
Auditing GitHub users’ SSH key quality - benjojo12
https://blog.benjojo.co.uk/post/auditing-github-users-keys
======
Someone1234
Maybe GitHub themselves should just stop accepting keys of a certain length.
For example <2048 RSA keys (and <256 ECDSA keys). They could also check
against the Debian set.

As the article says, GitHub could be being proactive rather than reactive
here. They don't "have" to, but they could.

~~~
Noelkd
According to a 2009 blog post[1]:

> Thanks to our new servers, known bad keys[2] from Debian and Ubuntu are now
> blacklisted. We estimate that about 1000 keys in our database were impacted
> by this. If you get authentication errors using keys that worked a day ago,
> please double-check that they are not on our blacklist. If they are, you
> should ensure your software is updated and generate new keys. We’ve got a
> guide to help you out with this.

[1] [https://github.com/blog/500-state-of-the-hub-rackspace-
day-0](https://github.com/blog/500-state-of-the-hub-rackspace-day-0)

[2] [https://github.com/blog/63-ssh-keys-generated-on-debian-
ubun...](https://github.com/blog/63-ssh-keys-generated-on-debian-ubuntu-
compromised)

~~~
scintill76
Woah, this new article says a lot of weak-Debian keys were found. Does this
mean Github had a regression in their blacklisting since 2009? Or maybe they
didn't blacklist enough originally?

~~~
viraptor
Actually the facts are not incompatible here. There are two questions: Are
weak Debian keys accepted in the web app? Are weak Debian keys accepted by
their SSH.

The answers were yes and no. It's the same for most systems right now. You can
put a weak Debian key in authorised keys, but you won't be able to login
anyway.

------
tyrel
Seeing a key with substring of "Tyr" as the username and that substring of my
key matching scared me a bit.

If you want to check how many bits your key is, use

ssh-keygen -l -f ~/.ssh/your_key.pub

(It wasn't mine, while it is an older key, mine is larger than 768 thankfully)

Edit: look at timdorr's example for a better visual.

~~~
timdorr
Most people will want to run this verbatim:

    
    
      ssh-keygen -l -f ~/.ssh/id_rsa.pub
    

You'll get an output like so:

    
    
      ⚡~ $ ssh-keygen -l -f ~/.ssh/id_rsa.pub
      2048 f6:2d:94:54:c0:96:18:64:24:fb:c2:ad:ed:6a:1d:68  timdorr@Pixelicious.local (RSA)

~~~
eridal
how much safe are we, with a 2048 bits key?

is this something we should be upgrading (like to 4096) in the near future?

~~~
agwa
Not much point in upgrading from 2048 bit RSA to 4096 bit RSA. Instead, you
should plan to upgrade to ed25519 keys when your client and servers support
them - faster and better security than RSA.

~~~
therealmarv
Does anybody have a good (and easy!) guide how to do that on my Mac or Linux
machine (client and server) ?

~~~
agwa
If you have experience with RSA key pairs, using ed25519 key pairs is easy. To
generate a key pair just run: ssh-keygen -t ed25519

As with RSA, this command generates a public and private key file. Put the
public key in the authorized_keys file on the server side.

You'll need OpenSSH 6.4 on both the server and the client side. If you have an
older version, I would not recommend upgrading outside of your operating
system's normal upgrade channel because then you'll be responsible for
security updates. Instead I would wait until your operating system has it.

------
scrollaway
How does one even go about _getting_ a 256-bit key? You have to do it on
purpose somehow, or it has to be _seriously_ old, in which case you're likely
aware somehow that that's a terrible idea.

Is there outdated ssh keygen software out there that still generates sub-768
keys?

~~~
pdw
And where do the odd numbers come from? 1023 bits? 799 bits??

~~~
benjojo12
So this one is kinda fun.

IIRC PuTTYGen had a bug in it for a very long time that you would ask for a
1024 key, and it would subtract a bit off it. You can see the same with 2047
keys in the data that I will be publishing on the next post.

~~~
mortenlarsen
Some people use slightly odd key-sizes on purpose, in the hope of buying a
little extra time in case something like the Debian OpenSSL bug happens again.

------
Tharkun
At least Github were "kind" enough to strip the comments from the public keys
they publish without permission. I would've been even more upset if they were
leaking things like username@workdomain....

~~~
c22
But the keys are public...

~~~
Tharkun
That's my point. They shouldn't be. I never gave Github permission to publish
my keys. The "public" part in the key is merely there to distinguish it from
the "private"-part ("never share this with anyone"). It should signify "share
this with people whose machine you want to access", not "share this with the
whole world".

From a healthy paranoid point of view: you don't share your public key unless
you have to. Sure, there are no known attacks on strong RSA keys _today_ , but
that doesn't mean there will never be. Why take that risk with, literally,
thousands of keys and people's security? It's rude at the very least.

Of course, you should never use your Github keys for anything else, but that's
beside the point entirely.

As for the comments: key comments are useful but often contain information
that can identify a person (e-mail address, username@machine etc). Publishing
that would have been even worse.

~~~
the8472
> Why take that risk with, literally, thousands of keys and people's security?

I would say it encourages scrutiny. The assumption of public keys is that they
are _public_ , if any part of your security architecture relies on a public
key being private then it would seem flawed, flaws that should be exposed.

And if them being public induces extra paranoia, such as using separate keys
only for github then all the better.

Sunlight is the best disinfectant.

~~~
scintill76
> if any part of your security architecture relies on a public key being
> private then it would seem flawed

What about your privacy architecture? Can the public key be derived from a
packet capture of SSH? My quick session with Wireshark and layman's
protocol/crypto understanding says probably not. But it seems possible that
while the crypto may be designed such that the public key may be public
without endangering the cryptography, there are still privacy reasons (being
able to identify people by unique public key) to not share it any more widely
than it needs to be.

For example, it seems like I have read that PGP public keys can be read in the
clear, which allows metadata graphs to be built by passive interceptors. Maybe
SSH doesn't have that issue though.

~~~
drewbug
Actually, it looks like the public key can be derived from a packet capture of
SSH. See
[https://tools.ietf.org/html/rfc4252#section-7](https://tools.ietf.org/html/rfc4252#section-7)

~~~
the8472
AIUI A SSH session first performs a DH key exchange and authenticates the
server. Only over that already-encrypted session will the client offer its
public keys.

That means the public key will not be leaked to outside observers. Combine
with server-specific keys to avoid potential "try logging into my server"
social engineering.

This means only the server will ever learn your public key, but it has to know
that already anyway.

So publishing your public key does not leak any privacy bits.

~~~
drewbug
You're right, my bad.

------
baby
Now you can also test several attacks on them, compare them to a larger
database to see if you have common divisors, check for low primes, check for
bad primes (fermat factorization)...

~~~
benjojo12
Yup, this is what I will be trying next.

~~~
martincmartin
It would be interesting to see, what's the public key that's used by the
largest number of accounts? I wonder if some people, instead of generating
their own, use a public/private pair they downloaded from the internet
somewhere, not realizing the vulnerability.

~~~
baby
I don't think that would happen since you would not find such a result
googling for "how to get a pgp key".

Makes me want to do a parody webpage explaining how to setup PGP by just
copy/pasting one

~~~
leni536
Maybe it doesn't happen directly but through downloading some preconfigured
Linux VM with the private/public key already set up.

------
madsushi
Rachel talked about Github and public keys a while ago (saw on HN):
[https://rachelbythebay.com/w/2013/04/07/ssh/](https://rachelbythebay.com/w/2013/04/07/ssh/)

~~~
Noelkd
Comments here:
[https://news.ycombinator.com/item?id=5508235](https://news.ycombinator.com/item?id=5508235)

------
Phemist
Especially the guy with commit access to PyCrypto should reconsider his
position in the project..

------
quux
Kudos to Github for not charging him with "Unauthorized Access of a Computer"

~~~
jessaustin
Given their customer base, that sort of response would have kicked off a shit-
storm. ISTM that any "responsible disclosure" ought to at least rate a
T-shirt. (If GH don't want to pony up the T-shirt, that's fine, but they can't
send customer notifications before the researcher publishes.)

~~~
benjojo12
I'm not saying that I didnt get anything for it what so ever, The peer of mine
did manage to send over some swag as a thanks, I now have
[http://i.imgur.com/d2f7mcD.png](http://i.imgur.com/d2f7mcD.png) on my work
desk :)

------
est
that [https://github.com/anybody.keys](https://github.com/anybody.keys)
feature, how on earth did OP find this?

~~~
helper
Its a documented feature [1].

[1]:
[https://developer.github.com/v3/users/keys/](https://developer.github.com/v3/users/keys/)

------
lcd047
In the mean time, Bitbucket still doesn't accept ECDSA keys:

[https://bitbucket.org/site/master/issue/4222/no-support-
for-...](https://bitbucket.org/site/master/issue/4222/no-support-for-ecdsa-
keys)

------
7ewis
What is the easiest way to manage SSH keys?

I can't remember where half of mine have been saved. I should really revoke
everything and start again, as I use it for accessing my VPS too.

How do you revoke all keys on Ubuntu and OS X?

~~~
semi-extrinsic
There is no concept of revoking ssh keys, so you have to remove them from the
~/.ssh/authorized_keys file on every server you have access to, and delete the
public keys at every service you've uploaded them to.

For a revoking mechanism to be possible you would need a trusted third party
(like a certificate authority) to verify the keys for each and every
connection you make.

~~~
shabble
For managing large infrastructure, it's possible with semi-recent openSSH
(5.4+ I think?) to validate and revoke keys[1] by signing them with a
different key which the server (or client) trusts.

[1] [http://www.lorier.net/docs/ssh-ca](http://www.lorier.net/docs/ssh-ca)

------
floatboth
> 210 | ssh-ed25519 AAAAC

Does this mean GitHub finally supports Ed25519?

~~~
glass-
I've been using an Ed25519 key on github for about 6 months now.

------
nodesocket
I'd be interested in the script used to scrape the GitHub public key endpoint?
I assume it just throttled back to stay under the GitHub API rate limit?

------
nandhp
I still use a 1024-bit DSA key I generated ~10 years ago. How bad is that?
Should I replace it with a 2048-bit RSA key?

~~~
baby
> We go on to consider Diffie-Hellman with 768- and 1024-bit groups. A small
> number of fixed or standardized groups are in use by millions of TLS, SSH,
> and VPN servers. Perform- ing precomputations on a few of these groups would
> allow a passive eavesdropper to decrypt a large fraction of Internet
> traffic. In the 1024-bit case, we estimate that such com- putations are
> plausible given nation-state resources, and a close reading of published NSA
> leaks shows that the agency’s attacks on VPNs are consistent with having
> achieved such a break. We conclude that moving to stronger key exchange
> methods should be a priority for the Internet community.

From: [https://weakdh.org/imperfect-forward-
secrecy.pdf](https://weakdh.org/imperfect-forward-secrecy.pdf)

------
hugomarisco
Good article. Very detailed and thoughtful!

------
scintill76
Pitting two well-known security principles (or at least watered-down versions)
against each other: "security by obscurity is evil" and "defense in depth".
Which trumps here? Should the public keys be printed in every phone book, just
because it says "public" in the name? Or should they be kept semi-secret,
since publishing them could lead to them being factored offline?

~~~
akerl_
Defense in depth doesn't conflict with "security by obscurity is evil":
Defense in depth is that I keep my private key secured with a passphrase, on
an encrypted volume, and that I take measures to protect against applications
having access to it unless they require it. It's the layer of physical
security where I don't leave my laptop where it's easily accessed, and
everything else that goes into securing a workstation.

Defense in depth recommends having multiple layers of security, such that a
breach of a single layer doesn't constitute a full breach. There's no
requirement (and in fact I'd argue there's no solid recommendation) for
including obscurity as one or more of the layers.

~~~
kelnos
The parent may not have used the best terminology, but the point still stands:
your "defense in depth" example utterly fails to protect your private key if
your public key is widely-available and easily-factorable.

If I didn't have my public key on GitHub, it's unlikely that even that could
fall into an attacker's hands. Not that I would _rely_ on that assumption, but
it would reduce my attack surface.

~~~
akerl_
If you think there's a chance that public RSA (lets not even get started on
ed25519) keys of reasonable size are easily-factorable, there's a lot of
groups out there who'd love to make you rich or lock you up.

~~~
dragonwriter
> If you think there's a chance that public RSA (lets not even get started on
> ed25519) keys of reasonable size are easily-factorable, there's a lot of
> groups out there who'd love to make you rich or lock you up.

I think that's more accurate if you replace "think" with "can actually
practically demonstrate".

------
scintill76
So, all the "it's called a public key for a reason!" people: when are you
going to submit a patch for OpenSSH allowing unauthenticated users to query
arbitrary users' public keys, and maybe a list of users while you're at it?
You vehemently support one particular operator of an SSH server doing it,
citing good security practice, so why not do it everywhere?

Edit: to be fair, there is the difference that GitHub has already added it and
probably didn't have to write C code to do it. So maybe this feature should be
requested for things like, say, cPanel, and users' $HOME/.ssh/authorized_keys
should be world-readable by default. Still, maybe it's worth doing in OpenSSH
so everyone can get the huge benefits of this currently only enjoyed by
GitHub's users.

------
3pt14159
This is a very grave error. If this caused damage to open source projects then
I could see a class action suit against GitHub.

1\. Duty of care - should never have accepted keys provably weak.

2\. Poorly communicated that username.keys was available, thus many users may
have thought their keys weren't at risk.

3\. No countermeasures from crawlers mass collecting keys. (Not they they
should even need to do this - they should just have done #1 in the first
place!)

This isn't a game man, GitHub hosts a ton of the world's open source code and
they're supposed to be experts in cryptography and security. Russian mobsters,
NATO spooks, bitcoin drug cartels, and even high school script kiddies are all
constantly trying shit and it impacts us _all_ not just the people with weak
keys. If python core gets backdoored _I_ get backdoored, no matter how careful
I am with the software I install.

~~~
baby
Instead of downvoting, let's educate people a bit more:

1\. Picking a small key is all on the user. It's like choosing the single
letter 'a' as a password. If you want to do so why not?

2\. The key you give to github is a "public" key. It is made to be public so
this should be irrelevant.

3\. There is 'almost' no known countermeasures against mass crawls of public
keys. Look at the recent attacks: [https://blog.hboeck.de/archives/872-About-
the-supposed-facto...](https://blog.hboeck.de/archives/872-About-the-supposed-
factoring-of-a-4096-bit-RSA-key.html)

What they could do: check against databases of public keys to see if your key
is weakened by such attacks.

~~~
Tharkun
I strongly disagree with #2. Your public key should NOT be public, especially
without your explicit consent. Specifically because, at least theoretically,
it could be used to derive your private key. From a parandoid point of view
that's just Bad.

This is one of the reasons why should use different key pairs for different
purposes.

~~~
orthecreedence
I strongly disagree with you. So do many, many people who upload their public
PGP keys to keyservers. The whole point is that anybody, anywhere can have my
public key without knowing my private key. If you can derive the private key
from your public key, then you have a really bad keypair (by algorithm or by
keysize).

~~~
snowwrestler
Yes, but communication is the whole point of PGP. I didn't upload my PGP key
to a keyserver, I uploaded SSH keys to GitHub so that I could check out my own
code--code which is in a private repo.

I can't think of any reason that my SSH keys should be publicly avaiable.
GitHub offers private repos so I can't understand why keys are all public by
default.

~~~
baby
It is because there is absolutely no reason they shouldn't be public. You can
generate as many ssh key as you want and if they are long enough they are
secure.

