Thanks for this. I found it kind of weird that the email they sent didn't include any instructions on what to do. The linked webpage didn't have any guidance either. I guess they assume we all know what to do.

This. In fact, it creates an even more dangerous situation, as users could go to the site, see their keys, and say "I dunno. Looks fine?" and approve all of the keys, without actually confirming that the keys are legitimate.

Not giving instructions on the page on how to verify the info was weak. Github people, if you're reading this, please update that page.

This is a good point. I was really impressed with their GitHub Bootcamp [1], which made setting up the keys and getting started a breeze.

It's a shame that hasn't carried through to the key audit page but there is (now) a link on how to verify keys (http://help.github.com/verify-ssh-redirect)

[1] http://help.github.com/set-up-git-redirect

I very much agree they should have added instructions to the page. However when I went through the process there was a prominent note saying that when in doubt, you should reject keys and upload new ones. So the "I dunno. Looks fine?" case seems like it would be a problem only for the careless.

Sort of like how the Rails default settings only caused problems for the careless....

I bet a lot of people would have verified their keys with instructions but didn't bother without.

Disagree for anyone with more than one key. The problem with verifying all your keys at once is that I'm not going to find all my devices (I don't practice falconry). It would have been better if you could delay answering for some keys. I'm not sure you could have, but I didn't feel that way when performing my audit so I accepted them all, they all had recognizable hostnames.

It looked like you could put off dealing with keys by just not doing anything to them. Anything you didn't approve or deny would stick around. However, I didn't actually test this, and I only had one key which is now approved so it's too late.

That is correct I did exactly that. I got the message at home, and I had a key for a work computer on there, so I confirmed the home keys and left the work key disabled.

How is that "more dangerous" than having the users never look at the keys.

Most users will not have many keys (probably just one), and will be alerted if they see more.

Honestly, I did that. Just went right to the page and clicked "Approve" to all of them. I couldn't remember the command to get my fingerprint, I was lazy, and that was really stupid of me but it does go to show you should never trust a user. Even one who is a programmer and understands the risks.

Very weird. What I consider to be a "public key" is one of those long strings of characters in my `.pub` files. What they asked me to verify turns out to be a fingerprint (from what I understand elsewhere in HN comments).

I'll be honest - I didn't understand what those MAC address-type fingerprints were, and I accepted each key. Their email made me trustful, saying that probably no account was affected. I do feel bad saying this in public, but it is what I did when there was not more information immediately available to me.

When I did it just now they did have instructions for Mac OS, Windows and (default) Linux linked off the page. Maybe they added them after the original email?

The Linux instructions were

ls ~/.ssh/*.pub | xargs -L 1 ssh-keygen -l -f

Yes, that link to instructions was only added later this afternoon.

I mailed them as soon as I received their notification to check my keys, that any kind of help on how to actually view the fingerprint would be useful. Also I suggested as a bonus, that they detect the OS from the browser and display the appropriate information. I assume, that I wasn't the only one asking for more detailed guidance. Funny enough, four hours later, they did the exact thing and notified me again via E-Mail. What a great response!

As I noted above (5 hours before your post), these comments all took place before they posted a link to some instructions. That link was added in the afternoon, eastern time.

Some people might be running DSA keys - this covers that case:

`ssh-keygen -lf ~/.ssh/*.pub`

> Some people might be running DSA keys

Yep, or use a non-default key name.

Fair point but if someone is using non-default names then they presumably had to deal with ssh config files too.

I'd expect such users to have just enough familiarity with ssh keys to know how to check them (though I could be wrong).

Edit: Also, GitHub's setup guide explicitly leads to rsa keys so anyone using dsa keys consciously made that choice http://help.github.com/mac-set-up-git/

There's a help page now: http://help.github.com/linux-verify-ssh/

You can also iterate over all the public keys in ~/.ssh:

    for f in ~/.ssh/*.pub; do ssh-keygen -lf $f; done

I had the same problem. I emailed them to invite them to add that exact command to the audit page. Glad to see I wasn't the only person who had trouble.

You can also use 'ssh-add -l' to see all the keys you've added to ssh-agent.