A system for distributing SSH public keys

We have many different systems that are managed by several people. We have chosen to use SSH public key authentication to access those systems. This works great, as there is no need to manage or share administrative account passwords, no need to remember passwords to the various systems (only the pass-phrase to your private key), no need to interaction (entering password) with every remote command.

The problem is, the public keys installed on the systems need to be managed somehow. People come and go, keys may get compromised, responsibilities change (a person authorised to enter one system today may be authorised to access a different one tomorrow). Currently we manage it by manually editing ~/.ssh/authorized_keys files on every account that needs that, but that is a lot of work and prone for mistakes.

Is there any ready tool to manage public keys in such scenario? Do you have your own solutions? Or is that whole idea of managing systems this way flawed?

From serverfault Jacek Konieczny

• if this system works for you then it's probably ok, i personally think it's bit insecure, but that's just my opinion.

  as to your question re management of the key distributions i would look into Puppet (or Chef).

  From pulegium

• The draft rfc4255, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints" can help you !

  joschi : I really fail to see how the server's SSH fingerprint could help in managing the authorized_keys file.

  bortzmeyer : And, if it is a RFC, then, by definition, it is no longer an Internet-Draft.
  From 2xyo

• As already mentioned by pulegium, any generic configuration management software like Puppet, Chef, Bcfg2 or cfengine could accomplish the task.

  Since the authorized_keys file is not that complicated, you could also use rsync or a (D)SCM like git or hg to manage this file. You have the "master" file on one of your servers and serve it via rsync/git/hg/…. On every other server you run a cron job which periodically retrieves the master copy (if it was changed) and copies it to the correct local location. Heck, this would even work with pure HTTP or FTP.

  The bottom line is: Have one "master" copy of your authorized_keys file and update it. Let the "clients" (the computers, which should have the current authorized_keys file) fetch it from your master server and deploy it locally.

  ForgeMan : We comfortably use puppet to manage ~200 Linux servers (pub keys are just a file to enforce as an attribute of a user).

  Jacek Konieczny : I'll accept this answer at it seems I won't get better. It seems the choices for me are: 1. Keep things as they are now 2. Build own tool chain to manage authorized_keys files 3. Use some existing, generic tool for managing servers, like Puppet or Chef… though those tools seems too big for this simple task. 4. Use other authentication/authorization mechanism (like Kerberos)… though this also seems too sophisticated tool for a simple task Thanks.
  From joschi

• I'm not sure what you mean by many, nor do I know if you're willing to change, but Kerberos is the droid you're looking for. That will solve your problems elegantly, and will authenticate both people and machines.

  From pboin

• i run a very easy solution, that does the same with firewall-rules

  example file hosts.conf:

  192.168.0.1
  192.168.2.99
  192.168.2.100
  

  distribute.sh:

  #!/bin/bash
  for d in `cat ./hosts.conf`; do
    echo "copying to $d ...";
    scp /root/.ssh./authorized_keys root@$d:/root/.ssh./authorized_keys
  done;
  

  thats the whole magic :-)

  From renton

• There is a patch available for OpenSSH that allows it to use public keys from an LDAP server, but this only really makes sense if your auth/account checks are also done against that LDAP server (which is how my environment is set up). Also it's only as secure as your LDAP configuration (so you want to be using SSL & verifying keys).

  See http://code.google.com/p/openssh-lpk/ for the patch and further details. I don't know any OS that ships with this patch by default, but if you're running FreeBSD it's an optional patch if you use the OpenSSH from ports.

  voretaq7 : Incidentally using pam_ldap also lets you solve the "someone authorized to access machine A today may not be authorized to access it tomorrow" problem -- read up on pam_ldap if you're interested in that aspect...
  From voretaq7

• You have two (that generally turn into 3) different problems that you're trying to solve:

  • Authentication (Who are you?)
  • Authorization (Are you allowed to access this server?)
  • Audit (What did you do?)

  Public-key auth is an ok way to authenticate sometimes, but doesn't address authorization at all. I don't like public-key auth, as it is very easy to compromise (especially internally) unless you have some good controls in place.

  That's where solutions like Kerberos come into play. In the Windows world, Active Directory solves this problem. In the Unix world, there are an abundance of choices, which is both a good thing and a bad thing.

  I'd check out the Red Hat FreeIPA project, which is a bundle of software that makes it easy to get an AD-like Kerberos/LDAP/DNS system up and running quickly.

  Jacek Konieczny : I do understand the difference between authentication, authorization and audit. And SSH's 'authorized_keys' provides both authentication and authorization data. It is far from being perfect, but it is simple. And simplicity is often a big advantage, also in security. Kerberos, with its complicated infrastructure may security-fail in more ways than ssh with its authorized_keys files. Though, it doesn't mean one or the other is more secure.

  duffbeer703 : Managing authorized_keys files is np for a handful of servers, but you rapidly reach a point where its impossible to manage. I wasn't trying to say that it's a "bad" solution. Likewise, the complexities in Kerberos are inappropriate for two servers... but the investment in design/implementation of kerberos is worth it in a larger environment.
  From duffbeer703