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
ssh-agent
ssh-agent is a program that can keep your ssh keys in memory and avoid you to type your password several time.
Warning: Anybody which can run command as your user or as root on your machine can reuse or eve steal your keys. Don't run ssh-agent on a machine unless you trust it 100%.
Run the agent
By default Debian and Ubuntu start ssh-agent when you log into a graphical session. However, the way it is done doesn't allow passing options to the agent.
To disable the default ssh-agent startup script, edit file /etc/X11/Xsession.options and remove line use-ssh-agent.
Add the following line to ~/.xsessionrc (create the file is it doesn't exist). This need to be done for each user that wants to run ssh-agent.
STARTUP="/usr/bin/ssh-agent -t 3600 ${TMPDIR:+env TMPDIR=$TMPDIR} $STARTUP"
Add keys to agent
Note: You need OpenSSH version 7.2 or above for this to work.
SSH client is able to add keys to ssh-agent automatically. To do this, edit file ~/.ssh/config and add
Host *
AddKeysToAgent yes
Forward agent
If you want to be able to connect from machine A to machine B and then from machine B to machine C without typing password twice, you can use a feature called agent forwarding. With this feature machine B will be able to use the keys from the agent running on machine A.
Warning: As for running the agent, you must only forward your agent to a machine that you trust 100%. Anybody with access to root or the account you use on machine B will be able to use your keys.
To enable the feature, add this to ~/.ssh/config
Host machineB.example.org machineD.example.org
ForwardAgent yes
