Hacker News Reader

Comment by rodionos | Hacker News Reader

Org question. We use a shared key and a shared account to manage our servers. When someone leaves the team we have to regenerate the key for the account. I'm sure it's not recommended, so what's a good way to manage ssh access in a team setting? I'd like avoid sharing the key so that access can be revoked from user without regenerating the key for everyone?

View on HN

Have each team member generate his own key. Copy everyone's key in a folder and have a script to generate an authorized_keys file. Use puppet or chef (or anything else) to dispatch the authorized_keys on every server.

A single shared key is a security disaster waiting to happen.

did you read the article? ssh certificates with revokation are a much more workable solution

I wrote the article.

There's the up-front cost of setting them up, and perhaps tool support (pubkey/agent auth is widely supported; X.509...not so much).

ssh certificates are not x.509, though they are designed around a PKI.

Thanks for the correction.

SSH actually supports the usage of certificates that you can use to sign individual keys with a finite lifetime and key revocation. For some reason, very few people know about this and assume SSL/TLS whenever you say "certificates".

You can read about this in the `CERTIFICATES` section of ssh-keygen(1).

We have a shared account to manage servers as well. However, the individuals still have individual accounts, and individual SSH keys. They log in as themselves, and `sudo -iu` into the shared user. This can be done without giving the user root (i.e., sudo supports only giving access to the shared account).

It's still not a great setup, because it makes auditing a nightmare. (Unfortunately, a particular software package we use essentially requires it due to its bad architecture.)

This is interesting: http://serverfault.com/questions/653792/ssh-key-authenticati...

Reply on news.ycombinator.com