There’s a new and improved version of this post HERE. Look at that instead.
I’ve been experimenting with servers from CloudAtCost. As such, I tear them down and re-image them fairly frequently. These are my notes on how I do initial setup of servers that have been freshly imaged with Ubuntu 14.04 LTS.
I generally start out making a copy of the server information from the CloudAtCost panel. This includes things like the IP address and the root password, which you will need shortly.
The process starts by logging into the SSH server newly imaged machine as root. The first thing to do is update Ubuntu with the following commands
This can take some time as it will upgrade a lot of files.
After the upgrade is complete, reboot the system.
This will break the SSH connection of course. So wait a few minutes for the reboot to complete, then log back in.
Next, we want to add a new user who is not root but can have all of the powers of root when needed.
Of course, the name you use can be anything, not just “user-name” (or “root”).
At this point, we can tell the system to allow the new user root access by adding them to the “sudo” group.
Now, you can log off as root and log back in as your new user. It’s important to know that you can log in with this new user because in a moment, we are going to change settings such that you will no longer be able to log in remotely as root.
Public key access is an additional method to authenticate yourself when signing into your server. It is considered to be more secure and flexible, but more difficult to set up. I think it is only more difficult in that there are more steps to do, none of which are particularly difficult. Just sayin’.
First off, you need public and private encryption keys. If you don’t know what I’m talking about, take a look here. After reading it, if you really think it’s too difficult, you can skip the remainder of this section, otherwise, follow along.
I usually start by changing the permissions of my home directory.
These permissions mean I can read/write/execute in my directory. Members of my group (usually no else at this point) can read and execute, but not write into the directory. Others can’t do any of those things.
Next you need to create a place to save public encryption keys. By convention, this is a sub-directory of your home directory.
These permissions mean that only I can read/write/execute in the
Since I do it so often, I have a file on the system that I use to set up the servers called “authorized_keys”. In that file, I have concatenated all of the public encryption keys that I tend to use on my servers. It’s just a text file that I need to be able to send to the new server. Make sure that only your public keys go in this file.
Now you need to be able to transfer that file into the
.ssh directory on the server. If you only have PuTTY to work with, it can be a bit of a chore. This is one area where the Bitvise client has an advantage – it has an SFTP (Secure File Transfer Protocol) client that provides a side-by-side listing of files on the client and the server. Copying the file is a simple matter of dragging the file from one window to the other.
If you are comfortable typing long command lines in the terminal, you can use plink.exe (one of the programs installed with PuTTY) to complete the transfer in a single line. From the directory where PuTTY is installed, type:
Use the appropriate user name, server IP address and server password for your account. If you have any problems or this looks too intimidating, grab a copy of the Bitvise client and use its’ SFTP program.
Next, set the permissions on the newly transferred file.
These permissions mean that only you can read or write the file.
Now we want to change some of the things about the way the SSH program works. I change my settings such that SSH no longer uses the default port, no longer allows root logins to SSH, and allows only specific users to log in. As a super user, fire up the nano editor on the
First look for the line that says “Port 22” and change it to “Port 1935” or some other number. This line is about the fifth line in the file on my system.
Then find the line that reads “PermitRootLogin yes”. Change “yes” to “no”.
Next, go all the way to the bottom of the file. Add an empty line and the following:
The lines beginning with the “#” character are just comments to remind us of who made the change. Again, substitute your actual user name for “user-name”.
Close the file and save it (Ctrl-X, “y”, Return).
Now, restart the SSH service with:
The process number you see is likely to be different.
Now you need the change the firewall configuration a bit to let SSH listen on the port you specified in the
It’s likely that the time zone is already set correctly, but you can check with:
You can assure synchronization with the Network Time Protocol (NTP) by installing the ntp package.
At this point, you should be set up and ready to go.
##Update: 17 Mar 2016##
Fail2ban is daemon that monitors frequent attempts to log into your system, and probing for exploits. It will ban IPs that repeatedly exhibit these suspicious activities. It’s easy to set up and is pre-configured to work pretty well. It’s “set it and forget it.”