SSH, the data-encrypting protocol we use for administering the server via a terminal shell – and that the Cop introduced in Setup SSH for Secure Server Login – gives a super-secure tunnelled connection straight out of the box.
Basically, ssh allows you to interact with the server without fear of a man-in-the-middle attack that could otherwise, for example, sniff out your server credentials.
In the above-mentioned tutorial we set up the authentication keys to give you a password-free yet more secure method of access and, if you haven't, you really should follow that guide although you should absolutely follow this one too, irrespective of whether or not you have swapped your password for a keyset.
That's all well and good but, with those keys set up and testing OK, we must tighten the SSH configuration to deny, entirely, the dreaded brute force password attack that can severly compromise a server, a site, a business and a hairline.
For the OpenSSH brand of SSH, again as confirmed or installed in the proceeding how-to, we'll first copy the configuration file, sshd_config, for safety before bolstering it using, in this case, the nano text editor:
In the sshd_config file you need to look for the following directives, following the instructions for each parameter. For instance, the first line to look for is Protocol 2 …
- Protocol 2
- Port 22
A local-to-remote SSH link connects to the server on port 22, by default.
While a scan may discover this port, whatever it's set to, for instance using NMAP as we did in How to Use NMAP to Map Out a Network, it makes sense to change the SSH port, especially if you don't disable password access, because this will counter the many automated scripts looking for the default, 22, before trying the brute force hack.
Pick a five digit value somewhere under, say, 60000 and replace Port 22 with that, for instance using Port 54321 or Port 12345, but less obvious. Save the configuration file and restart the SSH service like this:
Now, enable the new port in your firewall and disable 22 as explained in the Cop's Setup an iptables Firewall.
… Basically, for Windows, that means trading 22 for your new port number in a SSH client such as Tunnelier or PuTTY. For local Linux or a Mac using the in-built terminal, you add the -p switch with the new port number to the SSH command:
- PermitRootLogin yes
This default parameter tells the server to allow the root superuser to log in. Talk about a red flag for a brute force, you should change this to:
The only sensible reason to permit root to log in – ever – is when your server is first launched. That's because root, at that time, is the only user able to log in and, of course, someone has to open up shop. But once that's done, and a human administrator's user account is created which can also log in, root no longer needs this privilege.
As with changing any directive in the SSH settings file (or batch of directives if you're doing everything in one go, which is fine) you'll need to restart the service before the change is actually made:
- PasswordAuthentication yes
The PasswordAuthentication setting is for allowing password access, else denying access if instead everyone who needs access are using authentication keys.
Rarely is there a need to leave this setting enabled. Using authentication keys is vastly safer as we have covered. If you connect from many PCs then carry PuTTY Portable on a thumbdrive along with your private authentication key, else you can keep your key on a portable Linux distribution if you're a Mac or Tux type. Multiple users can, and should, have their own individual keys too, so no excuse there!
- AllowUsers USERNAME
This will not be in the SSH file, by default, but is the directive that denies all users except for those specified. That is powerful defense but, then again, don't assume that your username isn't guessable or traceable.
Add this to the bottom of the file to allow logins from your specified users, maybe just you in which case just add your username. Multiple usernames can be space-separated like so:
As mentioned, SSH registers no changes until it's restarted. Sorry to nag, again, but DON'T CLOSE YOUR EXISTING TERMINAL CONNECTION.
Just do this:
If the worst comes to the worst then you have the sshd_config backup that we created at the top of the tut. This command scraps our changes above and reverts the SSH settings to those of the original file:
… You could at any time use that command, then start again quite happily.
When everything's working, tidy up by deleting that backup:
Cool beans. Following that guide was a highly sensible move.
We'll consider an advanced use of SSH now, and one that's brilliant for WordPress and other sites in development or if you just want to allocate some server space for, say, file sharing, in Setup chroot SFTP Jail for WordPress using OpenSSH.