In this example, there are 2 machines, a client and an OpenSSH server. We will configure both machines so that John Doe can make an SSH connection to the OpenSSH without having to provide his password. SSH is kind of unique, as the public certificate is placed on the OpenSSH server, and the private key is then used to connect to the SSH server. In this example, John Doe would be responsible for maintaining the security of his private key.

Client

Enter the users hidden .ssh directory.

~]# cd /home/JohnDoe/.ssh

In this example, ssh-keygen is used to create the public certificate and private key. The public certificate is named id_rsa.pub, and the private key is id_rsa.

ssh-keygen -t rsa

Configure the .ssh directory so that only JohnDoe has read/write/execute permission, and configure the public/private key pair so that only JohnDoe has read/write permission.

~]# chmod 700 /home/JohnDoe/.ssh
~]# chmod 600 /home/JohnDoe/.ssh/id_rsa
~]# chmod 600 /home/JohnDoe/.ssh/id_rsa.pub

OpenSSH server

On the Linux OpenSSH server, create the authorized_keys file. The authorized_keys file will contain one or more public certificates.

~]# touch /ech/ssh/authorized_keys

Ensure the authorized_keys file can only be read and written by the owner of the file.

~]# chmod 600 /etc/ssh/authorized_keys

Give the authorized_keys file an owner (JohnDoe in this example).

~]# chown JohnDoe /etc/ssh/authorized_keys

Copy the private key from the client to the OpenSSH server. Replace "client" with the actual hostname or IP address of the client machine.

~]# scp JohnDoe@client:/home/JohnDoe/.ssh/id_rsa.pub /etc/ssh

If the SELinux context authorized_keys file is not system_u:object_r:ssh_home_t:s0, restore the context.

~]# ls -Z /etc/ssh
-rw-------. root root system_u:object_r:ssh_home_t:s0 authorized_keys

~]# restorecon -FRvv /etc/ssh

Use the paste command to append John Doe's public certificate to the authorized keys file.

~]# paste -s -d '\n' /etc/ssh/id_rsa.pub >> /etc/ssh/authorized_keys

Configure your /etc/ssh/sshd_config file to have the following settings.

PermitRootLogin        without-password
PubkeyAuthentication   yes
AuthorizedKeysFile     /etc/ssh/authorized_keys
GSSAPIAuthentication   no

Restart SSHD.

~]# systemctl restart sshd

Now the OpenSSH server has a way to authenticate the client. When the client requests the connection using the private key, the OpenSSH server has the corresponding public certificate.

Make the SSH connection without a password

If connecting using the ssh command, use the -i option followed by the path to the private key.

~]# ssh -i /home/JohnDoe/.ssh/id_rsa root@OpenSSH

If using PuTTY, add the private key to PuTTY.

1. Launch PuTTY.
2. In the left panel, expand +SSH and highlight auth. 
3. Enter the path to the private key.

Disable password and GSSAPI authentication

By default, both PuTTY and the OpenSSH server are configured to use password and GSSAPI authentication. To reduce the attack surface, password and GSSAPI authentication can be disabled, since a public private key pair are being used.

1. In PuTTY, expand Connection > SSH > Auth and select GSSAPI.
2. Remove the tick from Attempt GSSAPI authentication (SSH-2 only)

In the /etc/ssh/sshd_config file on the OpenSSH server, make the following configuration:

GSSAPIAuthentication no
PasswordAutehentication no

Log files

For absolute assurance that only a public private key pair are being used for authentication, and that password and GSSAPI authentication have been disabled, view the PuTTY log file.

1. In PuTTY, select Logging, and select the following:
   • SSH packets and raw data
   • Type the path to the file that will contain the log data
   • Remove the tick from Omit known password fields

Connect to the OpenSSH server, and then open the log file. In the log, the first outgoing packet from the client to the server is ....root....ssh-connection....none, and the incoming packet from the server to the client is ....publickey.....

• publickey means that the server is configured to allow the use of a public key for authentication requests.
• none means that no public key was provided in the request.

Because no public key was provided, the SSH server failed to authenticate the request. This is normal, and not suggestive of some problem. By default, PuTTY makes the first authentication attempt with no public key. Notice publickey and ssh-rsa in the last attempt.