Getting started with OpenSSH

From the console, I'm going to stop the SSH service-

root@twentymachines.net:/# 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.

root@twentymachines.net:/# cd /etc/ssh
root@twentymachines.net:/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
root@twentymachines.net:/etc/ssh# rm ssh_host_*

Now to force the openssh-server package to generate new keys using dpkg-reconfigure-

root@twentymachines.net:/# dpkg-reconfigure openssh-server
Creating SSH2 RSA key; this may take some time ...
2048 SHA256://oRt9KLv3HhyQv48en61M/Ru+68M7MuXwOvqm4A8TY root@twentymachines.net (RSA)
Creating SSH2 ECDSA key; this may take some time ...
256 SHA256:vu9A6d9kVnyfYASAR3o9+jmXHnwV2napmgcJTPSCne0 root@twentymachines.net (ECDSA)
Creating SSH2 ED25519 key; this may take some time ...
256 SHA256:+Jmqmgm+LGk4XU0PwRd0Oun3o8CiLoD5wh0MZPEvDJY root@twentymachines.net (ED25519)

Next, I'm going to create a new user who does not have root privileges.

root@twentymachines.net:/# 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] ([158.69.215.97])' 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
kieran@twentymachines.net's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'kieran@twentymachines.net'"
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-

PermitRootLogin no

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-

AllowUsers kieran

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.

AuthenticationMethods publickey,password

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.


Tags: [System Administration] [Linux] [OpenSSH]

Category: [Blog]