The following is valid for OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016 as shipped with Ubuntu 16.04.3 LTS “Xenial Xerus”

SSH Server


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!

Re-create Server Keys

After we improved our systems Entropy, its time to discard the old SSH server keys, who have been created by the Ubuntu server installation process, with a fresh set

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 -f
ssh-keygen -r -f ssh_host_rsa_key

Server Configuration File

The server settings are stored in /etc/ssh/sshd_config. Change according to the example below.

The complete configuration file described here is available for download also.

Network and Protocol Settings

By changing the default TCP listening port, we avoid thousands of malicious login attempts every day.


Changing the TCP listening port is not really 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:

# Get a random unused TCP/IP port number

while [[ $( grep ${PORT_CANDIDATE} ${PORTS_LIST_FILE} ) ]]
    echo "Port ${PORT_CANDIDATE} is in well-known use:"
echo "Port ${PORT_CANDIDATE} is not a well-known port."

We only allow SSH protocol version 2. Version 1 is insecure and will be removed in future versions of OpenSSH.

# SSH server configuration file
# See the sshd_config(5) manpage for details

# On which TCP ports we listen for SSH client connections
Port 22257

# On which interfaces and IP addresses we listen for SSH client connections
#ListenAddress ::

# Which SSH protocol versions are enabled. Don't use version 1
Protocol 2

Server Keys

They point to our newly created set of ed25519 and RSA host keys:

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

Authentication Settings

The root user is not allowed at all to login remotely. Others need their SSH public-key installed.

Password logins are not allowed.

HostKey /etc/ssh/ssh_host_rsa_key

# Authentication
PermitRootLogin no

# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# 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

Ciphers Suites

Same as with our TLS settings 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.

Key exchange:

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:

  • ecdh-sha2-nistp521,
  • ecdh-sha2-nistp384,
  • ecdh-sha2-nistp256,

Don’t use:

  • diffie-hellman-group1-sha1,
  • diffie-hellman-group14-sha1,
  • diffie-hellman-group-exchange-sha1
# Key Exchange

Symmetric ciphers:

You can check which symmetric ciphers are supported by your version of OpenSSH with the command ssh -Q cipher:



Don’t use:

# Symmetric ciphers

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:

# Message authentication

Other Settings

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# Secure File Transfer Protocol
Subsystem sftp /usr/lib/openssh/sftp-server

Restart SSH Server

After the new host keys and sevrer configurations are in place, restart the SSH server:

$ sudo systemctl reload ssh

SSH Client

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.

Client Configuration File

The system-wide default client settings are stored in /etc/ssh/ssh_config. Change according to the example below:

# Github supports neither AES nor Encrypt-then-MAC. LOL

Host *

Client Keys

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.


Show DNS Record

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 -f /etc/ssh/ IN SSHFP 1 1 de63........................0851 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:

Name Type Content
server SSHFP 1 2 466b…………………………..e409