

Key rotation in OpenSSH 6.8+ - zdw
http://blog.djm.net.au/2015/02/key-rotation-in-openssh-68.html

======
cnst
Will this all work by default?

E.g. other than simply being enabled by default (looks like it is), does
OpenSSH automatically generate new host keys every time the new host key
algorithm is started being supported? If it's system-dependent, e.g.
rc(8)-based, [http://mdoc.su/o/rc.8](http://mdoc.su/o/rc.8), how do most
systems behave here?

Also, looking at the code,
[http://bxr.su/o/usr.bin/ssh/clientloop.c#client_input_hostke...](http://bxr.su/o/usr.bin/ssh/clientloop.c#client_input_hostkeys)
will be calling
[http://bxr.su/o/usr.bin/ssh/hostfile.c#hostfile_replace_entr...](http://bxr.su/o/usr.bin/ssh/hostfile.c#hostfile_replace_entries),
doesn't it mean that it's quite easy for the attacker who can actually do MitM
and has indeed obtained the keys, to effectively cause a race condition, and
deprecate the non-exploited spare keys? Together with the existing key that
has been compromised? In such a scenario, it sounds like the attacker could
effectively replace the key they compromised (plus all the spare keys) with
their own brand new key, which will then make the ssh client generate warnings
should it try to connect to an sshd without MitM attack going on.

I'm kinda confused here -- is the possibility of such trick-playing not
considered a big deal?

~~~
zdw
I think the point here is changing from older RSA and DSA keys to newer ECDSA
and ED25519 keys.

Most of the issue you're bringing up a prerequisite of obtaining and/or
compromising the the target host's private keys, at which point most of the
other attacks have little value - what's the point of MitM-ing a host if the
SSH host keys only apply to that specific host, and you already have root on
it?

The only issue would be if you could take advantage of a flaw in the ssh
client and put arbitrary content in their ~/.ssh/known_hosts file, but I'm
betting this would be pretty easy to mitigate.

------
e12e
I'm not sure is this really is much of an improvement. SSH keys (as opposed to
ssh certs) have lots of trust issues, the main one being no way to properly
revoke a key, or for a key to expire.

I'm not sure adding this to the ssh server is better than just telling people
to use DNS RR-records (or use ssh certs, which narrows the problem to one of
distributing the ssh CA cert).

[http://www.openssh.com/txt/rfc4255.txt](http://www.openssh.com/txt/rfc4255.txt)

[http://www.iana.org/assignments/dns-sshfp-rr-
parameters/dns-...](http://www.iana.org/assignments/dns-sshfp-rr-
parameters/dns-sshfp-rr-parameters.xhtml)

I've yet to get around to managing my ssh keys via "ssh ca/ssh certs" (certs
are _relatively_ new -- at least when still running some Debian Old-stable LTS
boxes...). Looks like this might help:

[https://github.com/cloudtools/ssh-ca](https://github.com/cloudtools/ssh-ca)

As far as I can tell, there is no support to store SSH (CA) Certs in DNS --
which is a shame. Would've made sense to just have a SRV-record for the
(sub)domain?

------
adambatkin
You also need a way to revoke old and/or compromised keys (so maybe also have
an option to send keys that should be _removed_ from the known_hosts file)
otherwise you can't use this to rotate to new keys: sure, clients will
automatically know and trust the new key, but that's useless if they still
trust the old/compromised key too.

~~~
djmdjm
Yes, ssh will remove keys that are not in the set that the server sends it.
I've updated the blog post to mention this :)

~~~
adambatkin
That all makes a lot more sense now.

