If you're following this series, you probably just want to get on and set up the web server, add the sites and host away. Sure, understandable.
But just like you don't build a house on sand, you can't set up a quality Linux host without first laying a secure foundation, ensuring a strong unmanaged VPS solution.
Video: Solidify Server & Remote Shell
Harden the Secure Shell (SSH)
Logged in at the CLI, type this to open the SSH configuration file:-
.. If you get a message like:-
.. Or maybe something less cryptic, such as:-
.. then guess what, that's because we need to install Nano (which is a nice user-friendly text editor). Do this:-
.. and type y for yes when prompted, hitting return. The screen will spiel off and there may be some nagging about your locale not being set properly .. tssk, Linux is soooo impatient .. just pretend it's the wife and ignore it. (Sorry, female VPS'ers .. you do know I'm only joshin' huh 😛 . Well, ish.)
Er, that sudo thing, hmmn …
What the Bejeebers is sudo?
sudo, prefixing an Ubuntu command, gives our non-root user Super User permissions.
Then, for example, we can make core configuration changes that otherwise we could only perform by logging out, then back in as root (…then back out from root and back in to our regular username.) Wharrapalava!
When you use sudo, you'll be prompted to give the root user password. That's a good thing: it means you will be more aware that you are, potentially, playing with fire and, if the answer isn't here, ‘cue Google'.
Right, so that's all pretty crystal. Forgot where I was now. Oh yes, we did this:-
In this config file, find and change the following values. Here's a little detail, too, if you really want to know:-
| Port 22 | change default port 22 ie to “Port 54321” to confound hackers |
|---|---|
| PermitRootLogin yes | change “yes” to “no” to refuse root login * |
| #PasswordAuthentication yes | uncomment the line (lose the #) and change “yes” to “no” to prevent login using a password (unnecessary risk with authentication keys) ** |
| X11Forwarding yes | change “yes” to “no”. X11 is a protocol enabling a GUI option |
| UsePAM yes | change “yes” to “no”. PAM is a password authentication agent |
And add 2 lines at the end of the file:-
| UseDNS no | This prevents possible reverse host lookup problems |
|---|---|
| AllowUsers $USER | substitute “$USER” for your username. More users? Add the usernames alongside separated by single spaces *** |
* With some unmanaged VPS providers like Linode or Slicehost, you can use the Ajax Console to login as root, in case of emergency.
** If you want to connect to your Linux distro from computers other than your main Windows box, using your user password rather than the PuTTY authentication keys, leave this set to “no”.
*** Very rarely – and usually never – will you want to add the root superuser to the AllowUsers list.
We'll reload SSH to realise these changes. But first…
Set Up A Firewall Using iptables
Oh yes, good point.
Thing is, me old China, that we will be needing a firewall, and we also want a nicely tightknit SSH connection, and it's all rather ‘chicken and egg'. Building a server, we are wanting both elements, right here right now.
Consider: what does a firewall do? Pretty much, it denies access to ports, those doorways that traffic otherwise flows through, because we don't want any old hacker traffic coming through just any old port now, do we?
But. (There's always a ruddy but.)
But we do need to be able to access the server – using SSH and a special SSH port (yes, you see where I'm going with this now!) – and so, when we set up our firewall, we must allow for that, we must ensure the SSH port is open.
So, hey, TAKE A DETOUR:-
Or if you really want a pretty GUI-based firewall (which you could alternatively add later and I recommend just installing the basic iptables firewall, above, for now), then you can do this:-
Simplify iptables with ConfigServer Firewall
When you're done with that, COME BACK TO HERE.
Testing SSH
NOTE: Don't logout from the CLI. JUST DON'T! Yet.
Reload SSH, enabling those new settings from above:-
What you do now depends on whether, locally, you're running Linux or a Mac, else are just getting by with Windoze.
Testing SSH with Linux/Mac
.. where:-
- -p says we're about to specify a non-default port
- 54321 is your new port as designated in the sshd config file
Testing SSH with Windows
Obviously, this takes longer ..
Open PuTTY. If you've followed Encrypt Data with OpenSSH & Auto-Login with PuTTY of this series – you did do that, didn't you?! – then right-click the Pageant icon (the monitor wearing the hat, looks like a spaghetti western character, minus his cheroot) and click New session. If you didn't follow the Part 5, I guess you know what you're doing 😉
Right, we need to make one simple change in our PuTTY configuration, to the Saved session profile we created in Encrypt Data with OpenSSH & Auto-Login with PuTTY. Do this:-
Click on your new Saved session profile (mine was called guv Session in the video, if that helps), then click Load.
In the Port field that currently says 22, you got it, add the new port number. My new number is 54321.
Now click Save.
Cross your fingers.
Double click the Saved session profile. All being well, you'll get another one of those security alerts, that we saw in Set Up the Command Line Interface (CLI) using PuTTY. Click Yes. You're in. Great, you can log in and out, at will.
If that didn't work for you, retrace your steps, using that CLI we kept open. (You may need more caffeine.) In a worst case scenario, as I said above, many VPS providers have an emergency shell access. MyHosting, for example, has their Ajax console.