26

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?

aculich
  • 3,520
  • 1
  • 25
  • 33
Jacek Konieczny
  • 3,597
  • 2
  • 21
  • 22
  • I can't really answer your question but when I read it I could just hear it screaming out for some kind of database system. – John Gardeniers Feb 26 '10 at 09:00
  • Indeed, I can see a place for a database on the 'backend' (the 'key server'), though I would prefer limit the database access there and have the keys distributed over SSH channel. Not to open any other communication channels on the managed systems. In fact I feel capable of implementing such tool/system myself, though I would prefer something ready and proven effective. – Jacek Konieczny Feb 26 '10 at 09:21

8 Answers8

18

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.

joschi
  • 20,747
  • 3
  • 46
  • 50
  • 1
    We comfortably use puppet to manage ~200 Linux servers (pub keys are just a file to enforce as an attribute of a user). – ForgeMan Feb 28 '10 at 03:00
  • 1
    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. – Jacek Konieczny Mar 02 '10 at 07:31
  • this system is as secure as the channel through which the master copy is pulled. – yrk Mar 22 '12 at 14:46
  • 1
    Ansible is a *very* lightweight CM system that has a module to muck with authorized key files over ssh. See http://ansible.cc/docs/modules.html#authorized-key – R. S. Feb 09 '13 at 01:40
11

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
  • 79,345
  • 17
  • 128
  • 213
  • 1
    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... – voretaq7 Feb 28 '10 at 01:25
5

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 :-)

bmaeser
  • 639
  • 2
  • 6
  • 10
5

I am currently checking out SSH KeyDB. It is meant to do exactly that, administrate roles, servers and users, distribute user keys, gather host keys etc. It even has something called "locations".

I haven't worked it all out yet and I am not sure if it is fully working. The code is in python however and seems to be fairly manageable, so it shouldn't be too hard to dust it off and get it working.

andsens
  • 361
  • 4
  • 10
1

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.

pboin
  • 1,086
  • 8
  • 11
1

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.

duffbeer703
  • 20,077
  • 4
  • 30
  • 39
  • 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. – Jacek Konieczny Feb 28 '10 at 08:40
  • 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. – duffbeer703 Feb 28 '10 at 13:39
1

You can use Bcfg2 with bcfg2-accounts to distribute authorized_keys. As added bonus, you'll have ability to control users and groups.

Bcfg2 enables pain-free maintenance of /etc/ssh/ssh_known_hosts with SSHbase as well.

myroslav
  • 171
  • 7
1

There's also SKM

andsens
  • 361
  • 4
  • 10