Update: This isn’t actually that much better than letting them access the private key, since nothing is stopping the user from running their own SSH agent, which can be run under strace. A better solution is in the works. Thanks Timo Juhani Lindfors and Bob Proulx for both pointing this out.
At work, we have a shared SSH key between the different people
manning the support queue. So far, this has just been a file in a
directory where everybody could read it and people would
sudo to the
support user and then run SSH.
This has bugged me a fair bit, since there was nothing stopping a person from making a copy of the key onto their laptop, except policy.
Thanks to a tip, I got around to implementing this and figured writing up how to do it would be useful.
First, you need a directory readable by root only, I use
/var/local/support-ssh here. The other bits you need are a small
sudo snippet and a
My sudo snippet looks like:
Defaults!/usr/bin/ssh-add env_keep += "SSH_AUTH_SOCK" %support ALL=(root) NOPASSWD: /usr/bin/ssh-add /var/local/support-ssh/id_rsa
Everybody in group support can run ssh-add as root.
profile.d goes in
/etc/profile.d/support.sh and looks like:
if [ -n "$(groups | grep -E "(^| )support( |$)")" ]; then export SSH_AUTH_ENV="$HOME/.ssh/agent-env" if [ -f "$SSH_AUTH_ENV" ]; then . "$SSH_AUTH_ENV" fi ssh-add -l >/dev/null 2>&1 if [ $? = 2 ]; then mkdir -p "$HOME/.ssh" rm -f "$SSH_AUTH_ENV" ssh-agent > "$SSH_AUTH_ENV" . "$SSH_AUTH_ENV" fi sudo ssh-add /var/local/support-ssh/id_rsa fi
The key is unavailable for the user in question because
sgid and so runs with group ssh and the process is only debuggable for
root. The only thing missing is there’s no way to have the agent
prompt to use a key and I would like it to die or at least unload keys
when the last session for a user is closed, but that doesn’t seem
trivial to do.