SSH public key authentication under Ubuntu
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:
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
- ↑ Package: openssh-server (1:7.6p1-4) (packages.ubuntu.com)
- ↑ OpenSSH 7.6 Release Notes (openssh.com)
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.
|