Reduce the effort of verification
Posted Feb 18, 2010 20:55 UTC (Thu) by buchanmilne
Parent article: Trust, but verify
For SSH, especially for sites with lots of hosts, it means that users or
system administrators don't have to laboriously propagate keys into
authorized_keys files on each new system.
I typically avoid this.
In some instances, by using the openssh lpk patch, which allows the user's public keys to be
stored in LDAP, and have sshd find them there directly. I have also
scripted retrieving the keys from LDAP to a central authorized_keys file
(rather than per-user keys files, to adhere to security policies etc.), for
either the case where you can't patch sshd, or if you want to provide fail-
back in case of some problem reaching LDAP (e.g. failure of firewall or
network or similar). In this scenario, host key verification still needs to
be addressed, but there is a scalable solution - but it requires DNSSEC.
Now that we are seeing DSNSEC deployments, maybe this will become more
In other instances, where a decent Kerberos setup is in place, you don't
use public/private keys for users at all, but of course Kerberos
authentication. There is also a patch in development for OpenSSH to do host
verification by Kerberos, from the service principal, so host manual key
verification isn't necessary.
Both of these seem to scale better than MonkeySphere, as according to the
You'll probably only set up Identity Certifiers when you set up the
machine. After that, you'll only need to add or remove Identity Certifiers
when the roster of admins on the machine changes, or when one of the admins
switches OpenPGP keys.
So, when a new admin joins a team, another admin has to log in to all
servers and run a command to authorize the new admin as a "Identity
Certifier". This is exactly the kind of work duplication I have tried to
avoid by using LPK and Kerberos. And, if they don't know GPG/PGP, I would
have to teach them that first ... and unfortunately admins who have never
had a GPG/PGP key are all too common these days. In many environments, even
the term "ssh public key" had to be explained many times, including to the
network security team.
Now, unfortunately, AFAIK neither LPK nor the Kerberos host key
verification patches are likely to be merged upstream, as the OpenSSH team
doesn't seem to think they are necessary, and probably that they will
Of course, the pragmatic view that making it *easier* to implement adequate
security is of value seems to have been missed.
to post comments)