Someone ran an experiment looking at the SSH keys used on GitHub (public keys are accessible through the API):
https://blog.benjojo.co.uk/post/auditing-github-users-keys
Excerpt:
I remembered back to the May 2008 Debian OpenSSH bug, where
the randomness source was compromised to the point where the
system could only generate one of 32k keys in a set.
I used g0tmi1k’s set of keys to compare against what I had in
my database, and found a very large amount of users who are
still using vulnerable keys, and even worse, have commit
access to some really large and wide projects including:
...
Crypto libraries to Python
Django
Python’s core
...CPython is not officially on github, so committing evil stuff to the github mirror may not matter very much, but these users may have the same key configured for hg.python.org. Should we check everyone's SSH keys?
--amk
On Tue, Jun 2, 2015 at 10:19 AM, A.M. Kuchling amk@amk.ca wrote:
Should we check everyone's SSH keys?
Makes sense to me. Probably worth doing for all the *.python.org hosts, not just the commit boxes like hg.p.o.
Skip
On Tue, Jun 2, 2015, at 11:19, A.M. Kuchling wrote:
Someone ran an experiment looking at the SSH keys used on GitHub (public keys are accessible through the API):
https://blog.benjojo.co.uk/post/auditing-github-users-keys
Excerpt:
I remembered back to the May 2008 Debian OpenSSH bug, where the randomness source was compromised to the point where the system could only generate one of 32k keys in a set.
I used g0tmi1k’s set of keys to compare against what I had in my database, and found a very large amount of users who are still using vulnerable keys, and even worse, have commit access to some really large and wide projects including:
... Crypto libraries to Python Django Python’s core ...
CPython is not officially on github, so committing evil stuff to the github mirror may not matter very much, but these users may have the same key configured for hg.python.org. Should we check everyone's SSH keys?
I believe Martin checked everyone's keys when that vulnerability was announced. He certainly emailed me anyway.
Not that it wouldn't hurt to do again.
Also, everyone should use ed25519 keys now. :)
On Tue, Jun 2, 2015 at 11:28 AM, Benjamin Peterson benjamin@python.org wrote:
Also, everyone should use ed25519 keys now. :)
For people like myself who are behind the curve, can someone point me to a primer on generating new, more secure SSH keys?
Skip
On Tue, Jun 2, 2015, at 12:35, Skip Montanaro wrote:
On Tue, Jun 2, 2015 at 11:28 AM, Benjamin Peterson benjamin@python.org wrote:
Also, everyone should use ed25519 keys now. :)
For people like myself who are behind the curve, can someone point me to a primer on generating new, more secure SSH keys?
You just have to pass the right option to ssh-keygen
https://docs.python.org/devguide/faq.html#how-do-i-generate-an-ssh-2-public-...
On Tue, Jun 2, 2015, at 12:37, Antoine Pitrou wrote:
Le 02/06/2015 18:28, Benjamin Peterson a écrit :
Also, everyone should use ed25519 keys now. :)
Depends if the servers you connect to have all been migrated to a recent enough OpenSSH.
SSH can use your older keys if you don't delete them.
Le 02/06/2015 18:42, Benjamin Peterson a écrit :
On Tue, Jun 2, 2015, at 12:37, Antoine Pitrou wrote:
Le 02/06/2015 18:28, Benjamin Peterson a écrit :
Also, everyone should use ed25519 keys now. :)
Depends if the servers you connect to have all been migrated to a recent enough OpenSSH.
SSH can use your older keys if you don't delete them.
Is there a way of debugging which key is actually used? "ssh -v" isn't very useful.
Regards
Antoine.
On Wed, Jun 3, 2015, at 08:21, Antoine Pitrou wrote:
Le 02/06/2015 18:42, Benjamin Peterson a écrit :
On Tue, Jun 2, 2015, at 12:37, Antoine Pitrou wrote:
Le 02/06/2015 18:28, Benjamin Peterson a écrit :
Also, everyone should use ed25519 keys now. :)
Depends if the servers you connect to have all been migrated to a recent enough OpenSSH.
SSH can use your older keys if you don't delete them.
Is there a way of debugging which key is actually used? "ssh -v" isn't very useful.
Really? I see output from ssh -v like this:
debug1: Offering ED25519 public key: /home/benjamin/.ssh/id_ed25519 debug1: Authentications that can continue: publickey debug1: Offering RSA public key: /home/benjamin/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: Offering DSA public key: /home/benjamin/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 435
Le 03/06/2015 15:27, Benjamin Peterson a écrit :
On Wed, Jun 3, 2015, at 08:21, Antoine Pitrou wrote:
Le 02/06/2015 18:42, Benjamin Peterson a écrit :
On Tue, Jun 2, 2015, at 12:37, Antoine Pitrou wrote:
Le 02/06/2015 18:28, Benjamin Peterson a écrit :
Also, everyone should use ed25519 keys now. :)
Depends if the servers you connect to have all been migrated to a recent enough OpenSSH.
SSH can use your older keys if you don't delete them.
Is there a way of debugging which key is actually used? "ssh -v" isn't very useful.
Really? I see output from ssh -v like this:
debug1: Offering ED25519 public key: /home/benjamin/.ssh/id_ed25519 debug1: Authentications that can continue: publickey debug1: Offering RSA public key: /home/benjamin/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: Offering DSA public key: /home/benjamin/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 435
Yes, but why does it try keys in that order? And why is a key accepted or not?
Regards
Antoine.
On Wed, Jun 3, 2015, at 08:31, Antoine Pitrou wrote:
Le 03/06/2015 15:27, Benjamin Peterson a écrit :
On Wed, Jun 3, 2015, at 08:21, Antoine Pitrou wrote:
Le 02/06/2015 18:42, Benjamin Peterson a écrit :
On Tue, Jun 2, 2015, at 12:37, Antoine Pitrou wrote:
Le 02/06/2015 18:28, Benjamin Peterson a écrit :
Also, everyone should use ed25519 keys now. :)
Depends if the servers you connect to have all been migrated to a recent enough OpenSSH.
SSH can use your older keys if you don't delete them.
Is there a way of debugging which key is actually used? "ssh -v" isn't very useful.
Really? I see output from ssh -v like this:
debug1: Offering ED25519 public key: /home/benjamin/.ssh/id_ed25519 debug1: Authentications that can continue: publickey debug1: Offering RSA public key: /home/benjamin/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: Offering DSA public key: /home/benjamin/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 435
Yes, but why does it try keys in that order? And why is a key accepted or not?
That's just how the SSH auth protocol works. The client offers keys until the server finds one acceptable. I'm not sure how the order is determined; it's probably arbitrary for OpenSSH.
On Wed, Jun 3, 2015 at 9:59 AM, Benjamin Peterson benjamin@python.org wrote:
I'm not sure how the order is determined; it's probably arbitrary for OpenSSH.
Certainly you wouldn't want it to offer a key generated by a system it knows to be weaker before one generated by a known stronger system? I would hope the OpenSSH authors had some idea which were relatively stronger, so it could offer them first.
Skip
On 03/06/15 16:59, Benjamin Peterson wrote:
That's just how the SSH auth protocol works. The client offers keys until the server finds one acceptable. I'm not sure how the order is determined; it's probably arbitrary for OpenSSH.
The server will accept the first key it can find a public key correspondence in its configuration.
The key order the client offers is irrelevant if the server only knows about a concrete public key . That key will be accepted and all the other offers will be rejected.
-- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
participants (5)
-
A.M. Kuchling -
Antoine Pitrou -
Benjamin Peterson -
Jesus Cea -
Skip Montanaro