SSH

Warning:

These instructions were only tested on Debian. It will probably work for other Linux distributions, but you might need to adapt the provided instructions.

Server

Install

# apt install openssh-server

Configure

The settings of these section need to be writen in file /etc/ssh/sshd_config

Custom port

SSH server are a common target for hackers. Changing the port away from the default will greatly reduce the noise in your logs.

Port 2200

Authentication

Let's limit the users that have access to the server using ssh.

AllowUsers root myusername
PermitRootLogin prohibit-password
# Make sure you have setup authentication using keys before disabling passwords
PasswordAuthentication no
ChallengeResponseAuthentication no

Crypo

These settings are derived from secure secure shell.

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Sandbox

UsePrivilegeSeparation sandbox

KeepAlive

To make sure connections do not freeze in case of inactivity.

ClientAliveInterval 60

Generate server keys

# cd /etc/ssh
# rm ssh_host_*key*
# ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N ""
# ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N ""

Modify file /etc/ssh/sshd_config and make sure that the only lines to contains HostKey are:

HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

Publish server keys

It is possible to publish the fingerprint of your ssh server keys in a DNS server. It allows to not have to blindly trust the key on first connection.

To get the records to publish in your dns server, run

$ cd /etc/ssh
$ ssh-keygen -r $(hostname)
myserver.example.org IN SSHFP 1 1 1c47eee032179719595c8461adba051d4a00dc8f
myserver.example.org IN SSHFP 1 2 7371839b62ce52ede97a9598eea0f253e1d58f88f45a8a40e05c34a846dc2e81
myserver.example.org IN SSHFP 4 1 80aae333ad47851f788d3d9bddd87e489f8c18f8
myserver.example.org IN SSHFP 4 2 5d0511b19fcd0c2793eeda983f0a8ee70cc4868b98b6d2e67f3b97df8e480762

Once published, you can check you records with

$ dig +short -t SSHFP myserver.example.org | sort
1 1 1C47EEE032179719595C8461ADBA051D4A00DC8F
1 2 7371839B62CE52EDE97A9598EEA0F253E1D58F88F45A8A40E05C34A8 46DC2E81
4 1 80AAE333AD47851F788D3D9BDDD87E489F8C18F8
4 2 5D0511B19FCD0C2793EEDA983F0A8EE70CC4868B98B6D2E67F3B97DF 8E480762

Now you can configure your client to use your published keys.

issue.net

One of the danger when doing remote administration is to mechanically log in to a machine, type a few command and realise after that you where on the wrong server.

This doesn't happen with physical computers as they look different on first sight (either the machine itself or the place it is). The solution, make your remote servers look different.

This can be done by uncommenting this line in /etc/ssh/sshd_config

Banner /etc/issue.net

Then edit the file /etc/issue.net and make it as distinctive as possible.

Some examples:

  ************  **********   ***********   **********
  ************ ************  ************  ************
  ***          ***      ***  ***      ***  ***      ***
  ***          ***      ***  ***      ***  ***      ***
  *******      ***      ***  ************  ***      ***
  *******      ***      ***  ***********   ***      ***
  ***          ***      ***  ***   ***     ***      ***
  ***          ***      ***  ***    ***    ***      ***
  ***          ************  ***     ***   ************
  ***           **********   ***      ***  **********

   ##########   ###      ###           ###  ###  ###########
  ############  ####     ###           ###  ###  ###########
  ###      ###  #####    ###           ###  ###  ###
  ###      ###  ######   ###           ###  ###  ###
  ############  ### ###  ###           ###  ###  #######
  ############  ###  ### ###           ###  ###  #######
  ###      ###  ###   ######           ###  ###  ###
  ###      ###  ###    #####  ###      ###  ###  ###
  ###      ###  ###     ####   ###    ###   ###  ###########
  ###      ###  ###      ###    ########    ###  ###########

Note that they are 3 files quite similar for this

• /etc/issue: Displayed before login prompt on the physical consoles of the machines
• /etc/issue.net: Displayed before login prompt for remote login
• /etc/motd: Displayed after login (local and remote)

/etc/issue and /etc/motd don't need any setup before being used. Just modify the content and you are ok to go.

Other

If you are using OpenSSH < 7.2 or are not using X11 forwarding, you can disable it with

X11Forwarding no

Restart

Restarting the SSH server while connected through SSH is usually safe. However, you need to take some precautions to avoid being locked out of your server. Make sue you do that from a stable internet connection: in case your SSH server doesn't restart correctly, you don't want your active SSH connection to drop while you fix the issue.

# systemctl restart ssh

If you are connected through SSH, test that your server restarting correctly by opening a second connection

$ ssh -o "ControlMaster=yes" myserver.example.org

The -o "ControlMaster=yes" option prevents the SSH client from reusing your active connection in case you have multiplexing enabled.

Fail2Ban

Fail2Ban configuration for SSH is active by default in Debian. However, if you changed the listening port of your server, you must reflect that in Fail2Ban. To do so, create file /etc/fail2ban/jail.d/sshd.conf with the following content

[sshd]
enabled  = true
port     = 2200 ; <= Set the port here

Client

Install

# apt install openssh-client

Configure

The settings of these section need to be written in file /etc/ssh/ssh_config. Unless they contains a Host, they must be set under the existing Host * section.

Shortcuts

When it comes to typing, my motto is less is more. The following setting allows you to type ssh server1 instead of ssh server1.example.org

Host server1 server2
    CanonicalDomains example.org
    CanonicalizeFallbackLocal no
    CanonicalizeHostname yes

Port

If you changed the port of your servers, this settings allows you client to use the correct port automatically.

Host *.example.org
    Port 2200

Crypo

These settings are derived from secure secure shell.

    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
    HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

Generate user keys

This needs to be run by all users. It is strongly recommended to set a password to your keys. A passwordless keyfile is as secure as a post-it on the wall with your password. If a script need unattended access to another machine, create dedicated accounts and key for that usage.

$ ssh-keygen -t ed25519 -o -a 100
$ ssh-keygen -t rsa -b 4096 -o -a 100

Verify published server key

Make sure your server has some published keys.

Edit file /etc/ssh/ssh_config and add the line

    VerifyHostKeyDNS yes