Ubuntu Intrepid setup - page 1

These Ubuntu Intrepid Ibex articles will take you from a 'barebones' Ubuntu Intrepid Slice to a secured and up to date Slice ready for your server software (or whatever you use the Slice for).

Securing your Slice as soon as possible is a great way of starting your Slice administration.

Log in

As soon as you have your IP address and password for your Slice, login via SSH:

ssh root@

If you rebuilt your Slice, you may get a message informing you that the "remote host identification has changed".

When you log into a Slice via SSH, one of the security features is matching the remote host with known keys. When you rebuild a Slice, the remote host key changes. As such, your computer thinks there is something dodgy going on.

All you need to do is remove the older entry for the Slice IP:

On your LOCAL computer, edit the SSH known_hosts file and remove any entries that point to your Slice IP address.

nano ~/.ssh/known_hosts

If you are not using Linux or a Mac 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.

User administration

Once logged in to the VPS, immediately change your root password to one of your choosing.


Add an admin user (I've used the name demo here but any name will do).

adduser demo

As you know, we never log in as the root user (this initial setup is the only time you would need to log in as root). As such, the main administration user (demo) needs to have sudo (Super User) privileges so they can, with a password, complete administrative tasks.

To configure this, give the 'visudo' command, which invokes the 'nano' editor by default on Ubuntu Intrepid slices:


At the end of the file add:

demo   ALL=(ALL) ALL

When you are finished, press the key combination Ctrl-X to exit, press 'y' to confirm your saving the changes, and press the return key to save as the indicated file, '/etc/sudoers.tmp' .

NOTE: 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:

set rebinddelete

The corrected behavior will take effect after the file has been saved and nano has been opened again.

SSH keygen

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.

The first step is to create a folder to hold your keys. On your LOCAL workstation:

mkdir ~/.ssh

That's assuming you use Linux or a Mac and the folder does not exist. I will do a separate article for key generation using Putty for Windows users.

To create the ssh keys, on your LOCAL workstation enter:

ssh-keygen -t rsa

If you do not want a passphrase 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 Slice.

The other file is your private key. Never show, give away or keep this file on a public computer.

SSH copy

Now we need to get the public key file onto the Slice.

We'll use the 'scp' (secure copy) command for this as it is an easy and secure means of transferring files.

Still on your LOCAL workstation enter this command:

scp ~/.ssh/id_rsa.pub demo@

When prompted, enter the demo user password.

Change the IP address to your slice and the location to your admin user's home directory (remember the admin user in this example is called demo).

SSH Permissions

OK, so now we've created the public/private keys and we've copied the public key onto the Slice.

Now we need to sort out a few permissions for the ssh key.

On your Slice, create a directory called .ssh in the 'demo' user's home folder and move the pub key into it.

mkdir /home/demo/.ssh
mv /home/demo/id_rsa.pub /home/demo/.ssh/authorized_keys

Now we can set the correct permissions on the key:

chown -R demo:demo /home/demo/.ssh
chmod 700 /home/demo/.ssh
chmod 600 /home/demo/.ssh/authorized_keys

Again, change the 'demo' user and group to your admin user and group.

Done. It may seem a long set of steps but once you have done it once you can see the order of things: create the key on your local workstation, copy the public key to the Slice and set the correct permissions for the key.

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, check, and add are:

Port 30000                           <--- change to a port of your choosing
Protocol 2
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
UsePAM yes
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.

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.

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 put the private key on a work computer).

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.


As said, the 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 that we are logged in as the root user. This is the only time we will log in as the root user. As such, if you are completing this step at a later date using the admin user, you will need to put a 'sudo' in front of the commands.

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; if you or another admin user for this slice has worked through these or similar steps previously, this file may not be empty:

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. Don't forget to change the port number '30000' to whatever you specified in sshd_config.

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.

Logging in as the new user

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...

As you have an already established connection you will not be locked out of your ssh session (look at the iptables config file: it accepts already established connections).

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@

Change '30000' to whatever value you specified in sshd_config and the iptables rules.

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: demo login


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

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


Article Comments:

mdc commented Sat Jan 17 18:06:27 UTC 2009:

Just a quick note on /etc/ssh/ssh_config,

It looks like X11Forwarding has become the directive ForwardX11 . Do they have the same effect?

Will Olbrys commented Tue Feb 03 07:49:11 UTC 2009:

If after running through the visudo section of this article you notice you cant sudo using your chosen username, it's because you have to restart the server.

  1. enter the command: "visudo -c"
  2. To reboot the server FIRST COMPLETE THE IPTABLES SECTION OF THIS ARTICLE then enter "shutdown -r now".

I don't know of a way of adding a sudoer without rebooting, so if its possible please correct me.

Jeff Sheffield commented Sun Feb 08 19:34:58 UTC 2009:

thanks, you guys-n-gal's are making this incredibly simple. I feel much better knowing a-firewall (all be it a simple one) is configured on my my new slice... and it took like 10 min's. THANKS! I was ready to scour the net for how to do this and spend the day doing it.

Sir Granticus commented Tue Feb 10 03:14:56 UTC 2009:

Excellent article. I would like to note that during the ip tables configuration I was unable to issue the command "iptables-save > /etc/iptables.up.rules" when I wasn't the root user. It would return a Permission denied error. Using the sudo command would also return a permission denied error (very strange).

So I used the command "su" to switch to root and then the command worked fine.

zenzike commented Tue Feb 10 19:08:25 UTC 2009:

Very nice article. The only trouble is that I have: WARNING: Do not edit this file, otherwise your changes will be lost. # Please edit template /etc/network/interfaces.template instead.

at the top of my /etc/network/interfaces file, so I'm not sure what the best thing to do is.

Also, you should probably explain where exactly the pre-up line should go, and why it's there.

jacannon2 commented Wed Feb 11 15:20:38 UTC 2009:

I got through your article just fine all the way to iptables, and then I ran into a problem.

When I tried to run this command: iptables-restore < /etc/iptables.test.rules

It told me:

Bad argument 'REJECT'
Error occurred at line: 6
Try 'iptables-restore -h' or 'iptables-restore --help' for more information.

This is what is on line 6:

-A INPUT -i ! lo -d REJECT

I can't figure out what happened. Did I do something wrong?

PickledOnion commented Thu Feb 12 14:22:17 UTC 2009:


Not sure about the error.

I suspect if you copy & pasted the example rules, you may have missed a single character at the end or beginning. Or it may have added extra spaces to the lines.


Chris Martin commented Sat Mar 07 23:12:35 UTC 2009:

Great article. Thanks! All of the commands worked for me on my base Ubuntu Intrepid install.

Chris Martin commented Sun Mar 08 01:53:48 UTC 2009:

To change the visudo editor from nano to another editor altogether (vi, emacs, etc.), use the command (as root): update-alternatives --config editor

Chris Martin commented Sun Mar 08 02:23:15 UTC 2009:

A good link for IPTables configuration:


Allowing all traffic from another slicehost server:

-A INPUT -s 10.x.x.x -j ACCEPT

(Replace 10.x.x.x with the other slicehost server's internal IP address)

Marty Falatic commented Tue Mar 31 07:49:20 UTC 2009:

Thanks for the excellent tutorial! And thanks for the rescue console too... a silly mistake was quickly rectified with it - I changed my SSH port in sshd to one thing and in iptables to something else and restarted the daemon. Total security ensued. :-o

@Sir Granticus: you can't write to /etc unless you are actually root (even with sudo you can't redirect output to a root-only area with ">"). Workaround: save to a local file, then use "sudo cp" or "sudo mv" to copy or move that file to /etc.

tripdragon commented Tue Mar 31 22:59:42 UTC 2009:

If you HOPEELESSLY lock yourself out and are using the ajax console to fix things before the iptables

flip back the #PasswordAuthentication yes and AllowUsers demo Make sure you have a user named demo.

I locked my self out 7 times :P and reinstalled the server slice over and over.

This I time I just watched it step by step instead of one huge go.

in tandem nano /etc/ssh/sshd_config /etc/init.d/ssh reload

now I go for the iptables! Woot .

Sam commented Sun May 24 03:25:19 UTC 2009:

I just did this, but changed the firewall part to use Ubuntu's ufw firewall. Simple and straightforward.

This is an entertaining tutorial:


chillipepper commented Tue May 26 19:39:04 UTC 2009:

"I will do a separate article for key generation using Putty for Windows users." -what happened to this explanation? I am using Putty on Windows and can't do the key gen part of this article.

Eric Marden commented Wed Jun 17 09:35:44 UTC 2009:

It should be pretty easy to adapt the instructions above with the knowledge of puttygen:


gman commented Thu Jul 23 16:03:36 UTC 2009:

i followed this article to the 'T' and it worked a treat EXCEPT i also had to uncomment this line in the sshd_config file:

AuthorizedKeysFile %h/.ssh/authorized_keys

thanks for great articles and a great service :)

tiberius commented Fri Jul 24 03:04:11 UTC 2009:

This is almost certainly a dumb question. What's wrong with leaving ssh on 22?

Chris commented Fri Jul 31 21:15:10 UTC 2009:


The slicehost articles about using putty in general and about using putty to generate the private/public keys are here: https://articles.slicehost.com/windows

incolo real estate commented Thu Aug 13 23:18:47 UTC 2009:

@tiberius - it's a common port so if anyone was to attempt to attack through a known exploit in SSH, 22 would be the first port that would be tried. putting it at a random port makes hacking a lot tougher.

thanks mike for a great article!

GM commented Tue Sep 29 05:04:53 UTC 2009:

When I did this, there was no etc/network/interfaces file. I am using ubuntu jaunty though. What do I do?

Brian commented Mon Nov 30 06:01:17 UTC 2009:

After following these steps try this to make sure you got the iptable stuff right. If you made a mistake but you don't try this now, you'll have a lot of problems the next time you reboot (which could be months from now) and you won't know why:

sudo reboot

Then log in again (use the AJAX console if you're locked out) and type this:


This should ping localhost. If you get no response, double-check the steps in the "iptables" section above.

jay commented Tue Dec 22 23:03:00 UTC 2009:

On Ubuntu 9.10 Karmic Koala running the command "iptables-restore < /etc/iptables.test.rules" gets the following error message "Using intrapositioned negation (--option ! this) is deprecated in favor of extrapositioned (! --option this)."

mohan commented Fri Jan 08 06:15:27 UTC 2010:

How to find the putty configuration file in machine? ubuntu install in that machine?

Jeff commented Fri Jan 15 21:54:01 UTC 2010:

How do I setup another machine so I can SSH in? Right now I am being denied because of the public/private key setup but I am not 100% sure what I should do on my second machine (local).


Phillip Harrington commented Wed Feb 03 20:25:22 UTC 2010:


I got this to work on Karmic Koala by changing this line (around line 6):

-A INPUT -i ! lo -d -j REJECT

To this (not the -i and ! are transposed):

-A INPUT ! -i lo -d -j REJECT

Thank you Google.

Phillip Harrington commented Wed Feb 03 20:30:21 UTC 2010:

Oops that should be: "To this (NOTE the -i and ! are transposed)"

mandm commented Thu Sep 30 02:05:51 UTC 2010:

X11Forwarding no UsePAM no UseDNS no

whats the importance of setting these parameters?

Jered commented Fri Oct 01 19:02:32 UTC 2010:

The "X11Forwarding" setting tells SSH whether or not to forward X-Windows to your workstation. It's only useful if you install X-Windows on your slice and run it there.

UsePAM tells SSH whether or not to use the PAM authentication manager. I need to update this article, looking at it - that should be "UsePAM Yes". The "no" recommendation is based on an old security concern that doesn't apply anymore.

UseDNS tells SSH to only accept connections where the IP address of the client matches up with the reverse DNS of the hostname for the client. It can be nice for security, but many users aren't connecting from a client where they control the DNS for the IP address they're coming from (like connections from home). So it's easier to turn off UseDNS, since it's more likely to cause problems for users than to protect them from intruders.

Chris Hughes commented Thu Sep 15 21:44:23 UTC 2011:

You're a champion! I've never used Ubuntu (Windows user, yikes!), but this article was crystal clear.

I realize it was written a long time ago now, but it is still providing tremendous value.

Thanks! Chris

Want to comment?

(not made public)


(use plain text or Markdown syntax)