User key management on an average number of GNU/Linux servers

E

ergil2012-02-10 16:35:03

linux

ergil, 2012-02-10 16:35:03

Actually, we have, let's say, about 100 servers on which we must have a certain set of users, their entrance is purely by keys.
Adding users is not a problem, dsh will help us and add one command at least on all 100 servers.
But something sad happened to us, for some reason one of our users changed his key, it doesn’t matter if he lost his secret part or for some other reason, but changed it. Who can suggest what options for centralized management?
The first ideas that came to mind were all sorts of puppets and storing user keys not in ~, but in /etc/ssh/%user_name and, accordingly, unfolding.

Does anyone have any other ideas/options? Maybe someone already had a similar problem?
Do not offer the idea of users in LDAP and Co and centralized storage and access with a password, the idea of NIS + NFS and mounting ~ over the network from one place too.

Reply

Answer the question

In order to leave comments, you need to log in

4 answer(s)

D

DmZ, 2012-02-10
@DmZ

Who is stopping you from storing the key in ~/.ssh/authorized_keys via puppet?
This is how we implemented it (albeit through chef) - a list of users, a list of keys associated with them, and authorized_keys is overwritten if the list has changed.
No problems - the key has changed, you changed it for the user, the change has spread to the servers. At the same time, the old keys were rubbed so that there was access control.

V

Vlad Zhivotnev, 2012-02-10
@inkvizitor68sl

Deb bags. You can store the truth in one directory to make it more convenient and you only need to deploy one package.

@

@mgyk, 2012-02-11
_

Repository with keys and chef/puppet which deploys keys from it to all servers. + keys are not dragged behind puppet, there is a history of who added what key and when

S

svk, 2012-02-11
@svk

There is a patch for openssh in nature, which adds the AuthorizedKeysCommand option to the config, and allows you to take the key not from a file, but from the stdout of an arbitrary program or script. What opportunities this opens up, I hope, it is not necessary to explain. In normal server operating systems (RHEL, CentOS, OEL, etc.) this patch is already included in the mainstream.