Change authentication method

In the previous subsection Create RSA key we created a key pair and stored the public key on the server. Now we will modify the SSH configuration file so that the login is done exclusively with the private key.

In this subsection, we configure the key-based authentication method.

According to the current state of the art, this measure is the strongest authentication protection. It makes brute force attacks actually impossible. We will deal with the little bit of residual risk later.

But beware of quantum computers. They can decrypt cryptographic keys in acceptable computing time. However, since it is not economically viable to use the immensely expensive operating time of such computers to steal my uninteresting data, I personally am not worried about this matter (yet!). Sooner or later, this topic will certainly cause a furor.

Changing the SSH configuration

The responsible configuration file for the SSH service is /etc/ssh/sshd_config. There are a lot of configuration lines there, but most of them are commented out after a fresh Linux installation. This is symbolized by the hash (#) at the beginning of a line. A comprehensive documentation about sshd_config is available on the openbsd.org.

We open the file with sudo:


__$ sudo nano /etc/ssh/sshd_config

We are only interested in the following lines at this point:

Excerpt from /etc/ssh/sshd_config


...
#PubkeyAuthentication yes
...
#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2
...

We comment #PubkeyAuthentication yes by removing the comment symbol (#). We change the value for AuthorizedKeysFile to %h/.ssh/authorized_keys. The variable %h represents the user's home directory. When tom logs in, his user directory is searched for a public key to verify the submitted private key. In this case, in the /home/tom/.ssh/authorized_keys file. In the last chapter, we already stored a public key for tom here.

The entire /etc/ssh/sshd_config file should eventually look like this:

/etc/ssh/sshd_config


#       $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
AuthorizedKeysFile     %h/.ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem sftp  /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

Let's save the file (CTRL+s, CTRL+x) and restart the SSH service to make the changes effective:


__$ sudo systemctl restart sshd

This means that logging on to the server is possible in two ways: on the one hand, as before, with a user password and, on the other hand, with the private key. We will disable the first variant, i.e. the pure password-based login, in the next chapter. Before we do that, we should first test whether the new login method works. Otherwise, we run the risk of locking ourselves out irrevocably. So we keep the possibility open to still be able to correct configuration errors.

Let's log out first to be able to complete the test:


__$ logout

Depending on the operating system or client, the login with key varies. Below is the description for Windows, Mac and Linux.

Log in with PuTTY and private key

As usual we open PuTTY. If you have stored your connection under Sessions, select it and load it with load. Otherwise enter the server IP as described in Putty SSH connection. In the left column under Connections -> SSH -> Auth is the field Private key file for authentication. There we store the path to our key file private-key.ppk. Afterwards we change again over the left column to Sessions and save these settings with Save.

Now we can start the connection as usual with Open.

Log in with Cygwin and private key

With Cygwin you do the same as Mac and Linux users do. So with the parameter -i, followed by the path to the private key. A crucial difference is that the local file system is mounted via /cygdrive/d (for drive D):


__$ ssh tom@116.203.69.89 -i /cygdrive/d/linux-server/keys/private-key

Log in with private key on Mac and Linux

In the terminal, in addition to the username and IP, we include the -i parameter, followed by the path to the private key:


__$ ssh tom@116.203.69.89 -i ~/linux-server/id_rsa

Trust is good, control is better

It's really important that the login works before you move on to the next chapter!

Changing the SSH configuration

Testing the key-based login (Windows)

Log in with PuTTY and private key

Log in with Cygwin and private key

Testing the key-based login (Mac and Linux)

Log in with private key on Mac and Linux

Trust is good, control is better