SSH public key authentication under Ubuntu

From Thomas-Krenn-Wiki
Jump to: navigation, 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.

Generate keypair

In the first step, a key pair with ssh-keygen is created at the client. For the RSA keys, a size of 4096 bits is selected:

:~$ 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

Author: Thomas Niedermeier

Related articles

Check the Ubuntu version
Configure Locales in Ubuntu
Fixing Graphics Output Driver Problems of LES with newer Linux Kernels