Ubuntu LTS setup - page 1

In this Ubuntu LTS setup guide, we have a basic Ubuntu LTS slice, either a new slice or a reinstalled slice.

Now we need to access the slice and secure it as soon as possible.

Log in:

On your LOCAL computer, edit the SSH known_hosts file and remove any entries that point to your slice IP address. If this is a brand new VPS then you will not need to do this, but an OS reinstall will result in a different signature.

nano ~/.ssh/known_hosts

If you are not using Linux on your LOCAL computer, the location of the known_hosts file will differ. Please refer to your own OS for details of where this file is kept.

Using your IP address and password for your slice login via SSH:

ssh root@

User administration

Now we're logged in to the VPS, immediately change your root password:


Next we'll add an admin user (I've used the name demo here but any name will do).

adduser demo

As demo is our main administration user (we don't log in as root!) he needs to have sudo (Super User) privileges. We give those permissions via the visudo command:


At the end of the file add:

demo   ALL=(ALL) ALL

SSH preperation

One effective way of securing SSH access to your slice is to use a public/private key. This means that a 'public' key is placed on the server and the 'private' key is on our local workstation. This makes it impossible for someone to log in using just a password - they must have the private key.

This is very simple with ssh-copy-id.

We already have our admin user created (demo), so on your local workstation enter the command:

ssh-copy-id -i ~/.ssh/id_rsa.pub demo@

We use the -i option to specify which file (identity) to copy across to the slice. The user is then specified followed by the IP address of the slice.

So what happens when the command is entered? Firstly you will need to enter the user's password so it can have secure access to the slice. Then it creates a 'hidden' directory called .ssh and copies the public key to a file named 'authorized_keys'.

It then automatically changes the permissions so that only the owner (demo) can read or write to the file. Neat.

It's always a good idea to check the settings on something as important as this so let's have quick look at the permissions:

ls -al /home/demo/.ssh/authorized_keys
-rw------- 1 demo demo 394 Sep  6 09:23 /home/demo/.ssh/authorized_keys

Perfect. You can also open the authorized_keys file and make sure only your key was copied across and it is not full of unknown keys.

Remember that this is the only time you'll need to enter the SSH password as the file we just copied over will authorise the admin user 'demo' to SSH in without it - but only if they have the private key on their local workstation: it won't work from any workstation.

SSH config

Next we'll change the default SSH configuration to make it more secure:

nano /etc/ssh/sshd_config

Use can use this ssh configuration as an example.

The main things to change (or check) are:

Port 30000                           <--- change to a port of your choosing
Protocol 2
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
UsePAM no
UseDNS no
AllowUsers demo

I think the setting are fairly self explanatory but the main thing is to move it from the default port of 22 to one of your choosing, turn off root logins and define which users can log in.

PasswordAuthentication has been turned off as we setup the public/private key earlier. Do note that if you intend to access your slice from different computers you may want leave PasswordAuthentication set to yes. Only use the private key if the local computer is secure i.e. don't place it on a machine at work, etc.


Right, now we have the basics of logging in and securing SSH done.

Next thing is to set up our iptables so we have a more secure installation. To start with, we're going to have three ports open: ssh, http and https.

We're going to create two files, /etc/iptables.test.rules and /etc/iptables.up.rules. The first is a temporary (test) set of rules and the second the 'permanent' set of rules (this is the one iptables will use when starting up after a reboot for example).

Note: We are still logged in as the root user. This is a new, or reinstalled slice, and it is the only time we will ever log in as root. If you are doing this later, when logged in as the admin user, you will need to enter the command:

sudo -i

The sudo -i command will place you as the 'root' user. You will need to do this when changing the iptables rules as it won't work by adding a standard 'sudo' in front of the commands.

So, as the root user, save any existing rules to /etc/iptables.up.rules:

iptables-save > /etc/iptables.up.rules

Now let's see what's running at the moment:

iptables -L

You will see something similar to this:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

As you can see, we are accepting anything from anyone on any port and allowing anything to happen.

One theory is that if there are no services running then it doesn't matter. I disagree. If connections to unused (and popular) ports are blocked or dropped, then the vast majority of script kiddies will move on to another machine where ports are accepting connections. It takes two minutes to set up a firewall - is it really worth not doing?

Let's assume you've decided that you want a firewall. Create the file /etc/iptables.test.rules and add some rules to it.

nano /etc/iptables.test.rules

Look at this example iptables configuration file.

The rules are very simple and it is not designed to give you the ultimate firewall. It is a simple beginning.

Hopefully you will begin to see the pattern of the configuration file. It isn't complicated and is very flexible. You can change and add ports as you see fit.

Good. Defined your rules? Then lets apply those rules to our server:

iptables-restore < /etc/iptables.test.rules

Let's see if there is any difference:

iptables -L

Notice the change? (If there is no change in the output, you did something wrong. Try again from the start).

Have a look at the rules and see exactly what is being accepted, rejected and dropped. Once you are happy with the rules, it's time to save our rules permanently:

iptables-save > /etc/iptables.up.rules

Now we need to ensure that the iptables rules are applied when we reboot the server. At the moment, the changes will be lost and it will go back to allowing everything from everywhere.

Open the file /etc/network/interfaces

nano /etc/network/interfaces

Add a single line (shown below) just after 'iface lo inet loopback':

auto lo
iface lo inet loopback
pre-up iptables-restore < /etc/iptables.up.rules

# The primary network interface

As you can see, this line will restore the iptables rules from the /etc/iptables.up.rules file. Simple but effective.


Now we have our basic firewall humming along and we've set the ssh configuration. Now we need to test it. Reload ssh so it uses the new ports and configurations:

/etc/init.d/ssh reload

Don't logout yet...

On your LOCAL computer, open a new terminal and log in using the administration user (in this case, demo) to the port number you configured in the sshd_config file:

ssh -p 30000 demo@

The reason we use a new terminal is that if you can't login you will still have the working connection to try and fix any errors.

Slicehost also has the excellent Ajax console so if it all goes horribly wrong, you can log into your slice from the Slicehost management area.

If all goes well you should login without a password to a plain terminal:



We now know that the firewall and ssh_config works and we can log in.

Let's move on to page 2 which includes updating the install and installing some base programmes ready for the 'meat' of the server.


Article Comments:

Vek commented Fri Sep 14 12:22:04 UTC 2007:

My Ubuntu slice does not have a -m option to the adduser command. My Fedora desktop at home does have a -m option that means "create home directory", but it looks like the Ubuntu version does that automatically...

PickledOnion commented Fri Sep 14 12:39:32 UTC 2007:

Hi Vek,

You're not wrong :)

I don't have it in the Feisty articles, I wonder why I left it here?

Anyway, thanks for the note - I'll take it out.


Ken commented Wed Nov 14 18:16:28 UTC 2007:

I posted this question on the forum, but maybe this is a better location. My local machine is a Mac. Apparently, the ssh-copy-id command is not included with OS X so I'm having trouble with the first step under SSH Preparation above. Is ssh-copy-id available for OS X? Should I use a different approach to accomplish this task? Thanks, Ken

madra commented Tue Nov 20 14:13:48 UTC 2007:


the instructions for SSH given on the slicehost wiki worked fine for me on OSX..

> On OSX, Unix, Linux

On your home computer, generate an RSA key:

ssh-keygen -t rsa Hit enter to accept the default options for all three questions that it asks.

Copy the key to your server. User your new username and the Slice IP address where shown

scp ~/.ssh/id_rsa.pub USER@SLICEIP:~/ The catch – if you have changed your port number, you should be refused the connection. To solve this, issue the following command:

scp -P 2000 ~/.ssh/id_rsa.pub user@sliceip:~/ Enter your password when prompted.

Now login to your slice using a normal SSH login, including your password when prompted. Enter the following three commands on individual lines:

mkdir .ssh cat idrsa.pub >> .ssh/authorizedkeys rm id_rsa.pub Change permissions to allow only the local server to see the shared key:

chmod go-w ~ chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys Now logout, and log back in to your slice. You should be able to do an SSH login without entering your password. This will also allow you to run programs that use the SSH protocol, such as rsync, to login without a password. If you would like to simplify the login process even more, add the following line to the ~/.bash_profile file on your local computer:

alias slice="ssh user@SLICEIP" Now, simply typing “slice” in your terminal will automatically log you in to your slice server without having to enter any additional login or password data.

To remove the ability to login without a password, simply remove the file ~/.ssh/authorized_keys from your slice server.

rm ~/.ssh/authorized_keys

Carl Karsten commented Thu Jan 17 19:55:47 UTC 2008:

include the user@host prmopt - at this point I should have 3 ssh sessions going, and it isn't clear which I should be doing what in.


carl@Ridgemoor:~$ ls -al ~/.ssh/authorized_keys -rw------- 1 carl carl 393 2008-01-17 19:42

root@Ridgemoor:~# nano /etc/ssh/sshd_config

or better yet: carl@Ridgemoor:~$ sudo vim /etc/ssh/sshd_config

or nano, if you insist. :)

Vince commented Wed Oct 15 03:59:25 UTC 2008:

Your articles have saved me countless hours. Thank you so much. Here's a tip for those trying to configure ssh with no luck. Make sure you are editing "sshdconfig" instead of "sshconfig".

Saket commented Wed Mar 25 11:57:52 UTC 2009:

One should also secure the sysctl:

sudo nano /etc/sysctl.conf

Read comments and enable/disable kernerl security options. Then,

sudo sysctl -p

All the best!

Glad David commented Wed Aug 04 17:25:17 UTC 2010:

preperation -> preparation

Glad David commented Wed Aug 04 18:36:29 UTC 2010:

If you change your ssh port, remember to also change it in your iptable rules (30000 is the value used in the example iptable rule file, so if you use anything else, modify the example.)

Really appreciate the tutorial!

Want to comment?

(not made public)


(use plain text or Markdown syntax)