Home / server / Questions / 914046
Accepted
David542
Asked: 2018-05-28 19:24:43 +0800 CST

Suggested practice for adding/removing user accounts in Amazon EC2

  • 772

I have an AWS ubuntu server. Let's call the Key File "root-key.pem".

Let's suppose (for this example) that I have ten employees and we add a new employee every month and we let go of an existing employee every month. What would be the suggested way to enable users to access the server with admin credentials? They would need to be able to run sudo or have something like root privileges to be able to modify databases, ports, push/pull to git, etc.

  1. The 'easiest' way to do this would be to give everyone access to the "root-key.pem" file, but then whenever an employee is let go, we would need to create a new file and then make sure all existing employees have access to it (and perhaps any down time where a developer may not have access to it, or be waiting on it, etc.).

  2. The preferred way I think would be to create a user for each person (sudo adduser travis) and then add them to the sudoers file and add their pem key to .ssh/authorized_keys. This is the path I tried to implement. It works in that it gives the user access to the server and they can run sudo, however it's a nightmare when people are trying to push/pull to git (GitHub).

What would be the best way to accomplish #2? Or is this a very difficult item to implement, and #1, though it is a bit sloppier and inconvenient when someone is let go, is the preferred way to go for all but very large organizations?

linux

2 Answers

  1. You should have a key rotation strategy for your root-key.pem anyway. In the event someone potentially loses this key. However, number 2 is generally the right way to go about this. Credential sharing should never be the recommendation although I dont doubt it happens often. There are a lot of ways to potentially implement and manage number 2. Some type of directory service is the most common, but it isnt the only option. You should consider some type of configuration management to handle either 1 or 2 so that it reduces the overhead for your team.

    • 1
  2. Best Answer

    Generally Speaking go for the #2.

    In #1 when someone compromises the key every user has to rotate keys, instead if everyone has his own key only the affected user needs to do it and can be removed from the admin group.

    Also in #2 you avoid to manage and transfer private keys, everyone can use is personal keys and you only need to know the public part.

    Yet #2 is easily scriptable if you have programmatic access to the users public keys you can build an script or use some configuration management software to retrieve it from a public server. For example the public keys of a github user are exposed in https://github.com/<user>.keys you can write a script that grab the github keys, write on the associated authorized_keys of the user and give the user admin privileges only knowing your user's github names.

    • 1