Published: Mar 3, 2019
From the console, I'm going to stop the SSH service-
firstname.lastname@example.org:/# service ssh stop
Since a default installation of Debian includes the OpenSSH package with the ssh service running, it also means that host keys have already been generated. Since I didn't generate them, I'm going to get rid of the existing keys as a precaution.
email@example.com:/# cd /etc/ssh firstname.lastname@example.org:/etc/ssh# ls moduli sshd_config ssh_host_ecdsa_key.pub ssh_host_ed25519_key.pub ssh_host_rsa_key.pub ssh_config ssh_host_ecdsa_key ssh_host_ed25519_key ssh_host_rsa_key email@example.com:/etc/ssh# rm ssh_host_*
Now to force the openssh-server package to generate new keys using dpkg-reconfigure-
firstname.lastname@example.org:/# dpkg-reconfigure openssh-server Creating SSH2 RSA key; this may take some time ... 2048 SHA256://oRt9KLv3HhyQv48en61M/Ru+68M7MuXwOvqm4A8TY email@example.com (RSA) Creating SSH2 ECDSA key; this may take some time ... 256 SHA256:vu9A6d9kVnyfYASAR3o9+jmXHnwV2napmgcJTPSCne0 firstname.lastname@example.org (ECDSA) Creating SSH2 ED25519 key; this may take some time ... 256 SHA256:+Jmqmgm+LGk4XU0PwRd0Oun3o8CiLoD5wh0MZPEvDJY email@example.com (ED25519)
Next, I'm going to create a new user who does not have root privileges.
firstname.lastname@example.org:/# adduser kieran Adding user `kieran' ... Adding new group `kieran' (1001) ... Adding new user `kieran' (1001) with group `kieran' ... Creating home directory `/home/kieran' ... Copying files from `/etc/skel' ... Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully Changing the user information for kieran Enter the new value, or press ENTER for the default Full Name : Room Number : Work Phone : Home Phone : Other : Is the information correct? [Y/n] y
I'm going to end my console session and switch over to my laptop now, where the first order of business is generating a public/private key pair. For sport, I decided to use the new signature algorithm (ECDSA) with the maximum number of bits (521).
kieran@thinkpad:~$ ssh-keygen -b 521 -t ecdsa Generating public/private ecdsa key pair. Enter file in which to save the key (/home/kieran/.ssh/id_ecdsa): /home/kieran/.ssh/id_ecdsa.thinkpad Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/kieran/.ssh/id_ecdsa.thinkpad. Your public key has been saved in /home/kieran/.ssh/id_ecdsa.thinkpad.pub. The key fingerprint is: SHA256:d/fAYW2lPNqKfgqMsJ2mb+PFuNXA2WORWhm+R2/R6NA kieran@thinkpad The key's randomart image is: +---[ECDSA 521]---+ | . .| | . + o =.| | * o E +| | . = + O = | | . S * + O | | + * = = + o | | . * * o . .| | oo+ o . | | .++. oo | +----[SHA256]-----+
In order to implement public key authentication I have to get the public key on to the server, and I'm going to use the ssh-copy-id command to perform this task. Note: this will be my first ssh connection to the server.
kieran@thinkpad:~$ ssh-copy-id -i ~/.ssh/id_ecdsa.thinkpad.pub twentymachines.net /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/kieran/.ssh/id_ecdsa.thinkpad.pub" The authenticity of host '[twentymachines.net] ([22.214.171.124])' can't be established. ECDSA key fingerprint is SHA256:vu9A6d9kVnyfYASAR3o9+jmXHnwV2napmgcJTPSCne0. Are you sure you want to continue connecting (yes/no)? yes
I can see the hashed fingerprint of the host key matches what was in my console session a moment ago. For this reason I can be reasonably sure this is the entity I intend on connecting to.
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys email@example.com's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'firstname.lastname@example.org'" and check to make sure that only the key(s) you wanted were added.
And now to make some configuration changes.
kieran@thinkpad:~$ ssh twentymachines.net Enter passphrase for key: '/home/kieran/.ssh/id_ecdsa.thinkpad' Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.
Settings for the ssh server are located in the file sshd_config in the /etc/ssh folder. The first line I'm going to change is-
I don't have a reason for root to be able to use the ssh service, and it can be said that by disabling root you've become a less attractive target to a portion of attackers. The next line I'll actually have to add-
Because there are few users on this system, the AllowUsers directive is best suited. Like the AllowGroups directive, this policy hardens access by adding an additional authentication layer around access.
Because the server already has my public key I can authenticate with 'something I have,' and by entering a password afterwards I can authenticate with 'something I know.' This chain of multifactor authentication is performed just as it appears in the directive. You must have the correct key pair, and if you do, then you must also know the correct password.
As an aside, I learned the difference between "password" and "keyboard-interactive" in the AuthenticationMethods directive. "keyboard-interactive" makes use of PAM, which can be utilized for more than just passwords (security tokens, one-time passwords, and more).
In order for my changes to take effect I have to restart the ssh service-
service sshd restart
To wrap up, I believe we have a secure remote access service now (provided that I keep my keys secure and check for updates regularly). Another approach I would consider using is a different combination of options for AuthenticationMethods (using PAM) and also making use of fail2ban. Thanks for reading.