Authenticating git command line with personal access token

Hi there,

I got an email today while pushing an update to a repo to say that password authentication will be deprecated later this year in favour of access tokens. I want to set myself up for this change now rather than waiting until August. Better fix now rather than later :slight_smile:

I read the notice linked to by the email, and the documentation linked from there, and went about setting up a personal access token:

However, I’m a little confounded by the last step which seems to suggest that I have to copy the PAT into the password field for git whenever I make a request?

Quote from the documentation below:

Once you have a token, you can enter it instead of your password when performing Git operations over HTTPS.

For example, on the command line you would enter the following:

$ git clone
Username: your_username
Password: *your_token*

Is this really the only way to use a PAT? Surely there must be a way to authenticate without my having to copy/paste the token from the clipboard every time I want to push a commit? Moreover, the github website only shows the token to you once when it is created. So do I have to store the token in a plain text file on my machine?

Some guidance here would be much appreciated because I’m quite sure I’ve missed something. I had imagined that there would be a way to use a PAT like a public/private key where I would save it in a secure file on my system, could inform git of the location of the file and then git would handle all necessary authentication automatically in repsonse to requests.

Many thanks for your time!

:wave: Welcome!

A personal access token is used exactly like a password. That means you can cache your token in git, or a password manager.

More here about git credential storage: Git - Credential Storage.

Hi canuckjacq,

Thanks for the info, that’s good to know! I’ll experiment with git store for now. It seems like the most natural solution.

I think it would be good if a few extracts from the resources you linked could be added to the article below. If github is moving to PAT based authentication then this is likely where people such as myself will get their information. It would be helpful to know what options we have to spare ourselves copy/pasting over and over again.

1 Like

Thanks for your feedback! I’ll open an issue - to be honest I found our documentation a little confusing myself, which is why I linked to the external page.

Awesome! I actually only just noticed that the docs are open source anyway. I might make the edit myself and open a pull request. The page isn’t too bad, to be fair. Just that bit at the end could use some work.

1 Like

I have no idea why github is bothering us with changing passwords to credentials that are supposed to work in the same way. Even more it is extremely annoying that they do not provide any short how-to instructions to get the credentials deployed.
Pointing to some lenghty elaborations about credentials and tools is not a response to this issue. It’s wasting time of many people who are enforced to study things they don’t care about. Please be more respectful to your users.
Please provide instructions what to do once those credentials are created. Just the commands, not any theory.

Passwords and tokens may fit into the same boxes, but they aren’t the same.

A GitHub PAT can’t be used to log into your github account and change settings.

And you can disable a PAT w/o breaking your account.

Also, GitHub can recognize when you’ve leaked a PAT and disable it, w/o blocking your account.

These are all valuable properties.

In general, I’d suggest setting up SSH keys.

One thing GitHub may hopefully eventually do is force web based logins to use 2FA, and you can’t fit a 2FA challenge-response thing into a simple https url that you give to a git client. So by divorcing the git https credential from the web login credential, it enables GitHub to eventually move users to 2FA w/o breaking their ability to use https for git operations.

Further to the point, PATs allow you to scope permissions, instead of a password which enables the bearer to do everything as the user, a PAT can be scoped to perform a limited set of operations. This is incredibly valuable:

Thanks for the comment but it does not help with the question, how do I deploy the new key instead of the previous password, so I won’t get those deprecation warnings anymore (which suggest my login wouldn’t work after the switch date).

In principle: Use the token where you previously used your password.

The details vary depending on the client you use. Note that you may have to delete the password from a system keyring/password cache to be asked again, if your system has one.

OK, I use git command line only (in cygwin). No idea where it may have cached the credentials or how to delete/update them. But maybe it will ask implicitly once the password method has expired.