Intro:

Utilizing SSH keys as an alternative method to accessing a Linux server is a much more secure method than relying on a password to authenticate (and can actually be set up to also use a password as well, as seen below). The process involves generating a pair of key files containing long strings  – private and public – which, when matched up, provide access without the need for a password. The private key is stored on the client side of the connection, with the public key being provided to the receiving party without giving the private key itself away.

Step 1 – Generate and save the SSH key file:

The first step to setting up SSH keys is to generate the keys needed to authenticate the connection. This can be done by using the ssh-keygen command, with an example shown below:

test@demo:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/test/.ssh/id_rsa):

There are multiple flags that can be used when generating the key pair, but for many cases just using -t will suffice. This designates the specific protocol type to use, which would be Protocol Version 2 (SSH-2) in this case. After hitting Enter once, just hit it again unless you’d like to specify a separate name for the file to store the key within. That should provide the following output to stdout:

Created directory '/home/test/.ssh'.
Enter passphrase (empty for no passphrase):

At this point, you can select enter again, however if you would like to utilize added security with your key-pair you can choose to add a password at this point that must be used to allow access even after the key-pair has matched and hit enter to proceed.

Enter same passphrase again:

Either hit enter again, or re-enter the password that you entered previously.

Your identification has been saved in /home/test/.ssh/id_rsa.
Your public key has been saved in /home/test/.ssh/id_rsa.pub.
The key fingerprint is:
3f:d0:d0:9b:e1:b1:4f:b7:d9:2c:5b:01:67:41:cc:b4 test@demo
The key's randomart image is:

+--[ RSA 2048]----+
|              =+ |
|             . oo|
|           + . E |
|           + * + |
|          * . .. |
|         o o . =.|
|          o . + +|
|             . + |
|               . |
+-----------------+

At this point, your key has been saved. at the default location (or within a separate file if you chose to do so) and you can see the randomart image associated with the key. Generally, this isn’t utilized in and of itself, but in case you were curious, you can add the following string to any future SSH connection attempts:

-o VisualHostKey=yes

If you’d like to verify the validity of your connection yourself based off the randomart image provided in the output when connecting to your server in the future. This allows you an easier method of verifying that the image is familiar to ensure that you aren’t subject to a man-in-the-middle attack, though generally isn’t used often and does not appear by default.

Step 2 – Transfer the public key file to the receiving server

Option A:

The easiest method of transferring the SSH public key to the receiving server/computer is by just using a the ssh-copy-id command.

ssh-copy-id [email protected]

Or as an example using the direct IP address and a non-standard – read: not 22 – port:

ssh-copy-id [email protected] -p 3050

The -p flag allows you to specify the specific port after the command, which in this case would be 3050.

Option B:

Alternatively, you can utilize multiple separate commands together to string together something like the following:

cat /home/test/.ssh/id_rsa.pub | ssh [email protected] "mkdir .ssh && cat >> .ssh/authorized_keys && chmod 0600 .ssh/authorized_keys"

The command above pipes (or passes) the contents of the public key file you previously generated via SSH to an authorized keys file located in the .ssh/ subdirectory of the receiving user’s home directory. Specifically, this example takes into account that the .ssh/ directory and authorized_keys file have not been created yet and creates them during the process. The very last command – starting at chmod – modifies the permissions of the file to ensure that it’s only readable and writable by the target user themself, rather than any other users on the system.

At this point, you should be able to test the login to the new server and select yes when asked if you accept the key fingerprint (if this is your first time connecting and you’re certain it’s the proper server), at which point you will either be logged on immediately or prompted for the password that you had generated during Step 1.

Recommended man page reading:

ssh-keygen

ssh-copy-id

ssh