By Philip Knerr

Introduction

By default, Amazon EC2 instances have only a single user, named ec2-user. It is more secure for each individual person who needs to use the EC2 instance to have their own account. Creating individual accounts has the following advantages:

• Each account can be granted only the permissions which the account owner needs to do their job. For example, a back-end developer may need access to a database. A front-end developer may eschew access to this database, but they may need to change static files and execute a build process.
• Actions taken on Linux-based systems are usually traceable to a specific account. Thus, if each account belongs to a specific person, actions can usually be traced to a specific person.
• If an individual leaves the organization or otherwise no longer needs access, that individual’s account can simply be disabled without impacting any other user of the system.

The context and caveats in the Foreword apply to this article.

This information is current as of July 13, 2017.

Requirements

This article assumes you have already instantiated an Amazon EC2 instance on which you would like to create one or more users.

Key pairs

Each user of the system needs their own key pair. A key pair includes both a private key and a public key. The private key is intended to be possessed only by the party to whom the key pair belongs. The public key may be freely shared with other parties. Notably, the public key can be used (along with an encryption algorithm) to confirm that a party possesses the associated private key.

When a key pair is used for authentication via SSH, the public key is installed on the remote system to which the user authenticates. The private key is installed on any local device which the user uses to connect to the remote system. The private key is not installed on the remote system.

Creating a key pair for the new user

The steps in this section may be performed on any of:

• The remote system where the user is being created.
• A local system belonging to the user being created. This is actually optimal because it causes the private key to be generated on the system where it belongs. However, it requires access to this system or a user who knows what they are doing.
• Another system, e.g., the workstation of the administrator who is creating the new user. This is suboptimal because both the private key and the public key will need to be moved elsewhere.

These commands should work similarly on a local system which is based on another flavor of Linux, the macOS (or OS X) operating system, or a *nix operating system.

If the user does not already have a key pair, create one by executing the following command:

ssh-keygen -t rsa -f <filename> -C '<comment>'

For example, to create a key pair with a name of bob_id_rsa and a comment of Key pair for Bob, you could execute the following command:

ssh-keygen -t rsa -f bob_id_rsa -C 'Key pair for Bob'

N.B. The comment is optional, but it is recommended so as to identify the purpose of the key pair.

You will then be prompted for a passphrase. The output should look like this:

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 

The passphrase may optionally be omitted, but this is less secure. If a passphrase is specified, it must subsequently be entered to use the key pair. This effects two-factor authentication. Both the key and the passphrase are required to authenticate. The first factor is the key, which is something you have. The second factor is the passphrase, which is something you know.

After entering the passphrase, the output should look like this:

Your identification has been saved in bob_id_rsa.
Your public key has been saved in bob_id_rsa.pub.
The key fingerprint is:
e2:dd:97:e2:97:a2:95:98:d0:a4:7d:e4:ca:47:90:99 Key pair for Bob
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|         +       |
|        E .      |
|       = +       |
|      + S +      |
|     . = B . .   |
|      . * * o.   |
|         +.oo    |
|        ...o     |
+-----------------+

As noted in the output above, the private key will have the specified filename. The public key will have the same filename, followed by the suffix, .pub.

Creating the new user

Create the user by executing the following command on the system where the user should exist:

sudo useradd <username> --comment '<comment>'

For example, to create a user with a username of bob and a comment of Bob the Test User, you could execute the following command:

sudo useradd bob --comment 'Bob the Test User'

N.B. The comment is optional, but it is recommended so as to identify who the user is in real life.

If the user was created successfully, no output will be returned. You can view the /etc/passwd file to confirm that the new user exists.

Installing the public key of the new user

All of the following commands should be executed on the system where you just created the new user. Moreover, in all of the following commands, <username> should be replaced by the username of the new user.

Create a directory for files related to SSH for the new user by executing the following command:

sudo mkdir ~<username>/.ssh

N.B. The tilde character (~), followed by a username, indicates the home directory of the specified user. This is important because on some systems, user home directories may not be placed in the /home directory, even though that is customary on Linux systems.

Ensure that only the owner of this directory can read the contents thereof:

sudo chmod 700 ~<username>/.ssh

Copy the public key to a file named authorized_keys in this directory so that the user can authenticate. To do so, execute only one of options (a) and (b) below.

(a) If the public key was created on this system, it can simply be moved by executing the following command, where <filename> is the same value previously provided to ssh-keygen:

sudo mv <filename>.pub ~<username>/.ssh/authorized_keys

For example, if the key pair was generated as in the example above, you could execute the following command:

sudo mv bob_id_rsa.pub ~bob/.ssh/authorized_keys

(b) If the public key was created anywhere else, upload the public key and store it in this file. This can be done via SFTP. Another option is to edit this file with a text editor and copy and paste the public key into the text editor. For example, to edit this file for the username bob using the nano text editor, you could execute the following command:

sudo nano ~bob/.ssh/authorized_keys

In either case, ensure that only the owner of the new public key file may access it. Execute the following command:

sudo chmod 600 ~<username>/.ssh/authorized_keys

Grant the new user access to their own SSH directory and public key file by executing the following command:

sudo chown -R <username>:<username> ~<username>/.ssh

Providing the private key to the new user

The private key file should be transmitted to the new user, unless the new user generated the key pair themselves. This can be done via SFTP. Because the private key is simply text, it can also be displayed using a text editor or the cat command and then copied and pasted. For example, you could execute the following command if the private key was named as above:

cat bob_id_rsa

Warning: Care should be taken to avoid unencrypted channels such as email. Sophisticated attackers may be able to intercept unencrypted communications, and anyone who has a user’s private key can impersonate that user.

The private key file should then be stored on all local systems or devices which the user will use to connect to the remote system.

The private key file should only be readable by the user to whom it belongs. Otherwise, any other user of the same local system could read the private key and use it to impersonate that user. Therefore, on any system where the private key was stored, restrict permissions on the private key to the user themselves by executing the following command:

chmod 600 <private-key-filename>

In the above command, <private-key-filename> is the filename of the private key on the local system.

Unless the new user generated the key pair themselves, the private key file should be deleted from the system on which it was created. It is not needed on the remote system. In fact, it reduces security if it exists there. There is no benefit, and it could be used to impersonate the user.

Connecting as the new user

The new user should execute the following command to authenticate (log in):

ssh -i <private-key-filename> <username>@<hostname>

In the above command:

• <private-key-filename> is the filename of the private key on the local system.
• <username> is the username of the new user on the remote system.
• <hostname> is the hostname or IP address of the remote system.

For example, Bob from our previous examples could execute the following command:

ssh -i bob_id_rsa bob@34.228.34.124

The new user may want to create an alias on their local system to greatly reduce the number of keystrokes needed to authenticate. For example, if Bob uses the bash shell, he could add the following line to the .bash_aliases file in his home directory on his local system:

alias ssh-bob='ssh -i bob_id_rsa bob@34.228.34.124'

N.B. This alias will only be available in shells which are opened after the line above is added.

Conclusion

The new user you just created can now authenticate to the system.

You can repeat the steps above to create as many users as you need, within reason. In fact, you should repeat these steps for each individual person who needs access to the system.

–Phil Knerr