SSH Key Audit on Github (required)

What makes me the most happy about this is that they ask for the password in order to add a key now.<p>I was always very afraid of XSS attacks (I know - there shouldn't be any - but there could and were, though not for this) that would add another key, so I always hoped they would add that additional bit of protection.<p>As such: Another huge thanks to @homakov for forcing the issue.

Here is the command you use to obtain your fingerprint for this audit:<p>`ssh-keygen -lf ~/.ssh/id_rsa.pub`

The accompanying email:<p><pre><code> A security vulnerability was recently discovered that made it possible for an attacker to add new SSH keys to arbitrary GitHub user accounts. This would have provided an attacker with clone/pull access to repositories with read permissions, and clone/pull/push access to repositories with write permissions. As of 5:53 PM UTC on Sunday, March 4th the vulnerability no longer exists. While no known malicious activity has been reported, we are taking additional precautions by forcing an audit of all existing SSH keys. # Required Action Since you have one or more SSH keys associated with your GitHub account you must visit https://github.com/settings/ssh/audit to approve each valid SSH key. Until you have approved your SSH keys, you will be unable to clone/pull/push your repositories over SSH. # Status We take security seriously and recognize this never should have happened. In addition to a full code audit, we have taken the following measures to enhance the security of your account: - We are forcing an audit of all existing SSH keys - Adding a new SSH key will now prompt for your password - We will now email you any time a new SSH key is added to your account - You now have access to a log of account changes in your Account Settings page Sincerely, The GitHub Team --- https://github.com support@github.com</code></pre>

Why are ONLY keys at risk, which this implies?<p>Presumably someone could have added a key, done evil, then removed the key. Evil includes all sorts of interesting things, like checking in code under the name of an existing contributor. This could potentially be really subtle and would be difficult to find in an audit later.<p>(Remember the stink over OpenBSD potentially having backdoors in the IPsec stack, revealed in late 2010? <a href="http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd" rel="nofollow">http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd</a>)

They also did a notification when you tried to push:<p>ERROR: Hi andrewjshults, it's GitHub. We're doing an SSH key audit. Please visit <a href="https://github.com/settings/ssh/audit/&#60;removed&#62" rel="nofollow">https://github.com/settings/ssh/audit/&#60;removed&#62</a>; to approve this key so we know it's safe. Fingerprint: &#60;removed&#62; fatal: The remote end hung up unexpectedly<p>A little weird to see when you're doing a push but good that they put it in there. Their email got flagged as bulk in gmail so until I saw this I didn't know they were doing the audit.

Sadly the link in the email isn't direct (it's a tracking link through "news.github.com"), so Thunderbird flags it as a possible phishing attempt =(<p>Edit: github send out an email with a link to the ssh audit page; that's the email to which I refer

As an interesting side effect, they will have pretty exact stats on how many active users they have; might help them sunset old accounts or move them to the slowest servers.<p>(Because of the offline nature of most git actions and different habits on pushing/pulling, it's probably hard to otherwise estimate how much a user cares about their github.)

Correct me if I'm wrong but the nature of the vulnerability was that someone who's <i>not</i> you had to submit a page with certain POST variables they could have determined after the fact to be malicious while logged in.<p>So the fact that they're sending out this E-Mail tells us that they either don't keep logs on requests + POST contents, or that they haven't had the time or inclination to analyze this data if they have it.

I guess this answers my questions about how long this vulnerability existed (a long time) and whether or not they could verify no other accounts were compromised (no).

Um, is anybody else having the experience that their keys really do seem to be different?

It would be interesting to know the details of the vulnerability. Given that they've patched it, it would be good to see what the error was in case others are affected.<p>Was this Rails-related and what was it?

<a href="http://unix.stackexchange.com/questions/2116/given-keys-in-ssh-authorized-keys-format-can-you-determine-key-strength-easi/2146#2146" rel="nofollow">http://unix.stackexchange.com/questions/2116/given-keys-in-s...</a><p>This script is very useful when doing this audit, because you can turn your .ssh/authorized_keys file into a list of key names and fingerprints to check against what github is showing you.

I've just registered yesterday on Github (it's suggested for Coursera's Saas Class i'm attending) but they've sent it to me too, even though the vulnerability has already been resolved <i>before</i> my account was created. Maybe they've not checked account age..

Why are you guys praising GitHub? They basically screwed up thrice: first by not catching such an obvious flaw (granted it should have been changed in Rails, but still), second by breaking half the scripts that rely on their service and finally by sending such an obnoxious email (really required action? Who the hell to do you think you are?).<p>Anyway it is pretty moot at this point since I have long ago forgotten my password and changing the orgion to somebody else is pretty easy.<p>That said, can anybody recommend alternatives? I know Bitbucket and they seem pretty great, especially as they allow private repositories, but it seems the consensus here doesn't like them for some reason?

Is it a good idea to check created_at != updated_at ?<p>People update public keys very rarely. I would even say NEVER.<p>Just make an sql against your table to see what are the most possibly are malicious keys.<p>(i see no reason to update timestamps doing 'the trick'. I believe attackers didn't)

Several comments below praise the Github team response to this vulnerability. I agree. But it should also be mentioned that the first email I sent to my company this morning read, "should [our product] source code be in the cloud?"

It was easier for me to just delete all of the keys. I had some I didn't need anymore. I also didn't pick great names for the keys I had. It's easy to add a key so instead of checking the fingerprints I can just create a new key.

I've just seen it and I headed to Hacker News to verify if it was legit :)

Damn I envy the GitHub guys. They can send a mail to their users about SSH Keys and nearly all users simply understand it and get it over with.<p>In any other business, the result of a similar mail would be an overloaded helpdesk, a significant reputation hit and a massive bucketload of competitor FUD.

They also added a audit log so you will be able to track and address any future issues.. <a href="https://github.com/settings/security" rel="nofollow">https://github.com/settings/security</a>

you got balls guys. It is hard to force everyone to do something but you did it. Kudos<p>also, if we go back few years ago this way would be a bit secure to handle keys @key.body = params.. @key.title = params.. I am sure update_attributes is good choice when you got 5+ fields and update database scheme pretty frequently. Just my 2 cents

while this was a good response to their security issue a little heads up would have been good. they broke all of our auto builds and by the time we figured it out the guy who's key was used for the builds was gone on his vacation. luckily, we got ahold of him prior to him turning his phone off.

Did this change just disable re-use of deploy keys across multiple repos?