The majority of the following code snippets are to by typed directly into the server/RPi/client where you are setting up the SSH server. If otherwise, it will be stated explicitly, and the code snippets for those “local” commands will be bash commands. If you’re using a Windows device, you’ll need to look up the corresponding commands.
Also, as usual, just make sure you look out for any placeholders in the code snippets, usually denoted by being in ITALICIZED ALL CAPS.
Install OpenSSH (If Not Already Installed)
When I installed Ubuntu Mate, it came with OpenSSH installed already. In case whatever OS you’re using doesn’t come preloaded with OpenSSH, you can install it via this command (or some variation of it based on your distro):
sudo apt-get install openssh-server
Copy SSH Config File for Emergency Backup
Now that OpenSSH is installed on your machine, you’re ready to start configuring the server. But, before you start making changes to the sshd_config file (the OpenSSH Server configuration file), it would be wise to make a copy of it in case you (or someone else) messes something up. To do that, simply run the following:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_backup
Once that’s complete, it’s time to start configuring your OpenSSH server! Go ahead and open up the sshd_config file using your favorite editor.The majority of the rest of this tutorial involves working in and changing this file. Here’s an example of opening it up in vi:
sudo vi /etc/ssh/sshd_config
Enable Public Key Authentication
Public Key Authentication is the magic that allows SSH to work. In a nutshell, some really cool math makes it possible so that you have a secret/private key (a file filled with a bunch of text) on your machine that matches up with a public key (a different file filled with a bunch of text) on a server which allows you to authenticate without needing a username or password. There are a bunch of great posts out there about how Public-Private key encryption works, and I’ve copied several of them under the Further Readings section of this post. If you’re interested in learning more, check ’em out!
Depending on the version of OpenSSH that you have installed, this feature may or may not be enabled by default. Scan the sshd_config file for the following line and either uncomment it (remove the # from the beginning of the line), add the line, or change it so that it looks like this:
Now that public key authentication is turned on, you’ll need to upload your public key to the server to be able to authenticate. But, let’s configure some more security settings first.
Make Security-Based Configuration Changes
OpenSSH server can become an easy target for malicious intruders. If not properly configured, it will be an open gateway into your local network, which, depending on where your server/RPi/client is, could mean that someone could have unauthorized access to personal, private information.
To mitigate this risk, here are a couple of things that you can do to harden (beef-up) your OpenSSH installation.
Disclaimer: I am not a security professional. Also, there is no such thing as “perfect security” (related video). So, even though you take the following steps, you can still be or become vulnerable to outside attacks. Take it upon yourself to do some extra reading in order to lock down your local network. I’ve included a couple of links in the Further Readings section on hardening your local/home network, and securing your SSH server.
Disable Root Login Via Password
When you login to a server via SSH, you generally connect to the remote machine through a username. For example:
This command would attempt to log me in via the user john.
As mentioned previously, SSH allows you to access a remote machine through the internet without needing a username and password. Some situations, however, call for the ability to log into a server via a username and password in case the connecting user doesn’t have a public-private key pair stored correctly.
Now, combine both of those facts with the knowledge that the root user is allowed to do pretty much ANYTHING on a machine, and you’ve got yourself into a bit of a pickle. If your OpenSSH server allows someone to try to connect to the root user via SSH, AND allows that person to attempt to login via a password, then attackers can attempt to brute-force your root password and gain unfettered access to your machine.
To combat this weakness, the people behind OpenSSH have a setting that enables/disables the ability to login to the root user via a password. Recently, they have made it so that this is NOT allowed by default (yay security!). However, just in case, here’s the line that you need to change/confirm in your sshd_config file:
Make sure that the line looks like this, and that it’s not commented out, and you’re good.
Explicitly Declare with OS Users Can be Accessed Via SSH
As mentioned previously, when you login to a machine via SSH, you do so via operating system users, or user accounts on the remote machine. One nice security feature that you can add to your OpenSSH installation is the restriction of accounts that can be accessed via SSH.
For example, if you know that you only want the user john to be accessible via SSH, you can limit OpenSSH to only accept attempted connections to that user. All requests to connect to other users (root included) will be rejected.
To do this, add/uncomment (depending on your version of OpenSSH) the following line, and follow the pattern to add whichever user accounts you want to be accessible via SSH:
AllowUsers USER1 USER2 USER3...
Note: The users are NOT comma-separated, they are only separated with a space, and you can add as many users as you’d like here, including only a single user.
Some of the extra articles listed under the Hardening OpenSSH Server portion of the Further Readings section talk about other ways to accomplish this same task. They’re worth checking out to see if your use case would benefit from a different approach.
Change Which Port SSH Listens To
SSH, by default, listens on port 22. One added security measure is to change the default port for SSH to a different port that you choose at random.
Disclaimer: There’s a great article (check it out in the Further Readings section) that talks about why this isn’t necessarily a good idea. Though I don’t agree with all of the author’s arguments, and I do feel that this is a valid security measure, I absolutely agree with his main point: Security through obscurity isn’t enough. You can’t just hope that attackers won’t stumble onto your SSH port. Your system needs to be hardened in other areas as well.
Anyway, to change the default port, find this line in the sshd_config file and substitute the ###’s for whatever port number you’d like (make sure you don’t use a reserved/well-known port!).