[cryptography] preventing protocol failings

Nico Williams nico at cryptonector.com
Tue Jul 12 18:40:33 EDT 2011

On Tue, Jul 12, 2011 at 5:36 PM, Andy Steingruebl <andy at steingruebl.com> wrote:
> I reject the SSH key management example though.  Especially if you've
> ever maintained a large number/variety of unix servers running SSH,
> where hardware failures, machine upgrades, etc. lead to frequent SSH
> key churn.  In those cases the only solutions are:
> 1. Automate key distribution to things like the /etc/known_hosts file
> via means that aren't built into or supported by SSH itself really,
> they are an adhoc add-on.
> 2. Go to insane pains to ensure that keys don't ever change. Quite
> tricky when you're trying to automate OS installs, etc.
> 3. Use keys-in-DNS for this, which defaults back to something quite
> easy to attack.
> 4. Give up. Accept all keys without fail and just assume you're not
> getting owned.
> In practice unskilled sysadmins in large environments go with #4 most
> of the time, and you're right back to where you started... you can't
> defend against active attackers.

I've seen several cases (two of them high profile Wall St. banks)
where people fallback on SSHv2 with GSS keyex.  This way you get to
avoid SSHv2 public host keys altogether.


More information about the cryptography mailing list