How to use SSH keys for passwordless access to hosts

I work in a largely Linux shop, and I frequently have to hop on numerous remote systems to do my job. Logging in the traditional way with my ID and password can be cumbersome, and when working with scripting to deploy files or gather information from hosts I definitely don’t want to type in a password over and over.

Here’s where secure shell, or SSH, keys come in handy to facilitate access. I rely on them every day for quick and easy access to the hosts I support. While I use them exclusively on Linux servers, this access is also available to Windows systems that utilize OpenSSH or some related service or application. Cygwin runs on Windows and has an available SSH server component and you can also use OpenSSH on Windows 10 and Windows 2019. 

SEE: 20 good habits network administrators need–and 10 habits to break (free PDF) (TechRepublic)

SSH keys involve a public/private key pair which can be used for secure access to remote systems without the hassle of entering a password to authenticate. The private key resides on the source system, and the public key is configured on the target system via the methods I’ll explain in this article.

A mere user account might not have the root access needed to perform these functions, so I have set this up for root accounts to be able to easily hop from one system to another with zero fuss. However, this process applies to user-level accounts as well, so long as the account name is the same on the source and target servers.

Of course, there is a danger in this that all IT professionals should be aware of. An unguarded system can provide an unauthorized user access to other systems. If your private key is stolen, someone could gain unauthorized access to the servers that permit the account to connect via SSH keys.  

Human error is also always a potential pitfall. If you inadvertently connect to the wrong system to make a change (e.g. reboot the server or delete an SSL certificate file) this could negatively impact that system. And when running commands as root you must always double- and triple-check your work in advance.

The beauty of Linux is there are numerous ways to achieve the same objective, and one way is generally just as good as another. My colleague Jack Wallen wrote a helpful article on the topic in 2017. Here’s how I’ve set this up for my day-to-day tasks.

SEE: 5 Linux server distributions you should be using (TechRepublic Premium)

First you must create a public/private RSA key pair. For the purpose of this article, I’ve created an account called “testuser” on the source system and have logged in with this ID.

Run this command:

ssh-keygen

You will see the following output:

Generating public/private rsa key pair.

Enter the file in which to save the key (/usr/local/litle-home/testuser/.ssh/id_rsa):

Press enter to accept the default.

Created directory ‘/usr/local/litle-home/testuser/.ssh’.

Enter passphrase (empty for no passphrase):

You can choose to enter a passphrase or press enter to leave this blank. If you choose the former option that means you will have to type that passphrase in every time you connect via SSH to the target server, which defeats the purpose of avoiding entering credentials to connect. 

Enter same passphrase again or hit enter to leave blank.

You will see output similar to the following:

Your identification has been saved in /usr/local/litle-home/testuser/.ssh/id_rsa.

Your public key has been saved in /usr/local/litle-home/testuser/.ssh/id_rsa.pub.

The key fingerprint is:

a2:68:c9:de:41:69:e4:fd:6c:60:38:4d:3d:54:83:d5 testuser@devsrv1

The key’s randomart image is:

+–[ RSA 2048]—-+

|        .++.     |

|       o.  .E    |

|    . . o        |

|   o *   .       |

|    B * S        |

| . = + =         |

|  = o   +        |

| o . . .         |

|  . .            |

+—————–+

[testuser@devsrv1@noVapModule]

This process just created a public/private key pair for you under the account’s home directory in the .ssh subdirectory.

The id_rsa file is the private key. Do not copy this elsewhere.

The id_rsa.pub file is the public key. 

Now you’ll need to copy the contents of the new public key in order to configure access on the target system.

cat ~/.ssh/id_rsa.pub

You will see output similar to the following:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA5NiGhZo+yDJdNkAcbxb5lqPNTCyAOPaHmoajE0mXIO6i5Vbw70zsAnxZK6bMGbIAp9H+4kl8/9BteC/ed2STsyo3/sFV6jH+mePbA/dWSWpKeVFSr+nKQkZo5+upe50W/KchKV1lFdMJLJLFYMjMiTDJW7ItnZoJ3oiCG4Pd2H1hIjk324h4ilQOrtBBd7zuajsnZ8Yzcr7xvdsPSZvSS5OJT32Lc1mFvMH9wlSD777FNZdh/QekXUKrDq3lgr96IZVxnjqG8VzGKvKinj6xNJmWdrk8oumT2LfphNQelEfHe66lVzecxTkzy4vnEeo9SFRZC0/T5c/YplYd+0c7/Q== testuser@devsrv1

Copy this entry then SSH to the target server and log in with the account and password.

Access the home directory:

cd ~

Create a subdirectory called .ssh:

mkdir .ssh

Set the appropriate permissions on the .ssh directory:

chmod 700 .ssh

Confirm the permissions are as follows:

ls -al

drwx——   2 testuser testuser 4096 May 19 08:43 .ssh

Now you need to access the .ssh directory and create a file called authorized_keys. This file permits access from the source server.

cd .ssh

vi authorized_keys

Hit i to enter insert mode

Paste in the key (generally Shift-insert or right-click and choose paste)

Hit esc then enter :wq to save and exit the file

Set the appropriate permissions on the file:  

chmod 600 authorized_keys

Confirm the permissions are as follows:  

ls -al

drwx——   2 testuser testuser 4096 May 19 08:43 .ssh

Verify the key is ready for use:

cat -vet authorized_keys

You should see output similar to the following:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA5NiGhZo+yDJdNkAcbxb5lqPNTCyAOPaHmoajE0mXIO6i5Vbw70zsAnxZK6bMGbIAp9H+4kl8/9BteC/ed2STsyo3/sFV6jH+mePbA/dWSWpKeVFSr+nKQkZo5+upe50W/KchKV1lFdMJLJLFYMjMiTDJW7ItnZoJ3oiCG4Pd2H1hIjk324h4ilQOrtBBd7zuajsnZ8Yzcr7xvdsPSZvSS5OJT32Lc1mFvMH9wlSD777FNZdh/QekXUKrDq3lgr96IZVxnjqG8VzGKvKinj6xNJmWdrk8oumT2LfphNQelEfHe66lVzecxTkzy4vnEeo9SFRZC0/T5c/YplYd+0c7/Q== testuser@devsrv1$

Run this command:

wc -l authorized_keys

You should see:

1 authorized_keys

Now test the process by connecting via SSH from the source to the target system. You should receive no password prompt and find yourself immediately logged on to the target host.

Troubleshooting

If you are still prompted for a password, ensure the correct account is the owner of the .ssh directory and the authorized_keys file on the target server. Also check the permissions and ownership on the home directory. The directory should show these permissions:

drwx——   3 testuser        testuser         4096 May 19 08:44 testuser

Also see