As important as securing direct access to our WordPress sites is securing indirect access to the application via the server. Here's the deal.
We can figure out the attack routes easily enough because we use them too: server login, FTP, MySQL clients like phpMyAdmin and control panels are all targets for brute-force password attacks and, just like the more obvious WordPress wp-login.php page, these need toughening up.
So far as the server goes, as we find in wpCop's Server section, there's a whole lot more to securing the thing than creating a secure login process. This, though, is the natural starting point.
So what's the difference between server login and control panel login? The control panel is simply a software package, a set of tools that helps us to tweak settings and run tasks in a user-friendly way. The control panel sits on the server, just like other helpful GUIs such as file browsers (for instance, FileZilla) or database managers (for instance, phpMyAdmin).
Hush it up with SSH
For the most direct server manipulation we use a terminal, a console, a shell, a command line interface (CLI) or whatever else it's called today. We tap out commands locally that are enacted remotely. This tool gives us the greatest flexibility to build and maintain sites and the underlying technologies that make them work. With power comes responsibility.
If we can access the server, generally messing it up, who else can?
Cue SSH.
SSH stands for Secure Shell and that's just what it does, using a kind of revamped SSL protocol to shield or tunnel our terminal logon and dataflow. SSH can be tweaked so tight it squeaks, and we'll be doing that in the Cop's Harden SSH guide. For now though we'll crack out the basics, setting it up so that we have a properly encrypted server connection to work with.
Shared hosting SSH request
Shared types will have to request direct server access and this will be provided using SSH. You can often do this in cPanel easily enough:
cPanel > Account Addons > SSH Activation Request > submit your email
Then again, you could just shortcut that palaver altogether and submit a ticket, else jump the queue by making a live chat request. (Hey, you didn't hear it here.)
Once authorized, you're halfway there. You need to set up a terminal locally, so skip down to the ingeniously titled Setting up the Terminal Locally for how to do that. With the local terminal in place, connect remotely by typing a command like this:
And here's what that means:
- ssh – the protocol to use
- -p – you need to add this and the port number only if the server is accessed using a non-default port (that is, not the SSH default port 22). Your web host will tell you if you need this
- 54321 – if the port isn't 22 then provide the non-default port
- username – your server handle, often matching the control panel username
- @123.45.67.890 – at your IP address (your control panel tells you what that is)
When you connect for the first time, you'll be asked to verify that the destination is safe. Do. Then you are prompted for your shared hosting account password and, hey presto, what on earth do you do now that you're in? Damn, where to start! Carry on.
Setting up the terminal locally
This varies from system to system. Let's cover the bases.
- Linux or Mac locally
- Windows locally
For those of us using Windows we'll install some software to make logging in a snap. There are others, but two choice SSH clients are PuTTY and Tunnelier. Each has its pros and cons but Tunnelier is easier to set up and more fully-featured, sporting an SFTP client for example. While PuTTY is free, period, Tunnelier is only free for personal use:
Weighing up the two, we'll work with Tunnelier which is kinder to SSH noobs.
Setting up Tunnelier
Tunnelier has made the process far too easy. Download, install and run the package, merely adding your server details in the panel as shown here:
Setting up server details in Tunnelier
You can save and later edit or load profiles and click on Login to make the connection.
Securing the terminal
As with SSL, packet sniffing is no real concern when we use SSH because it would take so long to decrypt our encrypted data. Put it this way, we'll all be dead first and the hacker would need a medium. That said, with bots hacking away, automated, brute force password cracking remains an issue.
… To deflect that risk we enhance SSH by using authentication keys and denying password login. Here's how. You get a key, the server gets a key, the keys have to tally and then you're in. Otherwise, hack off! You can use your key from anywhere by thumbdriving it. Sweet.
There are three steps to setting this up. Creating the keys, uploading one to the server, and telling the server to refuse passwords. Here we go.
- Creating keys: Linux or Mac locally
- Creating keys: Windows locally
In Tunnelier's Login screen, click on the User keypair manager link to open the tool, then on Generate New, leaving the defaults, and adding a passphrase (as recommended in the Linux or Mac section above). Now, highlighting your new keypair entry, click on Export and in the new dialogue box leave the defaults and again click Export, saving as a text file to somewhere snug.
Open the text file and you'll see something like this. For this key to work we need to delete Tunnelier's superfluous text and spacing. All that you want to keep is highlighted in the screenshot. Be careful to keep those two equal signs – == – at the end of the key though:
Editing the public authentication key is fiddly. You have been warned!
- Uploading keys (all systems)
Now, logged into the remote server, type these commands to ensure that you are in your home directory, creating a hidden directory, .ssh, and a file within called authorized_keys.
Copy and paste your edited key to the authorized_keys file.For those using Tunnelier, add ssh-rsa to the beginning of the key followed by a single space. Also, carefully delete the spacing at the end of each line so that the key occupies a single line. (Yes, very silly maybe for Windows people this seemingly simple task is quite a tease. Just get Linux!)
For those using Macs or Linux your newly pasted key will work as is. (No comment!)
For everyone, what is now visible will look like this, all formatting having been stripped and with that ssh-rsa prefix. Note that this screenshot doesn't show the whole key which, being long and not wrapping, runs off the terminal screen. That's fine, leave it like that.
Pasting SSH' public authentication key to the remote server
We'd best set the correct file permissions. Swap USER for your server username:
Cooking on gas! We're nearly there.Windows users need to open a second instance of Tunnelier and, at the Login screen, this time change the Initial method value to publickey and add your passphrase in the box below that, clicking on Login.
Macs and Linux users equally should open a second terminal and give the same command as before.
In any case, if the keys are set up properly you'll no longer be prompted for a password which we can disable and, along with some other supersonic SSH sweeteners, we'll get around to doing in wpCop's Secure SSH guide.
All that done, not only is the logging in process considerably easier but passwords will not be accepted at all, negating the brute force threat. Take tea.
Using keys from multiple machines
Ah yes, you were wondering about this, huh? Well, yes you can.
Referring back to the Portable applications section of Stay Safe on a Shared Computer, you can carry an SSH client on a thumbdrive along with your local, private key, logging in with that from anywhere.
… So hey, no excuses, blog from the pub, go sshssh a bit and don't spill the beer. 😛
Other than for tightening SSH which we'll be doing in Harden SSH the Secure Shell for Safe Server Access, that's the server login properly defended and with our data protected en route.
Praise be. Have a cigar.
