The following is valid for OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n 7 Dec 2017 as shipped with Ubuntu 18.04.1 LTS “Bionic Beaver”
Please be advised that any change in the SSH-Settings of your server might cause problems connecting to the server or starting/reloading the SSH-Daemon itself. So every time you configure your SSH-Settings on a remote server via SSH itself, ensure that you have a second open connection to the server, which you can use to reset or adapt your changes!
Note that we only create ed25519 and RSA keys. Other types are not recommended.
The supported key types depend on the SSH software version. Both client and
server must support it. You can check which key types are supported by your
version of OpenSSH with the command
ssh -Q key.
cd /etc/ssh sudo rm ssh_host_*key* sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key sudo ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key
Don’t forget to re-distribute the new server public keys to any SSH clients you connect to from this host.
To create DNS server records of you key:
ssh-keygen -r host.example.net -f ssh_host_ed25519_key.pub ssh-keygen -r host.example.net -f ssh_host_rsa_key
The server settings are stored in
Change according to the example below.
The complete configuration file described here is available for
By changing the default TCP listening port, we avoid thousands of malicious login attempts every day.
Changing the TCP listening port is not a security feature, but keeps our logs more readable by avoiding this kind of junk.
It also helps, if you have multiple servers in your LAN behind a NAT.
The following small bash shell script will choose a random TCP port, which is unlikely to interfere with other services on your server:
$ shuf -i 49152-65535 -n 1 63508
Add this port to your configuration:
# SSH server configuration file # See the sshd_config(5) manpage for details # On which TCP ports we listen for SSH client connections Port 63508 # On which interfaces and IP addresses we listen for SSH client connections #ListenAddress :: #ListenAddress 0.0.0.0
They point to our newly created set of ed25519 and RSA host keys:
# HostKeys for protocol version 2 - by order of preference HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key #
The root user is not allowed at all to login remotely. Others need their SSH public-key installed.
Password logins are not allowed.
# # Authentication # # Root login is not allowed for auditing reasons. # Regular user logins combined with "sudo" ensures a clear audit track. PermitRootLogin no #PermitRootLogin without-password # Only public key based logins are allowed -password based logins are disabled. AuthenticationMethods publickey # Don't allow challenge-response passwords ChallengeResponseAuthentication no # Disable tunneled clear text passwords PasswordAuthentication no # Enable PAM authentication # If enabled, make sure that 'PasswordAuthentication' and # 'ChallengeResponseAuthentication' are both set to 'no'. UsePAM yes # Don't print /etc/motd when a user logs in PrintMotd no #
Similar to our Cipher Suite Selection we limit our SSH server to a safe and recommended set of encryption algorithms and set preferences as which ones are preferred over others.
The supported cipher suites are highly dependent on the SSH software. Both client and server must support it.
You can check which key exchange algorithms are supported by your version of OpenSSH with the command:
$ ssh -Q kex
- Avoid if better alternatives are available:
- Unknown, but probably OK:
- Don’t use:
You can check which symmetric ciphers are supported by your version of OpenSSH with the command:
$ ssh -Q cipher
- Avoid if better alternatives are available:
- Don’t use:
Message authentication (MAC):
You can check which message integrity codes are supported by your version of OpenSSH with the command:
$ ssh -Q mac
- Don’t use:
# # Ciphers suite selections # # Key Exchange KexAlgorithms firstname.lastname@example.org,diffie-hellman-group-exchange-sha256 # Symmetric ciphers Ciphers email@example.com,firstname.lastname@example.org,email@example.com # Message authentication MACs firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,hmac-sha2-512,hmac-sha2-256,email@example.com
# Allow client to pass locale environment variables AcceptEnv LANG LC_* # Secure File Transfer Protocol Subsystem sftp /usr/lib/openssh/sftp-server
There will be SSH connections out of the server to other SSH servers (i.e. for storing backups or accessing remote files). In that case, the server-system acts as a client to a remote SSH server. Therefore also a “server” needs a well configured SSH client.
The system-wide default client settings are stored in
/etc/ssh/ssh_config. Change according to the example below:
# Github sometimes needs diffie-hellman-group-exchange-sha1 Host github.com KexAlgorithms firstname.lastname@example.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1 Host * HostKeyAlgorithms email@example.com,firstname.lastname@example.org,ssh-ed25519,ssh-rsa KexAlgorithms email@example.com,diffie-hellman-group-exchange-sha256 Ciphers firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,aes256-ctr,aes192-ctr,aes128-ctr MACs email@example.com,firstname.lastname@example.org,email@example.com,hmac-sha2-512,hmac-sha2-256,firstname.lastname@example.org
As with the SSH server keys, we generate a fresh set of ed25519 and RSA client keys for our own user-profile:
$ rm ~/.ssh/id_* .ssh/id_*.pub $ ssh-keygen -t ed25519 $ ssh-keygen -t rsa -b 4096
The same has to be done also for the root user:
$ sudo rm /root/.ssh/id_* /root/.ssh/id_*.pub $ sudo -sH ssh-keygen -t ed25519 $ sudo -sH ssh-keygen -t rsa -b 4096
As well as for all other profiles on the system, who will initiate SSH client connections out of this system:
$ sudo rm /home/<username>/.ssh/id_* /home/<username>/.ssh/id_*.pub $ sudo -u <username> -sH ssh-keygen -t ed25519 $ sudo -u <username> -sH ssh-keygen -t rsa -b 4096
Don’t forget to re-distribute your public client keys to any SSH servers you connect to from this host.
If you domain is not secured with DNSSEC, you should NOT use this feature, as the information received by the clients over DNS can not be trusted.
The hash of the SSH server keys can be published in DNSSEC secured domains.
By publishing a fingerprint of your SSH server public keys in DNS, connecting clients can verify the server identity, without the need to distribute and update your server public keys on all clients.
As of now RSA and ed25519 keys can both be published in DNS according to the IANA assignments DNS SSHFP Resource Record Parameters. But OpenSSH isn’t ready to read and check ed25519 fingerprints from DNS. The message “Error calculating host key fingerprint.” will be displayed and keys need to be manually accepted.
The ssh-key-gen utility can be used to display the fingerprints of you host keys pre-formatted for publishing in DNS:
$ ssh-keygen -r server.example.net. -f /etc/ssh/ssh_host_rsa_key.pub server.example.net. IN SSHFP 1 1 de63........................0851 server.example.net. IN SSHFP 1 2 466b................................e409
The first line shows the SHA-1 fingerprint and the second line the SHA-256 fingeprint of our RSA key.
If you use PowerDNS server with the Poweradmin web interface, add the SHA-256 record as follows:
|server||SSHFP||1 2 466b…………………………..e409|