This guide is intended to be used in an environment where you have a barebones install of Debian 6.0 server. This could be on one of the various cloud platforms such as Rackspace, AWS, Linode, and others or on a bare metal box after you’ve performed a minimal installation.
I aim to take you from a barebones install to a secured and up-to-date configuration which you can then use for a variety of implementations (we’ll cover some of the more common in a future guide).
This is part 1 and I’ll post the follow-up guides as quickly as I can. This is enough to get just about anyone started though.
CREDITS: Some of this material I’ve pieced together from various sources including some old Slicehost articles for previous versions of Debian and this excellent post a few weeks ago, plus a few of my own insights.
I’m going to assume that you’re using a hosted environment here for simplicity. We’ll begin by connecting to your new server/instance/VM via SSH (secure shell). On a Mac or Linux environment you’ll want to run these commands from your terminal app. If you’re running Windows you should pick up a tool such as PuTTY.
As I mentioned above, we’ll be connecting to the new server via SSH:
When you first connect to a new or unrecognized server, one of the security features is matching the remote host with known keys. Since you know what machine you’re connecting to you can simple choose yes:
The authenticity of host '22.214.171.124 (126.96.36.199)' can't be established. RSA key fingerprint is 7c:06:8a:6d:ec:19:b9:fa:5b:cc:30:fc:91:3d:10:29. Are you sure you want to continue connecting (yes/no)?
If you are connecting to an IP that was previously used and is therefore already in your known_hosts file this is a quick fix. On your LOCAL computer, edit the SSH known_hosts file and remove any entries that point to your server IP address.
If you are not using Linux or a Mac on your LOCAL computer, the location of the known_hosts file will differ depending on the program you are using. You’ll need to refer to the documentation for that program for details. For example, PuTTY stores its known hosts in the following registry entry:
Now that we’re logged in to the server, immediately change your root password:
We should also update the system before we go any further:
aptitude update aptitude full-upgrade
Apart from this initial setup, you should never log in as the root user. It’s safer and more secure to create a new administrative user and use the ‘sudo’ command from that user. Having to use sudo to run superuser commands can help prevent some potentially system-breaking accidents, and it also means that any root-level commands run through sudo will be logged to ‘/var/log/secure’ if later review is needed.
Let’s issue the ‘visudo’ command to edit the sudo configuration:
The visudo command runs a default editor, and will check the configuration for any syntax errors before saving it. The default editor for Debian is ‘nano’.
Scroll down and look for this section of the file and add the following line for your user:
# User privilege specification root ALL=(ALL) ALL demo ALL=(ALL) ALL
Save and exit the file and now sudo is all set. Specified users will now have full sudo privileges.
TIP: Some users will find that while working in the nano editor, the backspace/delete key works backwards, deleting characters in front of the cursor rather than behind it. This can be resolved by editing the ‘/etc/nanorc’ file (with nano, for example) and either uncommenting or adding the line:
The corrected behavior will take effect after the file has been saved and nano has been opened again.
Adding A New User
Now we’ll create a new administrative user:
You will be asked to set a password for the new user. The other fiends can be left blank if you prefer.
SSH Key Generation
One feature of SSH is the ability to require users to use, instead of a password, a “key pair” for authentication. Under this approach a user generates a public and private key pair on their workstation and then uploads the public half of the key pair to the server. When they go to connect later the server tries to match up its public key with the user’s private key in order to authenticate the connection.
Using a key pair with SSH is good security policy, which is why we’ll walk you through the process here. A password can be guessed through sheer brute force (running a program to try different character combinations until it gets a match), but a key pair is vastly more complex. It is almost impossible to crack a key pair with a brute force approach.
Note that using a public/private key pair is impractical if you need to log in to your server from a workstation that is shared with other users. While you can copy the private key to another workstation, putting that key on a shared workstation would defeat the purpose of the key pair’s security. In that environment, continuing to use a password for SSH access would make sense.
The first step to using key pair authentication is to create a folder to hold your keys. On your LOCAL workstation:
This assumes you use Linux or Mac OS and the folder does not exist. To create the ssh keys, on your LOCAL workstation enter:
ssh-keygen -t rsa
If you do not want your key to require a passphrase when used then just press enter when prompted.
That created two files in the .ssh directory: id_rsa and id_rsa.pub. The pub file holds the public key. This is the file that is placed on the server. The other file is your private key. Never share this file with someone else or store it on a public computer.
Now we need to get the public key file onto the server. We’ll use the ‘scp’ command for this as it is an easy and secure means of transferring files.
On your LOCAL workstation enter this command, substituting your new username and the IP address of your server:
scp ~/.ssh/id_rsa.pub firstname.lastname@example.org:
When prompted, enter the user password. When that’s done you should see scp copy the file to your users home directory.
On a Windows machine you’ll want to use a third-party client like WinSCP, using the information above to make the connection.
So now we’ve created the public/private keys and we’ve copied the public key onto the server. Now we need to sort out a few permissions for the ssh key.
On your server, create a directory called .ssh in your home directory and move the pub key into it:
mkdir ~demo/.ssh mv ~demo/id_rsa.pub ~demo/.ssh/authorized_keys
If you haven’t run into it before, that squiggly character is the ’tilde’, and it’s usually in the upper-left of your keyboard. In the Linux shell it can be used as a reference to a user’s home directory. Using ‘~’ by itself refers to the current user’s home directory, while using it like we did above, ‘~demo’, refers to the home directory of user ‘demo’. It’s a handy shortcut to know.
Now we can set the correct permissions on the key:
chown -R demo:demo ~demo/.ssh chmod 700 ~demo/.ssh chmod 600 ~demo/.ssh/authorized_keys
Again, replace the ‘demo’ user and group above with the name of the user you created.
If you need to add more users to your system, now or after you finish this initial setup, you can just run through the steps above again for each user. If the user doesn’t need to have administrative privileges, skip the part where you add the user to the ‘sudoers’ group.
If the user will be accessed from the same workstation as your administrative user, you can re-use the same public SSH key for the new user.
Next we’ll tweak the default SSH configuration to make it more secure:
The main things to change (or check) are:
Port 30000 <--- change to a port of your choosing Protocol 2 PermitRootLogin no PasswordAuthentication no <--- if using SSH keys for auth UseDNS no AllowUsers demo
NOTE: The port number can readily be any integer between 1025 and 65536 (inclusive), but should be noted for reference later when any additional listening processes are setup, as it will be important to avoid conflicts.
If you need to allow remote logins for more than one user, add the additional users to the 'AllowUsers' setting separated by spaces.
The labels are fairly self explanatory, but the main security changes to make are to move ssh from the default port of 22 to one of your choosing (we use 30000 in the example), turn off remote root logins, and define which users can log in remotely.
PasswordAuthentication has been turned off because we setup the public/private key earlier. Do note that if you intend to access your server from different computers you may want leave PasswordAuthentication set to 'yes'. Only use the private key on a secure workstation.
Note that we haven't enabled the new settings — we will restart SSH in a moment, but first we need to create a simple firewall using iptables.
Firewall / UFW
Now that we have the basics of logging in and securing SSH done we need to configure out firewall. We can add rules for iptables by hand but this can be tedious and I'm going to recommend a simpler method for now. It does not hurt to learn more about itpables directly and there is no shortage of tutorials available.
We'll be using UFW (Uncomplicated Firewall) to configure iptables, but first we need to install it:
sudo aptitude install ufw
Now we can set our rules and enable our firewall with a few quick commands:
ufw allow 30000 <--- the port we set for SSH earlier ufw allow 80 <--- to allow HTTP traffic ufw allow 443 <--- to allow HTTPS traffic ufw enable
You can verify what rules you have set by either running:
sudo ufw status
Now that we have our basic firewall configured and we've set the SSH configuration it's time to test and verify that everything works as expected. Let's reload SSH so it uses the new port we set earlier:
DO NOT LOG OUT AS ROOT YET!
Log In As New User
On your LOCAL computer, open a NEW terminal and log in using the administrative user (in this case, demo) to the port number you configured in the sshd_config file (for our example, 30000):
ssh -p 30000 email@example.com
The reason we use a new terminal is that if you can't login you will still have the working root connection to try and fix any errors.
If all goes well you should be greeted with a plain terminal prompt like this:
Success! We now know that the firewall and sshd_config work and we can log in.
Coming next we'll review the steps to update and install some key software on our server. Stay tuned!
Comments and feedback welcome. I'm sure there others who have some deeper insights and I'm happy to update this article accordingly if there is a better way.