Managing multiple SSH private keys for a team

Not sure why you're using AWS-created keys. The "Network & Security / Key Pairs" screen also has an "Import key pair" button, I've successfully used it.

When you add a new team member who might be standing up new images, get his public key, import it.

Keep a copy of your standard "authorized_keys" file, with one or more public key per person, on a webserver or S3 (could be VPN-facing, or secured by a team-shared username and password, if you're trying to keep your team identities confidential.) Now part of your deploy process is to do

curl -u username:password \
  https://team-server/private/authorized_keys.txt >/home/ec2-user/.ssh/authorized_keys

(Such a command could also be added to the instance user data to run at instance creation.)

To add a new team-member, add his public key to the file, then run that command on all servers.

To remove a team-member, remove his key from the file, then run that command on all servers.

After re-reading all this, I insist : having root access granted to many users directly is generally a not so good idea. Use sudo is the recommended way (you could even run su, with group restriction).

Why not use Un*x group original behaviour?

• For each user, add a specific account ( you could manage user account replication by using LDAP, NIS or even rsync on your passwd, group, shadow and *$USER/.ssh/authorized_keys by a simple shell script... NIS is nice! )

  adduser alice
  

• Add specific passwd to each user (user may or need to change them... or not)

  passwd alice
  

• Add user to group with specific right (to acccess sudo, for sample)

  adduser alice sudo
  

• Doing so, you could create another group with common right, for working together on specific project, even without access to root.

Doing this way let the ability to

• let user connect without passwd, but only on his account. Then ask user for password when they run sudo.

  su - alice <<<eocmd
     curl -u username:password \
        https://team-server/private/authorized_keys.txt >.ssh/authorized_keys
  eocmd
  

• add or delete as many user you want

  deluser alice
  

• drop or restore rigth to

  • access to any host/server

    usermod --expiredate 1 alice
    

  • access to specific group rights.

    deluser alice sudo
    

• keep specific authorized_keys for each user, for sample

  su - alice -c 'curl ... >>.ssh/authorized_keys'
  

  to permit one user to connect from many different points. In fact, as each authorized_key file is owned by his user, each could do what he want, without compromising whole host.

... and keep PermitRootLogin to no in /etc/ssh/sshd_config!

Maybe a solution such as FreeIPA could help you. It provides a way to make sure that ssh keys are properly distributed as well as sudo profiles and authentication.

Z.

A typical best-practices answer would be to use something like LDAP. With it, you can define users, groups, and more.

By connecting your SSH authentication backend via PAM to your LDAP server, you can maintain separate accounts for each member of your team. I may be mistaken, but you should also be able to maintain separate $HOME/.ssh/authorized_keys files for each user as well.

By making users members of the sudoers group, they'll be able to request root permissions on-demand. These accesses will be recorded in logs, so you'll have auditability later on down the line.

This setup is pretty standard in larger corporations.

When I need to distribute public ssh-keys on my servers, I use an online tool (https://keydistributor.io) and fetch the keys on each server from their API. In that tool (just like Puppet, chef etc) I could define groups, where each user belongs to a group.