Securing SSH in ClearOS
SSH is a powerful protocol that allows you to remotely administer your ClearOS server from command line. Because it is so powerful, it is a common target. If you have SSH open to the world you may have noticed an accumulation of security alerts in your Webconfig interface.
By default, ClearOS is secure and has this management port firewalled. It is common to open it up and we recommend that if you have to open it, you implement many (or all) of the protections described. This guide will give you some guidance on best practices for using SSH on your server.
If you can avoid it, it is best not to open up external access to SSH. If you require external access, consider if it would be better to use OpenVPN
to connect to ClearOS because you can then connect to SSH as if you were connected to the ClearOS LAN
SSH Server App
The SSH Server app in the ClearCenter Marketplace can help you configure your SSH server easily. You can also configure your SSH server by hand by manipulating files in /etc/ssh/sshd_config but this app makes it easy to make common security changes without needing to know the complex command line parameters.
The items you can and SHOULD adjust or be aware of are:
Allow Root Login
These are discussed in order below.
Port: Obfuscation through misdirection
Changing the port is a useful way to stop a bulk of attacks. The default port is 22 but there are tens of thousands of other ports you could put this on. Changing this doesn't necessarily make it so someone can no long SSH to it. Nor does it prevent a hacker from scanning your IP and finding it there, plain as day. But it does do a few things for you.
If it isn't on the default, a hacker must spend additional time to reveal it. This is often a sufficient deterrent to cause a hacker to move along.
If it isn't on the default, a hacker may have to use a port scanner to find it. This port scanning activity can trigger defenses you have in place that are looking for port scans
It is important to note that you may be inconvenienced when changing the port number. You will have to specify the port each time you SSH to your box. You will also have to know how to do this in various different tools. Here is an example of some before and after commands if I change to using port 3242 for SSH:
ssh -p 3242 email@example.com
scp /the/source/file firstname.lastname@example.org:/destination/file
scp -P 3242 /the/source/file email@example.com:/destination/file
rsync -av firstname.lastname@example.org:/the/source/files/and/dirs/* /destination/dir/.
rsync -av -e 'ssh -p 3242' email@example.com:/the/source/files/and/dirs/* /destination/dir/.
When you change the port, you will also need to open an alternative port on your firewall. SSH works over TCP and whatever the port you specify. Be sure to remove the previous port 22 when you change it (if it exists.)
Key-based Access: Accessing while disallowing passwords
Key-based access is a way that you can really throw hackers for a loop. If you remove password-based logins in favor of key-based access, you can make it so that any password authentication via SSH will fail. Key-based access changes the factor of authentication from 'something you know' to 'something you have'. All brute force will prove ineffective since the complexity of key-based authentication just became orders of magnitude harder. You can make your key even harder to compromise by assigning a password to it. We strongly recommend doing this. This transforms your authentication to 'something you have' + 'something you know'.
There are two parts to this key, a public key and a private key. These are sometimes named:
Public key: id_rsa.pub
Private key: id_rsa
The public key is only used for encrypting messages. It cannot decrypt messages. The private key decrypts messages and should be kept secure. Because of this nature, the public key can be distributed. For example, it can be placed in:
When listed in this file, the user in possession of the private key is trusted and authorized to log into the server since the user can decrypt authorization challenge messages sent from the server using the key to the user.
permissions for the .ssh folder should be 0700 and the permissions for the authorized_keys file should be 0600. Both should be owned only by the user.
MacOSX and Linux
In MacOSC and Linux, you can create a keypair by logging in as root or your named account and running:
ssh-keygen -t rsa
This will ask you what you want to call your key. You can press to accept the default location. It will ask you for a passphrase. Type it in and press . It will NOT echo any stars or output for security reasons. Type it is a second time and press
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/username/.ssh/id_rsa): /Users/user/.ssh/id_rsa.test
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/username/.ssh/id_rsa.
Your public key has been saved in /Users/username/.ssh/id_rsa.pub.
The key fingerprint is:
The key's randomart image is:
|++oo==.X.*o . |
|* = .= X..o |
| O B o. |
|+ o S |
|. . |
In Windows, the most popular tool for using SSH is PuTTy. If you use the PuTTy Installer, it will install two programs that will assist you in using key-based authentication, namely; Pageant, and PuTTygen.
PuTTyGen will help you make a public/private keypair. You can save these files to disk and even copy the public key from the screen of PuTTygen into the .ssh/authorized_keys file. You can also specify a password for your keypair. Once you have your keypair, you can either specify your keyfile in PuTTy or use Pageant and load your key.
No Root Login
The root account is the most powerful account in Linux and is the prime target for hackers. Disabling this account from SSH will prevent all attempts to authenticate as root leaving attacker with the only recourse of attempting other names and not getting root access.
Naturally, there are methods for escalating privilege with non-root users. By converting your own access to SSH via a non-privileged user, you can obfuscate the root completely. Now the hacker must determine the username that will work with SSH. Also, by placing the burden on non-privileged users, you can require a root password post-login in order to escalate privilege.
Limiting Function through disabling TCP Forwarding
If you aren't using this and don't know what it is, turn it off. This can be very useful when used properly and with other security in place…but like all things, if you don't use it, why make it available as an attack surface.
“TCP forwarding allows users to use SSH to set up a VPN which they can use to tunnel into a network. This could allow an attacker to circumvent network security measures like firewalls. SSH tunneling can be an extremely useful tool, but it is also a security risk, so it should be disabled unless it is explicitly required.” GdD
Running a second SSH daemon on a separate port for key access only
This is a hybrid solution and allows you to keep normal access configured through the webconfig which may allow port 22 and then have a second instance SSH on a different port allowing key based access only on a second port. If you only open the port for key based access in the firewall, it allows you normal access from your LAN on your port configured through the Webconfig and access from the internet by keys only.
The steps for this are:
Clone /etc/ssh/sshd_config to /etc/ssh/sshd_config_keys.
In /etc/ssh/sshd_config_keys change:
to your chosen port and
Clone /usr/lib/systemd/system/sshd.service to /usr/lib/systemd/system/sshd-keys.service then change:
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd_config_keys $OPTIONS
Then start and enable your new daemon:
systemctl enable sshd-keys
systemctl start sshd-keys
And finally open your new incoming port.
Brute Force Mitigation
Brute force is the act of trying over and over again with different means as a way of trying all the solutions to a puzzle. While it may be akin to a trillion monkeys randomly trying to compose a work of Shakespeare, it can be done. To thwart this, active mitigation can be applied to watch SSH login attempts. There are two basic methods:
Both of these methods work and both will identify the IP address of the attacker.
The Intrusion Detection and Intrusion Preventions system can detect a number of attack vectors related to SSH security. First, they can detect failed login attempts and second they can detect port scans that are designed to reveal your changed SSH ports. There are other vectors as well that they can look at such as buffer over run attempts and others. It is important then to install these two apps and ensure that they are started and running. It is also important that you get the pattern file updates via the IDS Updates app. Without the updates, your pattern files are quite limited (and dated) in the attacks they can stop. The default pattern file is quite old.
When an attack is detected, the Intrusion Prevention system will add a firewall rule via ipset table to block the offending IP.
The Attack Detector app looks at the log file for failed login attempts. It is pretty awesome. If the threshold is exceeded, the IP is blocked by the firewall. Make sure the service is running after you install it.
Firewalling and Advanced Firewalling
Block the Port
Another way to secure this is to simply return it to being blocked by default. There are a couple ways to SSH to a box without having it open:
The Dynamic Firewall gives you a tighter and automated unblock method via Webconfig login. With the Dynamic Firewall, logging in to Webconfig can be a pre-requisite for the SSH port. This simulates a 2 factor authentication when you couple SSH with key-based authentication. After you log in to Webconfig, the configured Dynamic Firewall can open SSH to just your IP address.