OpenSSH Security Best Practices

OpenSSH is the standard SSH client and server used by most Linux Distributions. It is a connectivity tool that most administrators rely on to work on their Linux and *BSD servers. OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other attacks. So in other words "OpenSSH ensures that the connection to your server is secure". See Wikipedia article for a detailed excurse on SSH.

This tutorial covers the best practices to configure your SSH server securely.

OpenSSH Security

These are the six most important tasks to secure your SSH server setup:

Use a strong password.
Change the SSH default port.
Always use protocol version 2.
Disable the root login.
Limit user access.
Use key-based for authentication.

Use a strong password

A password is a word or string of characters used for user authentication to prove identity or access approval to gain access to a resource. Keep it secret from those that are not allowed to access the server. Use a complex and long password, it should be easy to remember and unique according to you but not easy to guess for others. Don't use `admin123` or `admin` etc. that are easy to guess and don't use birthdays, the name of your wife etc. A good password should also contain special chars like '.!;/' (not just the characters a-c and 0-9). Use upper- and lowercase characters in the password.

Change the SSH default port

The default Post of the SSH service is 22, you should change that to make it less obvious that your server is running an SSH service. The SSH configuration file is located in /etc/sshd/ directory, you have to edit the config file /etc/ssh/sshd_config .

nano /etc/ssh/sshd_config

Search for the "Port" line:

Port 22

and change it to your favorite port number, example: 1337

Port 1337

Please choose a port that is not in use on your server yet. You can get a list of ports that are currently in use with the command:

netstat -ntap

This command results in a quite long list that shows all open ports and connections. If you just like to check if your desired port is available, use this command instead:

netstat -ntap | grep 4422

In this example, I'll check if port 4422 is free. If the command does not return a result, then the port is available and can be used for SSH.

Always use protocol 2

SSH has two protocol versions, the old protocol 1 which is insecure and the new protocol 2. So Always use protocol 2 for your ssh server, it is more secure than protocol 1. More Info Here.

You should disable the direct login for the root user because there are many brute force attacks against the name of the root superuser. IMPORTANT: test the SSH login with your alternate non-root user that you plan to use for ssh logins before you disable the root account.

PermitRootLogin no

After you set "PermitRootLogin" to "no", you can not login with root account anymore, although you use the correct password for root user.

Limit user

You should add a new user for login to your server. Assume that you have created the users ruiko and mikoto to login to your server, then you can add the new line:

AllowUsers ruiko mikoto

in /etc/ssh/sshd_config to limit SSH access to these users.

Use Key Based Authentication

I recommended you to use this option because this is very easy to setup and more secure than password-based authentication. First you have to create a public-private key pair on your local (desktop) computer, I use Linux to create it.

You can create the public / private key pair with this command:

ssh-keygen -t rsa -b 4096

It will create 2 files located in ~/.ssh/ directory, id_rsa as private key and id_rsa.pub as the public key. If it prompts for a password, you can leave it blank or type to your password. Using a password to protect your key is recommended.

Now upload the public key id_rsa.pub to your server with ssh-copy-id command.

ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

It will automatically write your public key to the file ~/.ssh/authorized_keys/ in your server.

Now go back to your server and edit your ssh file configuration again.

nano /etc/ssh/sshd_config

Uncomment this line:

AuthorizedKeysFile     %h/.ssh/authorized_keys

and finally restart your ssh server:

systemctl restart sshd

Now try connect to your server:

ssh -p '4422' '[email protected]'

Conclusion

OpenSSH is the standard for secure remote access to *Unix-like servers, replacing the unencrypted telnet protocol. SSH (and its file transfer sub-protocol SCP) ensures that the connection from your local computer to the server is encrypted and secure. The base installation of OpenSSH is already quite secure, but we can improve it by following the above guide.

view as pdf | print

Share this page:

9 Comment(s)

Add comment

Comments

By: Keith Day

What is "zuthentication"?

By: Lee

A better practise, don't allow password based logins. Once setup and one or more admins have access then disable password based logins and only allow key based.

By: LSW

Changing the port is a good idea to deter script-kiddies, but does not really add much to security.

By: Curtis

Nice article. I have a few quick things to add that might help people out.

You can legitimately have multiple listening ports listed in sshd_config. This can allow one to use the default port 22 within the local network, but only forward a non-standard port through their firewall. (Of course, one could also redirect a high port to 22)

You can also use socket activation to start sshd. So if using systemd, you can enable the sshd.socket file instead. But if one chooses this method, they should be aware that the listening port it then determined by the sshd.socket unit file, while the Port line in sshd_config is ignored.

By default both ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2 can be used for authorized ssh keys. Users might want to consider expicitly enabling only one file.

Not all distributions have ssh-copy-id included. But it is basically just a script that writes the contents of the chosen ~/.ssh/*.pub key to the authorized keys file. This can also be done manually.

...and just a nitpick... with the AuthorizedKeysFile option, the path default is relative to a user's home directory. So you don't have the use %h/.ssh/authorized_keys and can instead simply use .ssh/authorized_keys.

By: big

Thanks for the tutorial.

By: Anonymous

Using ports above 1024 is dangerous as those are non privilidged ports (anyone can bind to them). A malicious user could crash SSH daemon and launch a compromised one on the same port. Do NOT use ports above 1024 for SSH daemons.

By: Jay

I agree, changing the port adds little to security. Better to leave on the default port, and limit access using iptables. No mention of setting specific MACs.

MACS hmac-sha2-256,hmac-sha1,hmac-sha2-512

By: JohnP

Using passwords for ssh access is a failure if retained after the first 5 minutes. No passwords should be used/allowed for ssh. Always use keys for ssh, scp, sftp.

No mention of denyhosts or fail2ban?

By: Trust Me

I think @Anonymous has a point in not using ports above 1024 for the sshd daemon.

Further I recommend reading the following article as an afterthought:

https://stribika.github.io/2015/01/04/secure-secure-shell.html

Log in or Sign up

OpenSSH Security Best Practices

On this page