SSH public key authentication under Ubuntu

From Thomas-Krenn-Wiki
Jump to navigation Jump to search

This article shows how to configure a SSH connection for authentication by using the public-key method. To do this, a key pair is created at the client, the public part of the key is transferred to the server, and afterwards the server is set up for key authentication. The user can log on to the server without a login password, only the password is required to protect the private key. The operating systems used in this article are on the one hand a Ubuntu 12.10 at the client side and a Ubuntu 12.04 at the server side. This guide was also validated working with Ubuntu 16.04 as client and server.

On the client

The first configuration steps take place at the client side.

Home folder rights

By default, Ubuntu sets the user home directory permissions to 755. Nevertheless, for security reasons, check whether the permissions are set to 755 on your system and change them if necessary:

:~$ sudo chmod 755 /home/<USER>

Generate keypair

In the first step, a key pair with ssh-keygen is created at the client. If you use Ubuntu 18.04 on the server, the package openssh-server will be installed in the version 7.6.[1] Since this version, RSA bit lengths smaller than 1024 bits are no longer accepted.[2] In this example, a bit length of 4096 bits is selected for the RSA keys:

:~$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gschoenb/.ssh/id_rsa): /home/gschoenb/.ssh/key_rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/gschoenb/.ssh/key_rsa.
Your public key has been saved in /home/gschoenb/.ssh/key_rsa.pub.
The key fingerprint is:
20:69:c5:c3:e2:2d:a8:09:49:b9:d9:ee:ca:f9:45:5e gschoenb@gschoenb-X220
The key's randomart image is:
+--[ RSA 4096]----+
|  .  o.          |
| o  .o+          |
|..+o+o..         |
|oo.oo...         |
|.o.  o ES        |
|o  .o .          |
|  .  o           |
|. ...            |
| +o.             |
+-----------------+
:~$ ls .ssh/
id_rsa  id_rsa.pub  key_rsa  key_rsa.pub  known_hosts  known_hosts.old

Please note: It is recommended to protect the key with a passphrase for security reasons. This means that the key is not available in plain text, but is AES-CBC encrypted:

:~$ cat .ssh/key_rsa
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,426FD49B9F6277AC00D62B08547D5FDE
[...]

If the private key is stolen by an attacker, he has to find out the password of the key in order to access the server with the key. If the key is available in plain text, an attacker can use this stolen key to directly access the server.

Transfer the public key to the server

To transfer the public key to the server, the first step is to use the SSH connection via password authentication yet. The ssh-copy-id tool copies the corresponding identity file to the server:

:~$ ssh-copy-id -i .ssh/key_rsa.pub tktest@192.168.56.101
tktest@192.168.56.101's password: 
Now try logging into the machine, with "ssh 'tktest@192.168.56.101'", and check in:

  ~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

The above-mentioned procedure has created the following entry in the /home/tktest/.ssh/authorized_keys on the server:

:~$ cat .ssh/authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC7qmegDxzv1omqG2cWM+i+qaEGzCoSBwqCeXyGUU93sTqtNYYHJVGj6YZqXeXEGzJtKm2A/uo59Y+WmqhJgW7HcT2Hqvo80NfbIRhqE9TJETyBe
GiiC8qpiYgPC2zigCNvTsRXh0CH5FJ1qy4QEBjztQDWOqSrsoOSJEEWCJiKJizTiXDmlGdiKE409GBo8lvlbMRWbrMj3iX825WTqy/T0Pio1kqANDotLnPA0sRXUPVyzc/ghzqRHzFetzP9j7C0nh
EvjiJphiuYvhbgix79FrCQG0lXBGcAWzsWUeAoT/d3kQu79+UTWxm+z4pnJ7gkKVMejqrWys560SdAqD264dc5UBRGI9j6XxVKdraSaEitDneONrSAt2tE/RwRxh2ASxqQfdF88zyDI8/ma608tHc
FROaNsn5hF+/wzjRK9akdhp5WjA5HXhg2OlkwKvSMhGlSgotRj5pr4Ebxjegysy1mEWRFN/vh/oNq4uHQy8adpfogaVELkI/Z2nuAdQk+uMy6D1hrKhUWubmBPxTbG00IWF25Tyuz8hnFRP9+gB/P
NRlF59/EHy27a72nirvuOyfxKnx/Mn+FD9Ah59OSLhWuo3sN9Im8yc2cliecwMz+DmTtE7TwzNw9v2zfxU9JDQwyLtppULiGpmKFOLHjz+SVGxSbVsWS//IyNK1GrQ== gschoenb@gschoenb-X220

Test the key authentication

Now that the public key is transferred to the server, the connection can be tested from the client. In this case, it is important that the server does not ask for the user password, but of course the passphrase of the protected key is required!

:~$ ssh -i .ssh/key_rsa tktest@192.168.56.101

The following dialog box appears for GUI-based systems:

OpenSSH-Public-Key-Dialog.png

After entering the password that protected the key when it was created, you are authenticated on the system:

:~$ ssh -i .ssh/key_rsa tktest@192.168.56.101
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-23-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Thu Jan 17 13:51:19 CET 2013
[...]

On the server

This paragraph shows some additional configuration steps on the server side to harden the public-key authentication.

sshd configuration

In Ubuntu, it is generally sufficient to carry out the above-mentioned procedure for public-key authentication. In some situations it makes sense to deactivate password authentication completely.

Please note: After changing the following setting, it is no longer possible to log in with a password via ssh: PasswordAuthentication no.

:~$ sudo diff /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
51c51
< PasswordAuthentication no
---
> #PasswordAuthentication yes

From the client, the connection is tested again:

:~$ ssh -i .ssh/key_rsa tktest@192.168.56.101
Agent admitted failure to sign using the key.
Permission denied (publickey).

In the above example, the dialog for entering the key password has been aborted. Since the log-on via password was deactivated, it was not possible to log-on to the system.

Forbid password authentication for just one user

Another way in which password authentication is not completely deactivated is to disable password authentication for specific users. This allows a user who does not have sudo privileges to log on to the server, for example. To gain root privileges, at least one additional password must be found for a user with sudo privileges. Plus, there's a way to completely exclude users from ssh:

:~$ sudo diff /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
88,91d87
< 
< DenyUsers test
< Match User tktest
<     PasswordAuthentication no

This example:

  • Prohibits SSH access for the user test
  • Deactivates password authentication for the user tktest
  • Password authentication is retained for all other users

Notes for other distributions

For other Linux distributions, the required steps may differ slightly. We would be happy to supplement our experiences with other distributions, which you are welcome to share with us via the feedback function.

Red Hat

One reader told us that the procedure described Red Hat does not work 1:1 in Red Hat. In the home directory of the user, the write permission was set for the group. After a chmod 755 it worked to connect via ssh to the server without asking for a password.

References


Foto Thomas Niedermeier.jpg

Author: Thomas Niedermeier

Thomas Niedermeier working in the product management team at Thomas-Krenn, completed his bachelor's degree in business informatics at the Deggendorf University of Applied Sciences. Since 2013 Thomas is employed at Thomas-Krenn and takes care of OPNsense firewalls, the Thomas-Krenn-Wiki and firmware security updates.


Related articles

Check the Ubuntu version
Installing Ubuntu 20.04 via a serial console
LES v3 with three displays under Windows and Ubuntu