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-keygen
creating 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 ----- BEGIN RSA PRIVATE KEY ----- 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-id
copies the corresponding Idendity 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 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@192.168.56.101
: ~ $ 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
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 51c51 <PasswordAuthentication no --- > #PasswordAuthentication yes
The connection is tested again from the client :
: ~ $ ssh -i .ssh / key_rsa tktest@192.168.56.101 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 88,91d87 < <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.
0 Comments