This article shows how SSH access is configured for public-key authentication . To do so, a key pair is created on the client, the public part of the keys are transferred to the server, and 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, an Ubuntu 12.10 on the client and on the other side an Ubuntu 12.04 on the server . The instructions were also tested under Ubuntu 16.04 as client and server .

On the client

Generate key pair

The first step involves ssh-keygencreating a key pair with the client . 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 whichever 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 random type 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

Caution: For security reasons it is recommended to protect the key with a passphrase. This means that the key is not in the plaintext, but is encrypted AES-CBC:

: ~ $ cat .ssh / key_rsa
Proc Type: 4, ENCRYPTED
DEK info: AES-128-CBC, 426FD49B9F6277AC00D62B08547D5FDE

If the private key is stolen by an attacker, the key has to find the password of the key in order to access the server with the key. When a key is present in the plaintext, an attacker can access the server directly with a stolen key.

Public. Transfer key to server

For the transfer of the public key to the server, the SSH connection is still used in the first step by means of password authentication. The tool ssh-copy-idcopies the corresponding Idendity file to the server:

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

  ~ / .ssh / authorized_keys

to make sure that you have not been expecting.

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

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

After the public. Key on the server, the connection can be tested from the client. It is important that you do not ask for the user’s password on the server, but the passphrase with which the key is protected is required!

: ~ $ ssh -i .ssh / key_rsa tktest@
After entering the password with which the key was protected during the creation process, you are authenticated to the system:
: ~ $ ssh -i .ssh / key_rsa tktest@
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

sshd configuration

Basically it is sufficient under Ubuntu to perform the above-mentioned procedure for public-key authentication. In some situations, it makes sense to completely disable password authentication.

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
<PasswordAuthentication no
> #PasswordAuthentication yes

The connection is tested again from the client :

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

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

Authenticate password authentication for one user only

Another way to disable password authentication is to disable password logon for specific users. For example, a user who does not have a sudo privilege on the server can log on to the server. In order to gain root privileges, a user with sudo rights must be found. In addition, there is the possibility to exclude users completely from ssh:

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

This example:

  • Prohibits SSH access for the user test
  • Disables password authentication for the user tktest
  • Password authentication is retained for all other users.
Categories: Tutorials


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: