Later this month, people who use GitHub may find themselves suddenly getting an error message while trying to authenticate against the GitHub API or perform actions on a GitHub repository with a username and password. The reason for this is the removal of this authentication option by GitHub, with a few ‘brown-out’ periods involving the rejection of passwords to give people warning of this fact.
This change was originally announced by GitHub in November of 2019, had a deprecation timeline assigned in February of 2020 and another blog update in July repeating the information. As noted there, only GitHub Enterprise Server remains unaffected for now. For everyone else, as of November 13th, 2020, in order to use GitHub services, the use of an OAuth token, personal token or SSH key is required.
While this is likely to affect a fair number of people who are using GitHub’s REST API and repositories, perhaps the more interesting question here is whether this is merely the beginning of a larger transformation away from username and password logins in services.
No Skies Are Falling… Yet
First of all, the good news is that dealing with this change isn’t super-complicated, and if reading GitHub’s blog posts has filled you with confusion and various levels of existential dread, here’s an easy way to fix it with minimal changes if you’re used to hammering in your credentials on the command line with the git client:
Switch to SSH.
That’s it. If you already have a SSH keys installed on your system, make sure to copy the public key into your GitHub profile. After this you can either clone your repositories anew with more SSH flavor, or change the git remote URL from HTTPS into its SSH equivalent.
Doing this requires opening the .git/config file in your local repository’s root folder in your favorite text editor (like Vim) and changing the remote’s URL. Simply change ‘https’ to ‘ssh’, and append ‘git@’ before the host name so that e.g. https://github.com/Foo/Bar.git becomes ssh://git@github.com/Foo/Bar.git.
Congratulations, you should now be able to use your SSH key to push, pull, fetch, rebase, squash and all those other naughty things with your remote repositories just like before. If you get weird SSH errors, it might be that you have the wrong permissions set on your ~/.ssh folder. Otherwise, enjoy not typing your username and password (or access token) any more every single time.
The Broader Picture
According to GitHub, the reason for this change is to increase security. Instead of passwords, they offer the use of personal access tokens (PATs) when using the REST API or accessing git repositories via HTTPS. The idea is that PATs can be created for specific services and individuals, to limit and grant certain rights. The resulting token is however a long string that you aren’t just going to remember and type in, which makes a password manager essential.
It is telling that none of this applies to logging into the GitHub website itself. There you can still use your username and password as before, possibly in addition to two-factor authentication (2FA) if you weren’t using it already. Here, the second factor in 2FA can be a code sent in a text message or mobile app, or something like WebAuthentication (FIDO2), with all the potential gotchas when using biometrics.
For those of us who were already using SSH with our GitHub repository queries, this means that essentially nothing changes. The use of access tokens should also come as no surprise to anyone who has integrated a CI system or similar with GitHub. It does however lead one to ask the question of what the point of GitHub’s change is if it only makes a few DevOps scurry around to update services (and fix the few that do fall over). Is anyone really trying to get rid of passwords?
As anyone who has ever managed a large, multi-user system at a university or large business knows, user account management is essential. Ideally you want to keep every user (whether a person, shell script or manager) in their own little permission zone. This is where GitHub’s announcement is perhaps the most puzzling. As noted by commenters over at Hacker News on the announcement, it would have made more sense to have expanded the access tokens to make more fine-grained and per-project roles.
The Power of Knowledge
Whether or not passwords are actually problematic seems to mostly depend on who you ask. If it’s a study commissioned by a company that sells alternatives to password-based logins, or the company behind Windows Hello, it’s the most insecure thing ever. However, as mentioned earlier, there are significant issues with these alternatives, especially biometrics.
In user authentication, identification can take place using something you have, something you are, and something you know. Biometrics is the practice of scanning a part of a person’s body and comparing it with previously stored data. This is public data which is becoming increasingly easier to copy and reproduce to fool biometric sensors. And of course if your biometric data falls into the hands of bad actors you can never change it.
Something which one has (wallet, credit card, hardware token) is easily stolen or lost. This is why such tokens are inevitably unlocked with a password, in the form of a personal identification number (PIN), which is awkwardly danced around as being a password, even though as a thing that ‘someone knows’ it is totally a password.
Things that people know are pretty amazing, because the only ways that they can be compromised are by forgetting them or by having someone record them using keyloggers, compromised ATMs, etc. This is demonstrated by the inability of US federal departments to force their way into password-secured iPhones. With the use of facial recognition all it takes is holding the phone up to the person’s face in order to unlock it, something which might even be legal for fingerprints. In some cases a photograph of the person suffices.
All You Need Is SSH
Realistically, the nice thing about GitHub’s change seems to be that it forces more people to finally toss out or rewrite those old scripts and forgotten-but-still-active Java back-end services that have username and password credentials hard-coded in them. Having them use SSH (conceivably using ssh-agent or GPG agent) eases maintenance and should improve security. Even if one just uses git repositories from the command line and doesn’t bother with a password manager, switching to SSH means less typing.
As an authentication mechanism, SSH provides two-factor authentication in the form of something you have (the secret key) and something you know (the key phrase). Its benefits are acknowledged by GitLab as well, who as of August 15th this year are no longer offering multi-factor resets for free user accounts. If one has an SSH key registered with the account, one can use SSH authentication to recover the account in cases where all of the other authentication methods have become unavailable.
It’s Passwords All the Way Down
Because of the power of keeping authentication information safely stored in our squishy, organic brains, all authentication methods seem to lead back to a form of passwords at some point. Even ‘password-less’ authentication tokens require a passcode (PIN), which one has to remember. The same is true for credit cards, debit cards, online banking accounts, SIM cards, password managers and so on.
On last count, I have to remember the PIN codes for multiple SIM cards, debit cards, credit cards, online banking apps, and one password manager for nearly a dozen total. Guess where these PIN codes end up? That’s correct, in the password manager, because remembering a random string of numbers is tricky, but remembering a dozen of them is a borderline nightmare scenario. Was it 7634 for that one debit card, or 7643? Or was that for the second credit card? Even Elliot Williams’ brain-based hashing system for PINs lets him write the public key on the card but it still demands that he remember the private key (and how to hash them in his head).
Perhaps that’s the appeal of biometrics: to have something that just is, with nothing to remember or some physical item to keep track of. Yet biometrics is the cryptology equivalent of printing your SSH private key on your forehead (or fingertips).
At the end of the day, it seems that all authentication roads end up leading to password managers and SSH keys.
I can’t imagine the hassle of using github regularly with passwords. I have been using SSH keys as long as I can remember.
Microsoft, I’m sure there trying to makw this a paid service
Yes and they are going to use the profits to buy adrenochrome for the annual bash at Bohemian Grove lol. One pointless security hiccup does not a conspiracy make.
GitLab is always an alternative.
I like notabug.org – just like github, BUT it uses opensource software one could even use for themselves and unobtrusive hosted service. And not a horrible over-cluttered monster like gitlab (where you can’t even find source for a while, dammit).
Because you don’t need access from somewhere you don’t carry your extremely valuable keys maybe?
This is exactly my greatest concern. I commonly work with many systems, hop laptops, and have to dev in conjunction with students. When it’s not Covid times I’m likely to need to clone/push/pull on machines that aren’t mine. Passwords were great for this. Now I’ll need to either remember to carry around a USB drive with keys or put them up on a cloud service (scp off a linux machine), which makes them closer to exposure anyway.
What a mess for those of us that don’t have just a couple static machines to work with.
I still prefer MFA access with a password because I have a special situation where a separate computer is running a dev web-api site that is accessible over the internet for web-ui dev purposes (the developer is in a remote location). That dev computer from time to time needs to update the web-api to accommodate enhancements and bug fixes. At that point I disable the firewall rules for the web-api and login to Git to pull the web-api using MFA as opposed to SSH (I literally have to manually delete the SSH that is automatically added to my machine when using Git Bash).
If this computer I am using gets hacked then the attacker still needs the multi-factor code that is sent to my phone, which they are unlikely to have access to. With an SSH, if the computer I am using gets hacked then I am toast.
Minor point of order… SSH doesn’t use certificates – the public keys aren’t signed by a higher authority like in a PKI. SSH public keys are trusted by virtue of the fact that they’re in the authorized_keys file.
SSH does support certificates.
https://smallstep.com/blog/use-ssh-certificates/
There is one funny catch: remote server can enumerate SSH keys you’ve got to some extent. I bet privacy intruders like MS really appreciate it. Doesn’t works with passwords of course.
Yuck. I hate SSH keys.
Every platform has a different way to implement them. There’s places to put them into config files in Linux. There’s some other weird file format for using them in Putty. There will probably be some third terrible way to do them I have to learn on Android when my Nexdock arrives. Or will any Android app even support this?
The example above, adding github to ssh’s config file brings back nightmares of the hoops I once had to jump through to make subversion via ssh work when an oh so helpful network admin decide it was a good idea to take ssh off the standard port. Why can’t ssh support server:port like any sane application?!? But that’s a tangent.
And the man files? Written for full time network admins or maybe someone who just came out of networking class in college. Definitely not for someone who graduated 20 years ago and doesn’t manage servers for a living.
And if you lose your files? Then what? Contact GitHub and ask them to let you back into your account? Pretty please! If I lose my password this isn’t a problem. It means I am suffering brain injury and probably not coding anymore anyway.
And functionally that is all an ssh key is anyway, a password. But it’s one that’s too long to fit in one’s head so it has to be carefully stored and backed up as a file that you are screwed if you ever lose. Yes, I know the difference, a key is used by the encryption/decryption algorithm while a password is only checked against a stored hash. But from a user’s perspective both are just the string that you have to know to prove you are you and get into your stuff.
Maybe this means I’ll be moving to some other service rather than GitHub or since this seems to be the way things are moving anyway maybe it’s time to switch back to self hosting. I never thought the cloud (other people’s computers) was a good idea anyway.
“And if you lose your files? Then what? Contact GitHub and ask them to let you back into your account?” – You still have username/password authentication available for “human-interaction” items like logging into the website.
It’s only for frequently “automated” things (use cases that would frequently involve someone storing their user/pass on an automated system) they’re blocking.
As you aren’t likely to remember the passwords anyway – too many of them to recall. Just be sure to keep your certificates and keys backed up perhaps inside your password manager..
Then they only need to beat one password out of you to gain access to everything, but hey its convenient and about as secure as any other method..
Nothing is really secure, and I am in agreement with kc8rwr that the cloud isn’t a good idea. At least in general, your own personal stores should be in your own control as much as possible. Though the cloud definitely has many uses and convenience benefits in some cases – for example I’m quite happy to host anything I intended to or have published open source to be stored anywhere, to allow the files for my D&D type games to on a cloud service (so the other players/Game Master (oh wait can’t use that word any more apparently… Game Maestro?) can have easy access), or to use some video sharing platform to share should I ever want to – I’d obviously want to keep my own original files myself as well but if the goal is to let others view your work why put in the hard work to make a decent website, host it yourself etc if the existing platforms do it for you! (The only reason I can see is because its important/Private type stuff you only want to share with very specific people – in which case why you would even consider a cloud company…)
Let’s see, I got my banking password, my e-mail password, my social media password (with 2fa enabled on every SM site I use) and a password for stuff I don’t care if they get hacked. Yup, remember them all.
Ashe does support host:port
I’m sorry you had such a problem with SSH in the past. That’s unfortunate. I find it to be a good tool overall, and I have not found it lacking or found any attractive alternatives.
For what it’s worth ssh:// style URLs lets you use host:port format. Which works with svn, git, and others. But it wasn’t always available. Introduced maybe 10 years ago? (not sure, I don’t use it much, see below)
Myself, I use .ssh/config to setup all my hosts ports and aliases. The wildcards make this easy for me as I have access to about 40 different machines all with a custom ssh port (usually the same port on the same top-level domain. Additional configuration per host like X11 forwarding makes the config file especially useful to me, as some hosts I need to do X11 and others it would just slow things down if I left it enabled (because things like vim will look for it when it starts)
In order to keep track of all this, I keep config files that don’t need to be confidential in a private subversion repo. I “svn up” on any of the systems I access to get my latest .ssh/config .bashrc .zshrc .inputrc .Xresources .vim/vimrc .screenrc .gitconfig and so on. Seems to be working fairly well for me for the past 15+ years. But certainly my way of doing things is not to everyone’s preference.
Finally if you lose your Github SSH key, then log into your account on the website and delete it and add a new one. If you use 2FA then use your recovery tokens. Which hopefully you stored somewhere safe, like as a hardcopy in a physical safe (bank safety deposit boxes are a good fire proof option).
This is going to be hell. Won’t be able to just git clone and do work anywhere from any machine easily anymore.
Unauthenticated git clone will still work. For public repositories.
Not that I like it :-/
Yes but i cant push my changes back with out either an SSH key or an auth token then. (Not nice to take with you.) This makes developing on basically random machines (one if the whole reasons i use github) basically impossible
I’m assuming there’s nothing that prevents you from keeping a PAT with you in multiple locations.
The main benefit of a PAT is that it’s easily revokable if you think a particular token was compromised without having to reset passwords to your entire account.
So i might as well just keep the files on a local only git or more to a better platform of i have to carry around a usb to use github.
Plus how do you get git to understand this auth token system? Unless they did major changes recently it only supports password and SSH auth.
So you have a habit of typing your passwords on random machines? This is probably some of the things they want to stop. A yubikey fits on the keychain together with your house/car key. A micro flash drive with a ready to go dev environment is another alternative, and easily goes together on the same keychain
Considering typing or connecting anything to a random machine is just as dangerous it means like nothing.
You plug a 2FA key in and someone can steal its information as it types it in to the site. You use a USB dev area and it can easily be infected with viruses or stolen.
I don’t see the problem. Simply memorize your SSH key. That should be simple. Maybe get a tatoo.
^ This. SSH keys are correct if you work from a limited number of places (station). Once you have many many station, maintaining your private keys is a nightmare (and having a single key with you is as insecure as a pin code or a CC)
You can technically use hardware token with ssh key in it, but it will still require setup.
Love my Yubikey.
You can declare as many public keys as you want, you know?
One private key has a single public key. Its unwise to move private keys around.
Indeed, keep private key at a single location.
Looks like it might be time to put all your favorite dev tools on a bootable USB thumbdrive and boot into those on all those machines. Or maybe include a VM client and boot the ISO there.
either way, PIA. Thank you Microsoft! May I have another?
I think “…opening the .ssh/config file in your local repository’s root folder” should rather be “…opening the .git/config file…”
oops, I replied with the same error, so ditto! ha.
There an error:
“Doing this requires opening the .ssh/config”
No:
Doing this requires opening the repositories .git/config
Have fun!
Argh… Here’s what the edited line should look like:
[remote “origin”]
url = git@github.com:Foo/Bar.git
i.e., You don’t use “ssh://”
Does the article author realize all this is only about the github API, not the web site? Many organizations have disallowed password-based API authentication for ages, I don’t see anything radical new here. I don’t think I’ve ever used github’s API with a password and I use github daily.
The author does realise that, as they wrote:
“It is telling that none of this applies to logging into the GitHub website itself.”
Of course they have, it’s trendy and cool, but it’s a pain in the ass to use to their stuff too. Probably the same dunces behind using emails as usernames so you have to give out your email address just to sign up for stuff,
I wonder what this does for proxies, that has always been my nightmare with github.
the computer can come up with a better password than i can. so i would rather these things be done without my direct intervention. my password manager is full of random noise passwords that i cant remember, hell i cant even remember all my user names half the time. take it a step further and make it so that there is little or no user interaction in password management other than maybe backing up your credentials file(s). such a system could even issue new keys periodically and update your password manager in the background.
i still dislike 2fa because of the almost universal requirement of owning a smart phone. you lose it or forget to pay your bill and you get locked out of your stuff. or if you are like me and think its a bad idea to keep a radio on your person at all times and let those pesky humans interrupt your existence all the time. and you are only one shop accident from invalidating your biometric data.
the biggest threat i think is still social engineering, and its hard to get people to cough up passwords they don’t know. and if they tell me to go into the bowels of my system and read off a text file to them, well that;s a big fat red flag.
A smartphone doesn’t stop working if you don’t pay your phone bill, but OK.
Most 2fa sends a text message to your phone. Sort of hard to get a text without service.
Doing two factor over MMS is not recommended, you should be using an authenticator application on the phone.
Not many 2FA uses an authenticator. Plus unlike an app you can’t just steal someones email and get ahold of their 2fa from downloading the app on a different device on their account.
I know that can happen because thats how i recovered an account that was 2FA with googles app on my tablet that’s screen broke.
Yep. That is certainly what I do when I use 2 factor authentication. Never though about doing it via SMS, that would be kind of tacky.
Google phone is free. My SMS goes to my email. I haven’t had a cell phone for a couple of years. If I go on a trip to Russia for the President, I get a throwaway phone.
May 2FA will not let you use a Google Voice number because its not a really number. (No idea how they know this. But its happened to me.)
I really hate 2FA that just sent it to your email.
Wait, what? I had this problem since all the way back in March or April, when I faceplanted straight into a big NOPE trying to commit on Github with a password, as usual.
Why would anyone intentionally use the more complicated and less secure option? The beauty of git is only realized when you use ssh …
Yes! Some people can’t deal with change though and want to keep washing their laundry by beating it on rocks down by the streambed. Change always brings out the whiners.
Yep. Hauling SSH keys and PATs around is by far more complicated and less secure then remembering as pass word that travels over HTTPS to Githubs servers.
Granted yes its easier to revoke a PAT then reset a password but revoking an SSH is annoying as hell if you happen to use the default one on your system. Considering its may be used for every SSH connection you have made.
How do you know how safe HTTPS is? It has had many many design vulnerabilities in the past and yet somehow you think it is now in a perfect state??? Do you not know that public key encryption is very close to being completely cracked, while the encryption used by ssh is much more secure? Please, how did you reach this conclusion?
You do realize SSH and HTTPS use the same type of encryption public-private key pairs. The weak part of HTTPS is the key exchange that goes on.
SSH is only as safe as your private key exactly like HTTPS. Once you have a server’s private key you can decrypt any of its data encrypted with the public key.
Also you should never be moving an SSH Private key around EVER. So the only choice would be PATs or passwords. Both of which go over a HTTPS connection. Passwords can be memorized while PATs can not and have to be saved somewhere.
> Once you have a server’s private key you can decrypt any of its data encrypted with the public key.
Sure about that? Isn’t nowadays server’s private key used merely to prove its identity?
You’re right, ssh isn’t a super choice because the lazy key management most people have (and most tools encourage)
PATs are the way to go. Create the pat with the appropriate permission, save it how you please. If it gets compromised or lost, replace it.
I’ve got one password in my head. It’s got >64 bits of entropy. I use it for exactly one thing, my password manager. That stores the rest, all pretty much as complex the system supports.
Yes, you could steal my password database. You probably wouldn’t have to hit me very often to get my password, and my keyfile. At this point, you’ve exceeded my threat model.
If you’re remembering passwords for individual services, you’re probably reusing passwords, or at best using one password scheme.
Maybe not you of course, but the folks who’ve been convinced that CranberryJuice!01 is a sufficiently strong password (they increment it each time they have to change) wouldn’t want to adopt the discipline if they were able.
According to GitHub, the reason for this change is to increase security. Instead of passwords, they offer the use of personal access tokens (PATs) when using the REST API or accessing git repositories via HTTPS. The idea is that PATs can be created for specific services and individuals, to limit and grant certain rights. The resulting token is however a long string that you aren’t just going to remember and type in, which makes a post-it note affixed to your screen essential.
Fixed that for you.
SMSes sent from Shithub were delayed, so they expired when I received them in Belgium. It took me a while to recover my account, and get rid of 2FA, now that they are removing passwords based auth, I am seriously considering moving away from Shithub.
#deletegithub it’s a proprietary platform anyway driven by Microsoft.
Codeberg.org seems to be a nice alternative, for example:
https://codeberg.org/timelimit/timelimit-server
While I generally avoid github for having a painful UI for a keyboard (but non-vi) user, this is a very sensible move.
Passwords, and more generally authentication, are problematic and don’t really have a place on the web. Once I’ve authenticated myself to my computer, the secrets representing authorisation to perform actions based on some remote avatar should be placed in a controlled process on the computer where they can be taken out and used as needed, I shouldn’t have to keep typing passwords. Password managers and SSH keys are both strong movements in the right direction, but the concept isn’t new at all; and dates back to the 60s in the form of object-capability theory. It’s unfortunate that browsers are so big and clunky that getting them to treat the URL securely (so we can use a portion of it for credentials) is practically infeasible today, but I suspect that eventually they will have to make that change, as the frequency of browser bugs that get around the Single Origin Policy remains fairly constant.
Every platform? What do you mean by that, “every”?
Why would I need to login to github lol?
Just get the code and go. I haven’t logged in in perhaps years. I always found github to be a bit of a mess so I just relied on FTP for my code dispersal. Still works great.
I really love convoluted solutions. >_<
ANYWAYS, security is not just adding layers of it, security works differently, where a simple vulnerability breaks the whole chain of security.
In this case HTTPS is more than enough. If your user/password is leaked or your ssh is leaked, then the result is the same.
Option 1, use SSH. Option 2 … What is option 2!
Where we’re going, we don’t need an option 2!
Seriously, how can you be so self smug that you don’t see people needing access where they don’t have ssh key access? What’s the matter with you?
There will be no mass movement away from passwords until passwordless technologies are easy enough for the non technical. This move is good for nerds on github, but not for your mom.
I don’t get it, if you already login to Github with your FIDO2 physical key, then what difference does it make?
> Simply change ‘https’ to ‘ssh’, and append ‘git@’ before the host name so that e.g. https://github.com/Foo/Bar.git becomes ssh://git@github.com/Foo/Bar.git.
@Maya Posch (IDK if this kind of highlight works) there’s a much better solution – do “git remote set-url origin –push ssh://git@github.com/Foo/Bar.git” . Not only it’s easier to run a command than to edit a file (and you can even do this with a script easier, since there’s “git remote get-url” too), the –push flag makes it still use the HTTP-based URL for pulls, which is very good if you have a password-protected SSH key and you have to enter a password every time you try to use it. And yes, you should password-protect your SSH key , run “ssh-keygen -p” to set a password on it.
If you are trying to do a domain user profile, couldn’t you just use one of the GET cmdlets?