Securing OpenSSH

OpenSSH is a wonderful tool; it's the Linux administrator's best friend. It saves you the trouble of having to walk into the server room and attach a monitor and keyboard in order to perform work on your network. Using any computer connected to the same network, you can pretty much do anything you want to as if you were standing right in front of the machine. The problem is that an unsecured SSH implementation gives miscreants the exact same luxury. Of all the things running on your network, SSH is definitely the one you want to give some major attention to.

The first and most common security tweak for SSH is to use only Version 2 of the protocol. To determine which version your Linux installation is using, grep the /etc/ssh/sshd_config file:

cat /etc/ssh/sshd_config |grep Protocol

If the answer is 1, you should edit this file and change the line that reads Protocol 1 to Protocol 2, and restart SSH. The reason this is important is because Protocol 1 has considerably weaker security than Protocol 2. Thankfully, SSH Version 7 and later, now default to Protocol 2, so this isn't as common as it used to be. But at the time of this writing, Version 7 was just released and hasn't made its way into many distributions yet. Hopefully, by the time you read this, your distribution has upgraded to Version 7. But if not, it's important that you ensure all of your servers utilize only Protocol 2 for SSH. You can achieve this by changing the relevant line in your sshd_conf file and then restarting the SSH service.

Another worthwhile change to SSH is changing the port it listens on. By default, SSH is listening on Port 22. You can confirm this with the following command:

cat /etc/ssh/sshd_config |grep Port

Unless you changed it, the answer will be 22. Since 22 is the default port for SSH, that's the port everyone (including the bad guys) expects it to be on. In the /etc/ssh/sshd_config file, there will be an option for the port near the top. If you change it to something else, it will be less obvious to outsiders. However, I don't want to lure you into a false sense of security here. Changing the port for SSH isn't a magical barrier against intrusion via SSH. In a targeted attack, a miscreant will scan every port on your server, so if they are determined, they'll figure out what port you changed it to. The reason why I recommend this change is because it's a very easy change to make. It requires only a few seconds to change your SSH port, and anything you can do to make your network less obvious to outsiders is a welcome change. The only time changing the SSH port can become a potential problem is if users of your network expect it to be on port 22. As long as you communicate this change to everyone, it should be a non-issue.

In order to connect to a server with a non-standard SSH port, use the -p flag:

ssh -p 63456 myhost.mynetwork

You can also designate the port while using scp as well:

scp -P 63456

Note

Note the -P parameter is uppercase in scp but not in the ssh command. This was intentional. The reason for this is because the lowercase -p option in scp was already taken, and it's used for preserving modification times when transferring files.

If you can't seem to get into the habit of requesting a different port for SSH, create an alias for it. However, this can be a problem if some of your hosts are still using port 22, so you would only use this alias if everything you connect to is on the same port. In the following example, we can set an alias to ssh to force it to always use port 63456:

alias ssh="ssh -p 63456"

Another very important change to your SSH configuration is to not allow root login. Under no circumstances should root login be allowed on any Linux server for any reason. If your configuration requires you to log in to a server as root via SSH, correct your configuration. To check to see if root login is enabled via SSH, run the following:

cat /etc/ssh/sshd_config |grep PermitRootLogin

If root login is enabled, disable it by correcting the following configuration line in /etc/ssh/sshd_config. However, make sure you are able to access the server via SSH with a normal user account first; otherwise, you'll be locked out. The following configuration line in sshd_config will disallow root login:

PermitRootLogin no

Note

As always, restart ssh after you make any changes to its configuration. Don't worry about restarting SSH while you are using it, current connections will not be disrupted.

For Debian systems, execute the following command:

# systemctl restart ssh

For CentOS systems, execute the following command:

# systemctl restart sshd

Another practice worth implementing is locking SSH down to only allow connections via specific users and/or groups. By default, any user with an account on the system is available via SSH. To change this, add the following line to the very bottom of the configuration file:

AllowUsers jdoe

If you have more than one user, you can add multiple users on the same line:

AllowUsers jdoe bsmith

You can also allow specific groups. First, create a group that you'll use for SSH access:

groupadd ssh_admins

Next, add one or more users to the group:

usermod -aG ssh_admins jdoe

Finally, add the following line to the bottom of your SSH configuration file. After you restart SSH, access will be restricted to those that are a member of this group. Each time you need to grant SSH access to someone, all you'll need to do is add their user ID to this group and you won't have to restart the sshd_config configuration file each time.

AllowGroups ssh_admins

Finally, the most secure option for SSH is to not allow password-based authentication at all. Instead, users can use a public/private key pair for access. With this method, passwords are not transmitted over the network and those without a private key that matches an accepted public key are not allowed access. This is the practice that I recommend to everyone. On the down-side, it also comes with the most administrative overhead. To implement this change, each user will need to generate a key pair for SSH with the following command:

ssh-keygen

You'll be asked several questions, most of which you can leave as the default. For the passphrase, come up with something unique and ensure it's not the same as your password. You can leave it blank if you don't want to be asked for a passphrase while making connections, but I recommend creating one.

Next, the easiest way to configure a server to allow you to connect via a key is to import that key into the server, before you disable password authentication. To do that, use a variation of the following:

ssh-copy-id -i ~/.ssh/id_rsa.pub myserver.mynetwork.com

At this point, you'll be asked to log in to the server via your normal password. Then, the next time you connect to it, you will default to using the key pair you came up with and you'll be asked for your passphrase if you created one.

After all of your users have generated their key and imported it into the server, you can implement this change. Look for the line in the SSH configuration file that looks similar to the following:

PasswordAuthentication yes

Simply change that option to no, restart SSH, and you should be all set. The reason that this works is because when you copy over your SSH key using the ssh-copy-id command, what it's actually doing is copying the contents of your public key (~/.ssh/id_rsa.pub) on your local machine to the end of the ~/.ssh/authorized_keys file on the remote machine. With password authentication disabled, SSH will check that the key listed there matches your private key (~/.ssh/id_rsa) and then allow you access.

With these tweaks, your SSH implementation should be reasonably secure. It certainly won't help you if you use weak passwords or passphrases, but these are the general steps you should take on all servers.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset