Exec Summary: No actual changes to how the protocol itself works. Github is requiring modern keys + algorithms for git over SSH connections and removing the unencrypted git protocol as a connection option.
Seems reasonable to me. Since github is a git-as-a-service provider it makes sense to do this. From the headline I had thought they were making their own variant on the git protocol.
SSH is used to authenticate to GitHub as a specific user. GitHub can use this for access control and logging. This isn't new or surprising.
If you don't want to authenticate to GitHub as a specific user, you can clone repositories over HTTPS. This isn't new either. You can't authenticate over HTTPS anymore, but if you were concerned about being "controlled and recorded", you weren't doing that anyway.
For accounts without MFA enabled (which are the only ones who were able to use username/password via https in the first place), is the token granted after supplying just username and password, and if so, what's the real improvement?
I see here [0] a few benefits listed:
> 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
...but if you can trivially obtain it by supplying username/password, then it's effectively equivalent anyway.
Ah, that makes sense, for the case of losing control of (e.g., accidentally committing) the git connection credentials: better to just revoke a token than rotate the password after having potentially also lost control of whatever else uses the same password.
I know, but it's just, with git:// you know you're getting the "anonymous user" experience, so when things work for instructions or submodules or whatever you know it's not just because of your own saved credentials. If your repo is accidentally private, a git:// URL is just going to give you an error right away.
Not a big deal but just something that to my knowledge you won't be able to do going forward.
Huh, I was unaware of that. But then again so are most people, I'm sure.
It's akin using HostName in an ssh config file, though with what I'd consider to be a kind of odd reversed directionality to how you define it (and obviously letting you protocol-jump like this).
I really only said one thing, and I'm pretty sure it's not true of https URLs under common configurations when you've stored your credentials.
What I'm talking about is this: with a git:// URL, if you plug it into Git and that repo is private, you just get "Repository not found" immediately. With an HTTPS URL, if you're routinely using HTTPS for Git, you probably have credentials saved and you might miss that something's not publicly accessible which should be.
Further, if you do have some problem like this then the issue's arguably less clear, as the behavior of a private or simply nonexistent HTTPS repo URL for users without saved credentials is to prompt for login, which can be confusing, making a user think they need a Github account or that there's some problem with theirs.
https supports having credentials provided by various providers (and `.netrc`, for example). Which means when using https you don't know you're getting the anonymous user experience (because it's likely using credentials from other sources)
I use https solely for fetch, and ssh for push. Then the only credentials are the ssh keys. Does mean I need to edit the remote after fetching, but I'm pretty happy with that.
Natural language is sometimes ambiguous. I read "Git protocol security" as the protocol security of network protocols related to Git in general. They are deprecating the internal git protocol (tcp on port 9418) entirely, and changing the requirements for using the ssh protocol (tcp on port 22).
Last I checked, GitHub still refused to update their SSH key generation documentation to include instructions on using the "new" openssh key format, leaving users with insecure private keys.
The argument for why, according to every vendor I've reported this to, is their users are stupid and will get confused by the strange new detail that if their key is copied to a server that hasn't been upgraded in 8 years, that server might not be able to read the private key [locally]. It is much easier to just use the insecure defaults. For an SSH key.
That's a bit of a stretch (pun intended). The release page clearly says "Security updates have been discontinued as of July 6th, 2020" and that updates are only available through long time support.
That said, according to packages.debian.org it ships with OpenSSH 7.4 and support for sha2 have been included since 7.2. And ed25519 has been included since 6.5, so you should be fine.
> That's a bit of a stretch (pun intended). The release page clearly says "Security updates have been discontinued as of July 6th, 2020" and that updates are only available through long time support.
Yeah, but LTS is still support :P
> That said, according to packages.debian.org it ships with OpenSSH 7.4 and support for sha2 have been included since 7.2. And ed25519 has been included since 6.5, so you should be fine.
You'd think that, but Debian do their own thing. I don't recall the exact versions, but the Include directive for sshd_config should be present in the version shipped in Debian 9, but isn't[0]. I can't find the exact listing, but for instance you can see that `ssh-keygen` in Debian 9, of version 7.4, doesn't support rsa-sha2[1]; it does support `ed25519` however.
Was the whole password to SSH key switch annoying at all for anyone else? Like procedurally its simple but I have a bunch of accounts, a bunch of different repos. It just felt annoying even if the end-result desire for the system operator (GitHub) is maybe desirable... ("our users are better off according to our definitions of security")
Let me use a password if I want, these security requirements are becoming increasing absurd - I could realistically see people just checking out of services if these invasive procedures continue. Just kidding, a lad can dream. Yeah it's not rocket surgery to add the ssh key and then clone it to your different machines but if you have strict sprint deadline or something and you haven't pulled from your repo in a day and suddenly you can't run your workflow, then that's really pretty annoying to have to run the context switch and do some random bullshit to appease your vendor's obnoxious requirements. If Millenials ever learn software engineering en-masse maybe they would decry this lack of consent in daily software engineering operations. (Haha jk... not really, but I'm a Millenial so it's ok for me to say this)
Passwords are 100% the weakest link in our beep boop chain of trust, of course - we know this. But maybe they should just be rethought from the ground up instead of randomly affecting your users all the time with security nonsense.
EDIT: WOW speak of the devil, I literally just received an email saying on of my earlier keys is about to expire (personal account vs my employer GitHub account). Seriously shoot me in the face, why do I have to constantly update stuff to comply with requirements without getting paid? Just kidding, but almost not.
>Was the whole password to SSH key switch annoying at all for anyone else?
Never was an issue for me because I'd always been using keys in the first place. I imagine it's less common for folks who don't manage servers, but all of my prior ssh usage had switched to keys over a decade ago.
>Like procedurally its simple but I have a bunch of accounts, a bunch of different repos.
Definitely recommend looking into creating a ssh config if you're using different keys per account. (Notably you can set your IdentityFile (key to use) per host (which can also be set as something arbitrary like "gh-username")
>Let me use a password if I want, these security requirements are becoming increasing absurd
I don't want my software dependencies to be compromised just because someone reused a password.
>Passwords are 100% the weakest link in our beep boop chain of trust, of course - we know this. But maybe they should just be rethought from the ground up instead of randomly affecting your users all the time with security nonsense.
Keys are rethinking it from the ground up (which seems to be the complaint), though there certainly are challenges in managing keys as well.
Yeah you are basically right. I hate passwords with a passion so I guess it is foolish to even complain about passwords in the aggregate but I mean mentally it just adds a layer where I have to vaguely remember if I used passwords or another alternative form of authentication with a specific service.
I do a lot of data ingestion work, I run my own servers within a ZeroTier setup that links a bunch of machines together. I can only access it from my machines that have a set SSH key setup, so I agree, that's a great system. I ingest data from a bunch of data providers as well as some exchanges/brokers. But for example, look at the disparity for some of these web operators - Gemini only uses Authy for 2FA management iirc + password, Coinbase is Authenticator (or whatever you want) + password, Interactive Brokers has some weird bespoke setup that requires an initial mobile login and then another layer of auth that I can't fully describe. DigitalOcean is authenticator + password, GitHub is authenticator or SMS + password [I'm referring to actually accessing the website from a client device for all of these] Then they all have API key generation which has variable definitions. AWS is nice for its consistency with its AWS access key + private key combo that you can generate whenever you need with IAM profiles.
It's just... this is a lot to even need to know. I wish I didn't have to know the intricacies of all these crazy systems. I want to get some stuff done. I'd be down to have it be biometric or something. I'm tired of having to think about how I log into stuff and managing keys for all this shit. Literally - that's my complaint. It's all too much to keep in my head and I'm frequently frustrated by needing to recall this stuff. Sure, lastpass is fine for what it is and I also do try to keep my SSH keys safely stored for re-use where desired or generate machine specific configurations when that is reasonable for the project specification, but it's really just a headache for me.
I'd love a ssh key management solution that doesn't drive me bonkers - if you have any suggestions I'll owe you a coffee next time youre in town lol.
>I'd love a ssh key management solution that doesn't drive me bonkers
Kinda in the same boat here, taken a glance at Vault [1] but it seems like something that I'd probably spend more time figuring out than get benefit from it given my relatively small footprint.
Definitely have a lot more ssh authorized_hosts entries lingering around from old systems than I'm happy about.
A couple years back I installed Vault nodes on three Linode servers. Now, Vault's documentation specifies very clearly that the servers in your Vault deployment need to be talking to each other across a private network and their ports absolutely mustn't be accessible to the public internet.
At that time (this may have changed in the interim; I'm not using Linode nearly as much these days), Linode didn't offer private LANs between groups of servers. They did offer private IP addresses, but they had only a single LAN that was shared by every machine in each data center. But I figured; hey, that'd probably be good enough -- Those private IPs weren't publicly accessible, after all!
Anyhow, long story short, less than twelve hours later all three machines were furiously mining bitcoin.
Lesson learned: when software says that you need a private network, you need a private network.
>Linode didn't offer private LANs between groups of servers. They did offer private IP addresses, but they had only a single LAN that was shared by every machine in each data center.
>Lesson learned: when software says that you need a private network, you need a private network.
Hah yeah, I imagine a properly secured (famous last words) VPN setup is kinda necessary when dealing with stuff like that.
Having your secrets in one place (especially remotely accessible) is a very attractive target and you don't want to find out there's a 0day (or general misconfiguration) on your management system the hard way.
I'd like to think that I could make something like that work, but it's certainly more than setup and forget about it.
Mostly happy Vault user here. Unless you have hundreds of systems to authenticate (to), maybe with short-lived secrets, I think Vault will bring you more cognitive overhead, not less. I love it for system-to-system auth, or running on the system side at least, but for individual use I think a password manager will do you better.
Though yeah, I'd also like a better key management setup for myself. I have not been able to get either gpg-agent or ssh-agent to where I want in terms or privacy or usability.
> Passwords are 100% the weakest link in our beep boop chain of trust, of course - we know this. But maybe they should just be rethought from the ground up instead of randomly affecting your users all the time with security nonsense.
Github is not in a position to "rethink passwords from the ground up". They are however in a position where it's their responsibility to ensure the security of what they host.
These changes are good. That you're calling them "absurd" and "security nonsense" speaks volumes, to be honest.
And if one of your keys is about to expire (I'm guessing a GPG key since SSH keys traditionally have no expiration), that'd be because you put an expiration date on it. One you chose…
You're probably right, I was speaking about authentication on the whole from an industry perspective. I'm allowed to be annoyed with something that disrupts me from Innovating™ so I used my post as an outlet to do just that.
P.S. no the email that came is was related to a personal access token for my own special projects account. Maybe they defaulted to some expiration period, don't care enough to go out of my way to find out right now.
> Let me use a password if I want, these security requirements are becoming increasing absurd - I could realistically see people just checking out of services if these invasive procedures continue. Just kidding, a lad can dream. Yeah it's not rocket surgery to add the ssh key and then clone it to your different machines but if you have strict sprint deadline or something and you haven't pulled from your repo in a day and suddenly you can't run your workflow, then that's really pretty annoying to have to run the context switch and do some random bullshit to appease your vendor's obnoxious requirements. If Millenials ever learn software engineering en-masse maybe they would decry this lack of consent in daily software engineering operations. (Haha jk... not really, but I'm a Millenial so it's ok for me to say this)
Passwords are just not viable for public-facing services any more. If they let people use passwords, those people would keep getting hacked, and the support burden (or the reputation burden if they just shrugged their shoulders) would be too high.
Frankly, between using passwords that you're forced to rotate / expire / use x special characters and y numbers, using some opaque ML system that blocks your login whenever you're travelling, and just actually using ssh keys, I know which option I prefer.
I... what? I've never had my ssh key expire, because that's just not a thing. If you don't use it, then I think Github drops it after a year and requires you to add it again, but it's really not hard to put it back in in that case.
Also why on earth would I want to type a password every time I do something, even when it was an option I usually cancelled my push and set up an ssh key.
It is, actually. https://manpages.ubuntu.com/manpages/xenial/man1/ssh-keygen.... look for "-V validity_interval". Admittedly that's on the certificate rather than the key itself (yes, SSH keys can have proper CA infrastructure!) and not something most people have to worry about.
> Github drops it after a year and requires you to add it again
That's pretty clearly what GP was referring to. And I completely understand how annoying it would be, too. Consider this, you might not even use it again before it expires again, but if you don't re-add it promptly you probably won't be able to figure out why stuff isn't working the next time you do use it...
I have never used a password for git. It's always been ssh keys, across github, gitlab, bitbucket, github enterprise, stash, a folder on a server I have, etc. It wasn't something I was familiar with before the first time I used github in 2009 as a teenager, and it did not take too long to figure out.
Nowadays if copy/pasting the CLI commands github gives you and putting that in your profile settings is offputting, a lot of GUIs exist that will automate the setup process. It's not something where you're going to lose lots of time adjusting your settings, and it's not like github did not give a lot of warning on this change.
There's plenty of security behaviours I find overbearing, but I have to say I'm pretty ok with how github has been handling their transitions.
I have still not figured out how to use the new system from the command line. And I am generally rather familiar with git, just not with ssh. Ended up switching a repo to public just in order to be able to use it. Maybe I should try again and hope there are better tutorials around now than a month ago. The Anubis school of infosec https://external-preview.redd.it/-zmkMWw8GlL5REUZmtcKIPj9PtY... is strong on this one.
Sorry I'd tell you how I do it but for OPSEC reasons I cannot...
Haha just kidding, here what's up - this is what a friend of mine does that has nothing to do with my own operations of course. Probably violating many contractual arrangements bigly but honestly the whole security side of this stuff is so anal retentive that I will, for the greater good of my boy generationP.
You just go into your dev settings on GitHub. (Top right when youre on GitHub.com, dev profile pic, click on Settings then on Developer Settings, then you'll be confused because it asks you to register a dumbass GitHub app - ignore this)
Then click on "Personal access tokens" on the lower left of the left most menu.
Then generate with the desired permissions (wow, guess what most people will select in a rush...? shocking, unimaginable...)
Anyways once you have the token, which will only be generated once, so save it down - I just make a environment variable and export it because I have a finite amount of time in my life and this stuff beyond annoys me.
The just repoint your local repo clones to an instance with the following convention:
git://<username>:<personal_access_token>@github.com/<username OR orgname>/<repo name>
Good luck, old sport. Post on here if you have any problems.
You can also modify all the crap in your .git subdirectory within a repo but that's deep in the danger zone.
Thanks, but... something's off, and the error message makes no sense:
$ git remote set-url origin git://<my userid>:<my token>@github.com/<repository owner's userid>/<repository name>
$ git pull
fatal: unable to look up <my userid>:<my token>@github.com (port 9418) (Non-recoverable failure in name resolution)
In other news, did I mention that the scopes are a bit confusing? I've checked "repo" and nothing else, based on the empirical assumption that the stuff near the top is the most important, but why don't I need, say, "read:public_key", if I am to use ssh?
(The set-url worked fine -- the new URL is indeed in the .git/config.)
It is extremely annoying to me. Microsoft goes a similar way for authentication against a lot of their APIs. I dropped some of them because the maintenance isn't worth the benefit anymore.
I also don't want to register apps at them and don't want to wait until they acknowledge access. The market is too competitive for that.
An overall it doesn't really add security to my threat model. A complicated authentication isn't necessarily a secure authentication. Given, passwords have to be handled with care, but any ssh key could just as well be scraped by the OS vendor as any password or by someone that compromised your system.
While theoretically secure, CBC ciphers are considered weak because of their implementation. They are more often than not vulnerable to padding oracle attacks.
These issues have been around for more than a decade, but they keep popping up. The last 3-ish years a larger push has been made to disable CBC ciphers (in SSL/TLS, SSH, etc.). See [0, 1, 2, 3, and 4] for more information.
GCM/CTR is considered to be a more secure alternative.
That said, i don't think padding oracles are usually available in the context of an encrypted backup, so that particular concern is probably not a big concern in OP's usecase.
CBC does not provide authentication, thus it does not protect your encrypted content from manipulation (which can enable all kinds of followup attacks). Generally you should avoid using unauthenticated ciphers almost always and use an AEAD.
SSH uses CBC in combination with a MAC, so it has authentication, but it combines them in an insecure way. It turns out it's practically impossible to avoid these attacks (there had been countermeasures, but it's been shown that they can be circumvented). The attacks only let an attacker decrypt a single byte in certain situations, so the practical impact is limited.
Turning off unencrypted raw git protocol will be a pain.
I generally use that for grabbing stuff for inspection & evaluation as on a number of my machines, https protocol does not work (seemingly due to only supporting older versions of TLS).
I have not upgraded those machines for 'reasons'.
It can be worked around by grabbing on a newer machine, then cloning from there, but that is extra hassle. Ho hum.
(Given the Merkle hash format of the git repo's, there is really little or no need for an encrypted connection when fetching from a public repo).
As usual the problem is MITM. Any clone for git://github.com/foo/bar.git can easily be intercepted to git://github.com/evil-foo/evil-baz.git, or fetch, etc. The middleman can also do freeze attacks (i.e. prevent 'git fetch' from ever succeeding) and other such things. Almost all git workflows implicitly assume that both A) the upstream is 'correct' and therefore trusted. A corollary of this is that B) the transport to that upstream must also be secure, so you are sure it really is the upstream you wanted. A merkle tree is only useful after this chain of trust is established.
The only exception is if you know the commit hash a priori perhaps, and fetch that explicitly. But you often don't; even assuming most Git/GitHub workflows did know that, you're just passing the buck because to verify that commit hash is authentic you have to use some other secure channel, and that's often HTTPS.
My workflow was to look at the site with a web browser (with working up to date TLS), and note the hash of the final commit of master. This can be done on a different machine.
Then one clones the repo from the non https capable machine, and verifies the hash for the tip of master. Rinse and repeat for any other branches of interest, especially if only performing a limited clone.
Except git uses sha1 for those. Additionally unless you verify the ENTIRE hash not just 6 characters, it's trivial to brute force specific hashes into git.
I myself have committed with a hash of 0000000 into a git repository twice, meaning it is easy to confuse those two commits.
An attacker would merely have to brute force the tip of their attacker repository, a matter which you can do within the hour on a stock standard PC.
My example was using cut'n'paste, then cmp, so the full 40 char hash. I don't try comparing those things manually.
As I said trivial to prove valid; and since I was actually reading, using, and compiling the code, quite difficult to achieve a collision in the circumstances.
Then just fake the first and last characters, not much of an additional challenge, few people compare all characters, they compare the first and last few. I bet that would have even caught you unaware in some moments.
Brute Forcing a commit hash requires no gibberish binary files with random names, the data can be inserted into the commit metadata in ways that won't even show up in your git log. Forcing the entire commit hash is hard but by default everyone only checks the first 6 digits anyway.
Now the sadly amusing aspect of all this is that I only noticed the https issue in the first place, because I'd previously cloned some repos on the machine using it.
Then some time later when doing a fetch, I received a TLS nego rejection complaint. Github had turned off support or earlier versions TLS, and the machine in question did not implement the later version. (I believe this was on an old macOS version).
So as a workaround, I altered the refspec in the git config file to switch to using the raw git protocol.
i.e. their earlier 'improve security' measure drove me to switch to the 'improved' unencrypted git protocol.
would let you use an HTTP connection to your less archaic machine. Could even configure git to automatically do the rewrite similar to https://stackoverflow.com/questions/1722807/how-to-convert-g.... There's security considerations here so don't just do this blindly, but if no more unencrypted git protocol is a real pain point there's pain free ways around it.
Potentially useful, since I've used proxies before in a different manner.
However what I'm more inclined to do is simply compile up a version of git from source, ensure it includes the HTTPS transport, and links against an appropriate TLS/SSL library. I used to build it from source years ago (on a different platform).
The git protocol approach was simply to avoid that hassle, as used correctly it is safe enough.
This site isn't where I first saw this. This isn't the top hit for any search term I can come up with, but it is often on the first page of hits. So people do silly things without understanding what they're doing.
(To give somewhat of a feeling for age here, the exact wording from that tutorial is at least 5 years out of date. Putty changed the UI a bit in 0.68)
How would you correlate that with anything to produce useful data? GitHub already knows what repos an SSH key has access to, and usually read-only access to a public repo for which you don’t have write permission is done with HTTPS.
>and usually read-only access to a public repo for which you don’t have write permission is done with HTTPS.
I don't know if this is the case. I always clone with `github.com:owner/repo` remotes, because it's shorter and saves me the effort of doing things differently based on whether it's my repo or not.
What's the line of thinking that led you to believing a change like this would be for user tracking?
(Seriously asking by the way, this isn't a put-down. MS isn't in the ad business, let alone Github, and these changes primarily affect people who are logged in, so … no idea how you can make the leap)
Seems reasonable to me. Since github is a git-as-a-service provider it makes sense to do this. From the headline I had thought they were making their own variant on the git protocol.