The motivation for using public key authentication over simple passwords is security.
Public key authentication provides cryptographic strength that even extremely long passwords can not offer. With SSH, public key authentication improves security considerably as it frees the users from remembering complicated passwords (or worse yet, writing them down).
In addition to security public key authentication also offers usability benefits - it allows users to implement single sign-on across the SSH servers they connect to.
Public key authentication also allows automated, passwordless login that is a key enabler for the countless secure automation processes that execute within enterprise networks globally.
Public key cryptography revolves around a couple of key concepts. The sections below explain these briefly.
As with any encryption scheme, public key authentication is based on an algorithm. There are several well-researched, secure, and trustworthy algorithms out there - the most common being the likes of RSA and DSA. Unlike the commonly known (symmetric or secret-key) encryption algorithms the public key encryption algorithms work with two separate keys.
These two keys form a pair that is specific to each user.
In the SSH public key authentication use case, it is rather typical that the users create (i.e. provision) the key pair for themselves.
SSH implementations include easily usable utilities for this (for more information see ssh-keygen and ssh-copy-id).
Each SSH key pair includes two keys:
A public key that is copied to the SSH server(s). Anyone with a copy of the public key can encrypt data which can then only be read by the person who holds the corresponding private key. Once an SSH server receives a public key from a user and considers the key trustworthy, the server marks the key as authorized in its authorized_keys file. Such keys are called authorized keys.
A private key that remains (only) with the user. The possession of this key is proof of the user's identity. Only a user in possession of a private key that corresponds to the public key at the server will be able to authenticate successfully. The private keys need to be stored and handled carefully, and no copies of the private key should be distributed. The private keys used for user authentication are called identity keys.
The following simple steps are required to set up public key authentication (for SSH):
Key pair is created (typically by the user). This is typically done with ssh-keygen.
Private key stays with the user (and only there), while the public key is sent to the server. Typically with the ssh-copy-id utility.
Server stores the public key (and "marks" it as authorized).
Server will now allow access to anyone who can prove they have the corresponding private key.
ssh-keygen
Sample Output
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Next, you will be prompted to enter a passphrase for the key. This is an optional passphrase that can be used to encrypt the private key file on disk.
You now have a public and private key that you can use to authenticate. The next step is to place the public key on your server so that you can use SSH key authentication to log in.
Copy the public key to the remote server: Use the ssh-copy-id command to copy the public key to the remote server. This command will append the public key to the authorized_keys file in your home directory on the remote server.
ssh-copy-id user@remote_host
ssh username@remote_host
If this is your first time connecting to this host (if you used the last method above), you may see something like this:
Output
The authenticity of host (102.23.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f2:57:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes
This means that your local computer does not recognize the remote host. Type yes and then press ENTER to continue.
If you did not supply a passphrase for your private key, you will be logged in immediately. If you supplied a passphrase for the private key when you created the key, you will be required to enter it now. Afterwards, a new shell session will be created for you with the account on the remote system.
If successful, continue on to find out how to lock down the server.
If you were able to login to your account using SSH without a password, you have successfully configured SSH key-based authentication to your account. However, your password-based authentication mechanism is still active, meaning that your server is still exposed to brute-force attacks.
Before completing the steps in this section, make sure that you either have SSH key-based authentication configured for the root account on this server, or preferably, that you have SSH key-based authentication configured for an account on this server with sudo access. This step will lock down password-based logins, so ensuring that you will still be able to get administrative access is essential.
Once the above conditions are true, log into your remote server with SSH keys, either as root or with an account with sudo privileges. Open the SSH daemon’s configuration file:
sudo nano /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
sudo systemctl restart ssh
After completing this step, you’ve successfully transitioned your SSH daemon to only respond to SSH keys.
Export our Private and public keys from your server that you have used to generate them, save them in your WSL.
Install package: keychain
sudo apt-get install keychain
append to your ~/.bashrc
/usr/bin/keychain --nogui $HOME/.ssh/id_rsa
source $HOME/.keychain/$HOSTNAME-sh
** Or wherever your ssh key resides. **
Apply the correct file permissions to your keys.
chmod 600 $HOME/.ssh/id_rsa
All done, re-open your WSL and Keychain should load your SSH key and request a passphrase should you have one setup.