On July 13, 2021, users of the COECIS Github Enterprise server will be transitioned to log in using Cornell Single Sign-On (Shibboleth) instead of using the previous sign-in process.
If you use your Cornell netid and Cornell password to authenticate to Github from within your locally cloned repositories, you must switch to token-based authentication, SSH-based authentication, or another approved method before July 13, 2021.
Logging into the COECIS Github Enterprise server through the web interface will continue to work, albeit using the Cornell Single Sign-On process.
If you need more assistance, please submit a ticket to the COECIS Help Desk.
Beginning July 13, 2021, we will no longer accept account passwords when authenticating Git operations and will require the use of token-based authentication, such as a personal access token (for developers) or an OAuth or GitHub App installation token (for integrators) for all authenticated Git operations on github.coecis.cornell.edu. You may also continue using SSH keys where you prefer.
This change is required in order to enable our Github Enterprise server to use Cornell Single Sign On
Tokens offer a number of security benefits over password-based authentication:
- Unique – tokens are specific to GitHub and can be generated per use or per device
- Revocable – tokens can can be individually revoked at any time without needing to update unaffected credentials
- Limited – tokens can be narrowly scoped to allow only the access necessary for the use case
- Random – tokens are not subject to the types of dictionary or brute force attempts that simpler passwords that you need to remember or enter regularly might be
- Command line Git access over HTTPS
- Desktop applications using Git (GitHub Desktop is unaffected)
- Any apps/services that access Git repositories on github.coecis.cornell.edu directly using your Cornell NetID and password
Command line Git access over HTTPS
Many people have historically cloned a repository to their computer using HTTPS and the standard command-line tool ‘git’ or another git client. For those users, they were prompted to enter their Cornell username and password during the git operations.
This functionality will no longer work and you will need to change how you interact between your local and remote Git repository.
Any method of working with Github that previously used a username and password can be done using these Personal Access Token instructions.
You would use the same username, but when prompted for your password, you would enter your Personal Access Token. If you’re worried about having to repeatedly re-enter your Personal Access Token, you can configure your Git client to cache your credentials.
Working with Github using SSH keys to push and pull their code will work just like it did before. If you wish to switch to this method, you can read more about it in Github’s detailed documentation.
Then when you clone a repository on your computer, just make sure you clone it over SSH and all git interactions will take place using the SSH key authentication.
If you have any existing repositories configured to use HTTPS, it’s relatively easy to configure them to use SSH.
Many users already use Github Desktop to interact with the COECIS Github server. Working with your code in this manner is easy and works natively with how Github authentication currently works. The client is free and available for Linux, Windows, and Mac.
Using the Github CLI Application
‘gh’ is GitHub on the command line. It brings pull requests, issues, and other GitHub concepts to the terminal next to where you are already working with git and your code.
If you prefer the command line, it’ll likely be an improvement to how you interact with the Github server.