Let's start from the server opening the /etc/ssh/ssd_config file and checking the following configuration directives:

Port 22

Let's start with the port. The standard port for the SSH service is 22 , and it is at this value that most of the script kiddies around will probe your SSH daemon with some automated tools; so if you have a server publicly available, change the value to an unprivileged port such as 9527 . Thus, a lot of these attacks will simply be ineffective:

#ListenAddress ::
#ListenAddress 0.0.0.0

If we need to bind the service to a specific address on our server, this is the directive we need to work on; we simply uncomment and fill in the appropriate value:

Protocol 2

We do not think to use version 1 of the protocol, not even as a second choice. We stay safe and go along protocol version 2:

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

Ever wondered where the system-wide host keys are? Here, they are, and we can also decide to change names and path if we need to.

#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

Definitely! We want to work with unprivileged processes so that no super user privileges can be exploited.

# Authentication:
LoginGraceTime 120

Just give us some time to log in.

#PermitRootLogin without-password
PermitRootLogin yes

One safe practice is to limit the log in to the root account on a remote host to key-based authentication. This way, an intruder will not able to break in by just guessing a password; he will need the client's secret key to enter, and the key is safely stored on our client, not on the server. Anyway, if we want to remotely set up a passwordless authentication for the root account, we must allow root logins with passwords. Once we are sure everything works, we will restrict without-password.

StrictModes yes

It is so easy to forget some world-writable permission on the home directory or on our ssh configuration files and keys, so better to enable this directive; and it will prevent us to log in if the home directory of the remote user we log in has some unsafe permissions set.

PubkeyAuthentication yes

Well, we are working on that so better to be sure this is set to yes.

AuthorizedKeysFile %h/.ssh/authorized_keys

Let's note down where our public key must be stored. The token tells us they are in the .ssh directory inside the home of the accounts the file authorized_keys is in the home directory of the account we used to login into the system.

HostbasedAuthentication no

Just for safety, let's ditch the host authentication:

PermitEmptyPasswords no 

Let's check this. We must never switch this to yes unless we want logins without passwords. But who would want this?

UsePAM yes

There are a few reasons why we would like to set this to yes. One is that, with this on, the SSH daemon cannot be run as root; and this is a safe option.

Once we have the config bits in place, let's check that we also have the host keys that we need to proof the server identity to the client. As we can read from the configuration file, on the remote host, we should have a key for each algorithm supported in /etc/ssh:

root:# ls -lah /etc/ssh/
total 296K
drwxr-xr-x 2 root root 4.0K Apr 16 07:32 .
drwxr-xr-x 129 root root 12K Apr 17 04:00 ..
-rw-r--r-- 1 root root 237K Jul 22 2016 moduli
-rw-r--r-- 1 root root 1.7K Jul 22 2016 ssh_config
-rw-r--r-- 1 root root 2.6K Apr 16 07:32 sshd_config
-rw------- 1 root root 668 Apr 16 07:20 ssh_host_dsa_key
-rw-r--r-- 1 root root 601 Apr 16 07:20 ssh_host_dsa_key.pub
-rw------- 1 root root 227 Apr 16 07:20 ssh_host_ecdsa_key
-rw-r--r-- 1 root root 173 Apr 16 07:20 ssh_host_ecdsa_key.pub
-rw------- 1 root root 399 Apr 16 07:20 ssh_host_ed25519_key
-rw-r--r-- 1 root root 93 Apr 16 07:20 ssh_host_ed25519_key.pub
-rw------- 1 root root 1.7K Apr 16 07:20 ssh_host_rsa_key
-rw-r--r-- 1 root root 393 Apr 16 07:20 ssh_host_rsa_key.pub

There they are! So, we are fine. They usually get created when we install the OpenSSH server from our distribution packages, but we can also decide to create our very own host key. Let's see how. First, let's have a look at the fingerprint of one of the keys:

root:# ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
256 fe:23:d3:9b:8a:80:30:ad:0d:ac:81:fa:ba:3f:6f:56 /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA)

We used ssh-keygen, a utility which does a lot of things, from creating a key to modifying it or, as in this case, having a look at it. The first field of the resulting sting tells us the bit length of the key, the second sports the actual key, the third points to the file holding this key, and finally comes the encryption method.

But let's say we do not trust the existing keys, and we want to create a new pair set of them:

root:# cd /etc/ssh
root:# ssh-keygen -A
ssh-keygen: generating new host keys: RSA1 RSA DSA ECDSA ED25519

Is this easy? Yes, it is:

root:# ls -lh ssh_h*
-rw------- 1 root root 668 Apr 24 06:13 ssh_host_dsa_key
-rw-r--r-- 1 root root 601 Apr 24 06:13 ssh_host_dsa_key.pub
-rw------- 1 root root 227 Apr 24 06:13 ssh_host_ecdsa_key
-rw-r--r-- 1 root root 173 Apr 24 06:13 ssh_host_ecdsa_key.pub
-rw------- 1 root root 399 Apr 24 06:13 ssh_host_ed25519_key
-rw-r--r-- 1 root root 93 Apr 24 06:13 ssh_host_ed25519_key.pub
-rw------- 1 root root 976 Apr 24 06:13 ssh_host_key
-rw-r--r-- 1 root root 641 Apr 24 06:13 ssh_host_key.pub
-rw------- 1 root root 1.7K Apr 24 06:13 ssh_host_rsa_key
-rw-r--r-- 1 root root 393 Apr 24 06:13 ssh_host_rsa_key.pub

Here are the new key files; let's check the same key again:

root:# ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
256 24:4d:3e:6b:f4:0f:4b:bf:56:b9:b5:c4:b6:ab:c6:7b /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA)

The two keys are different:

24:4d:3e:6b:f4:0f:4b:bf:56:b9:b5:c4:b6:ab:c6:7b
fe:23:d3:9b:8a:80:30:ad:0d:ac:81:fa:ba:3f:6f:56

We took advantage of the -A option of ssh-keygen, which automatically creates a missing key for each type (rsa1, rsa, dsa, ecdsa, and ed25519). The keys are created with the default bit size, with no password, and with the default comments. Now, let's say again that we want to create our very own ecdsa host key pair:

root:# ssh-keygen -t ecdsa -a 1000 -b 521 -C "My hand crafted key" -f /etc/ssh/ssh_host_crafted_ecdsa -o
Generating public/private ecdsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /etc/ssh/ssh_host_crafted_ecdsa.
Your public key has been saved in /etc/ssh/ssh_host_crafted_ecdsa.pub.
The key fingerprint is:
28:74:b2:e6:a1:e5:6d:cd:ca:e7:f2:47:86:6d:39:d6 My hand crafted key
The key's randomart image is:
+---[ECDSA 521]---+
|                 |
|                 |
|    o .          |
|   . + .         |
|     * . So o    |
|    * + o. O E   |
|   . o o o= .    |
|     o... .      |
|      o=o.       |
+-----------------+

We created our new host key using some simple options:

• -t: This selects the type of the keyboard-interactive.
• -a: This option can be selected when saving a key in the ed25519 format or with any SSH-2 key when the -o option is selected. It specifies the number of Key Derivation Function (KDF) rounds to use to encrypt the private password. It makes the passphrase check slower and more resistant to a brute force attack. The higher the integer, the slower the check. It defaults to 64 , which is really good; we just got insane with 1000.
• -b: Bit length of the key. Ecdsa can have a size of 256, 384, or 521 bit.
• -C: Is a comment you can associate to the key.
• -f: Is the path to the file that will hold the new key.
• -o: Saves the SSH-2 private key in the new OpenSSH format rather than the usual PEM format. The new format is more resistant to brute force attack, but it is not supported by OpenSSH versions lower than 6.5. The ed25519 keys are always saved in the new format, so they do not require this option on the command line.

Now, it is time to make the new key available to the server by adding it to the main sshd configuration file:

HostKey /etc/ssh/ssh_host_crafted_ecdsa

Let's restrict the permissions on the keys:

root:# chmod 600 *

So, no one other than root will be able to access the keys and configuration files:

root:# ls -lah | grep cra
-rw------- 1 root root 751 Apr 24 11:41 ssh_host_crafted_ecdsa
-rw------- 1 root root 225 Apr 24 11:39 ssh_host_crafted_ecdsa.pub

We notice two things:

• We created a private key whose name does not end with _key. We did this on purpose to differentiate it from the prebuilt keys. The key filename can be whatever we want, but better give it a meaningful value.
• ssh-keygen automatically added a trailing .pub to the private key file name and used the resulting name for the public key filename.

Now, let's reload or restart the service to get the new key available for the SSH daemon:

root:# systemctl restart sshd ; systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: active (running) since Mon 2017-04-24 11:40:51 EDT; 5ms ago
Process: 30993 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Main PID: 31265 (sshd)
CGroup: /system.slice/ssh.service
└─31265 /usr/sbin/sshd -D

Wow, it is working, let's see the logs:

root:# tail -f /var/log/syslog
Apr 24 11:40:51 spoton systemd[1]: Stopping OpenBSD Secure Shell server...
Apr 24 11:40:51 spoton systemd[1]: Starting OpenBSD Secure Shell server...
Apr 24 11:40:51 spoton systemd[1]: Started OpenBSD Secure Shell server.
Apr 24 11:40:51 spoton sshd[31265]: Could not load host key: /etc/ssh/ssh_host_crafted_ecdsa

We are almost there. The daemon successfully started but refused to load the host key. What happened? Simply, we gave a passphrase during the key creation; and to load the key, a passphrase must be given but the daemon cannot interact and fill it in. We must remove the passphrase:

root:# ssh-keygen -p -f /etc/ssh/ssh_host_crafted_ecdsa

The program will ask for the old password, and when it comes to fill in a new one, let's just hit the Enter key twice so that no password will be added to the private key. Now, let's restart and check:

root:# systemctl restart ssh ; systemctl status ssh ; tail -n3 /var/log/syslog

● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: active (running) since Mon 2017-04-24 11:59:32 EDT; 8ms ago
Process: 30993 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Main PID: 31517 (sshd)
CGroup: /system.slice/ssh.service
└─31517 /usr/sbin/sshd -D

Apr 24 11:59:32 spoton systemd[1]: Started OpenBSD Secure Shell server.
Apr 24 11:59:32 spoton systemd[1]: Stopping OpenBSD Secure Shell server...
Apr 24 11:59:32 spoton systemd[1]: Starting OpenBSD Secure Shell server...
Apr 24 11:59:32 spoton systemd[1]: Started OpenBSD Secure Shell server.

Now, it is really fine, the key has been loaded.