Ubuntu Gutsy setup - page 1

These Ubuntu Gutsy articles will take you from a 'barebones' Ubuntu Gutsy 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

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 Slice then you will not need to do this, but a reinstall will result in a different signature.

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.

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

ssh root@123.45.67.890

User administration

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

passwd

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 he can, with a password, complete administrative tasks.

To configure this, give the 'visudo' command:

visudo

At the end of the file add:

demo   ALL=(ALL) ALL

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' 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@123.45.67.890:/home/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 your 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 (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

iptables

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.

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.

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@123.45.67.890

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@yourvpsname:~$

Success!

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.

PickledOnion

Article Comments:

rdflowers commented Thu Nov 29 04:01:42 UTC 2007:

Excellent !!!

I would suggest a little more detail in the write-up-and-look-at-your-iptables-config section.

Anatoly commented Thu Jan 03 20:27:58 UTC 2008:

Those who have Windows as local system (if any ;) could face a problem when trying to generate a key pair (server will not accept the key when authenticating). In order to avoid this, just follow instructions in section 8.2.10 of PuTTY help file. The problem with saving file from PuTTY and than copying with SCP on slice server is that OpenSSH requires public key to be placed in one line, which is not so when key is saved by PuTTY. PuTTY authors recommend copying key from PuTTYGen GUI and pasting it to authorized_keys file opened in a text editor in opened session of SSH. That worked for me.

Shane commented Thu Jan 10 07:17:40 UTC 2008:

Very nice article! Really helpful. I am new(ish) to Linux and this is my first non-shared hosting environment. I really appreciate the information.

Brian Egge commented Thu Jan 31 10:14:57 UTC 2008:

Thanks for the concise IP Tables directions. In the past, books describing IP tables have gone into so much detail, that I've given up before even trying. IP Tables is very powerful, but the example you gave should work for basic setups.

walter commented Fri Feb 29 00:14:06 UTC 2008:

I used Winscp not scp as I'm on windows, copied the ssh pub to the .ssh directory and renamed it authorized_keys. Otherwise all else is exactly the same.

I got as far as the SSH config section but I'm not able to edit the /etc/ssh/sshd_config file even as a superuser?! I added my owm "demo" user calling something else.

Tried also looking into /etc/sudoers file but it's blank. Any ideas?

Thanks

Stephen Wolff commented Fri Mar 14 13:16:54 UTC 2008:

I also got as far as editing the /etc/ssh/sshd_config file, and could not save either as root, or my equivalent to the 'demo' user.

I'm using the Ubuntu 7.10 distro, has anyone else experienced the same issue? Thanks

Stephen Wolff commented Fri Mar 14 13:30:04 UTC 2008:

I discovered that it worked while logged in as root - probably worth mentioning that in the article (just before editing ssh_config). Great stuff anyhow.

Stephen Wolff commented Fri Mar 14 13:56:47 UTC 2008:

bit of a gotcha... i initially edited:

nano /etc/ssh/ssh_config

rather than:

nano /etc/ssh/sshd_config

beware!

Skeletor commented Sat Mar 15 15:31:40 UTC 2008:

Everytime I run through the article, my root ssh session freezes up when I reload the iptables and then I cannot ssh into the machine from anywhere. This has happened twice (I reinstalled my slice from scratch.)

Kyle commented Tue Mar 18 16:35:21 UTC 2008:

Mine is doing the same thing (freezing after reloading iptables), but only when I try to use vim to edit /etc/network/interfaces - nano seems to work fine. I'll assume that this might be covered later before I start asking questions.

Kyle commented Tue Mar 18 17:14:43 UTC 2008:

...but now it's working fine. Who knows!

Daryl commented Fri Mar 21 13:45:17 UTC 2008:

Interesting.

I've always put a (similar) firewall script in /etc/init.d/ and then symlinked it to S42firewall in /etc/rcS.d/S42firewall (right after the network is brought up).

This gives me the advantage of being able to start|stop|restart the firewall via the command line /etc/init.d/firewall

Are there any security issues I should be aware of doing it that way versus your means ? (yours does seem simpler than bash scripting... ;-) )

Donnie commented Fri Mar 21 21:39:08 UTC 2008:

when executing the

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

command i get:

iptables-restore v1.3.6: no command specified Error occurred at line: 42

any idea?

marvin Hidalgo commented Mon Mar 24 19:03:32 UTC 2008:

How do you setup ssh password less login for multiple users ?

Gavin Laking commented Tue Mar 25 10:49:11 UTC 2008:

Excellent article. All secure, onto part 2 for me :-)

Ben commented Fri Mar 28 04:55:03 UTC 2008:

awesome newbie documentation!

Luke commented Sat Apr 05 17:32:50 UTC 2008:

I typed the iptables.test.rules file exactly from the example. I've never made one of these files before so I don't know the syntax or what it means at all. Upon hitting the iptables-restore command, I get the following error message:

Bad argument lo' Error occurred at line: 5 Tryiptables-restore -h' or 'iptables-restore --help' for more information.

Any idea why this might be? The only reference to this error I could find was a discussion board in German, which I unfortunately don't speak.

Robert commented Sat Apr 05 23:25:04 UTC 2008:

Try copy&pasting the config rather than typing it. There's probably just a very small typo in the file. If you still run into problems, post a link to that message board you found, I can try and translate.

Carina commented Mon Apr 14 22:15:04 UTC 2008:

On the local machine, I also needed to reduce rights on the private key (otherwise ssh complains about the key being unsafe and prompts for a password instead): chown 600 ~/.ssh/id_rsa

Greg commented Tue May 13 02:25:00 UTC 2008:

I am having the same problem Skeletor reported earlier. I've reinstalled twice already. As soon as I get to iptables -L, PuTTY freezes with a "software caused connection abort error". I've copied and pasted each section. Any suggestions would be appreciated.

Dilip commented Fri May 16 19:00:15 UTC 2008:

I cldn't succeed in the last step. Where do i look for trouble shoot info. I'm locked out via ssh

Gordon Mohr commented Mon May 26 22:41:46 UTC 2008:

With 'UsePAM no', the sshd_config recommendations above disabled my ability to login with the previously-established key. (The error given was "Permission denied (publickey).")

Switching back to 'UsePAM yes' again allowed key-based login.

hari commented Fri May 30 07:21:34 UTC 2008:

Followed the tutorial exactly, in the last step, when I try to log in ssh -p 30000 demo@123.45.67.890

I get Permission denied(public key) error.

Tried setting UsePAM yes did not help either.

Any clues.

Thanks

Kenny commented Tue Jun 03 23:01:46 UTC 2008:

Having problems with the last command. The Mac's keychain prompt comes up (3 times) and asks for the password, then I have to enter it again in Terminal. It lets me in, but it's not letting me login with only the public key.

Kenny commented Wed Jun 25 17:33:56 UTC 2008:

Strike that last comment. I needed to delete my old keys and re-create new ones.

Rob commented Sun Jun 29 14:05:50 UTC 2008:

I am having trouble applying changes to iptables to allow ftp and mysql access.

I am using:

Allows FTP connections

-A INPUT -p tcp --dport 21 -j ACCEPT

MySQL database server

-A INPUT -p tcp -m tcp --dport 3306 -j ACCEPT --syn -A INPUT -p udp -m udp --dport 3306 -j ACCEPT

and when I use iptables -L i see the rules listed, but I am getting 'connection refused' when i attempt to access the services.

Any ideas? I bet it's something basic I am missing...

Brian commented Mon Jun 30 17:26:15 UTC 2008:

Does anyone have an answer to Hari's question? I experienced the same thing: Permission denied(public key) error. Tried setting UsePAM yes but this had no effect. Please help. Thx.

gladwright commented Fri Oct 24 16:35:45 UTC 2008:

Daryl, you asked about security issues with using a startup script for your firewall, specifically /etc/rcS.d/S42firewall, which starts just after your network.

This post suggests that starting it just before your network (like /etc/rcS.d/S37firewall) is safer:

http://ubuntuforums.org/archive/index.php/t-19106.html

Bernard D commented Sat Apr 25 13:21:22 UTC 2009:

For those getting the "no command specified" error when doing an iptables-restore, be careful of extra white spaces on "empty" lines. Empty lines should only contain the return character. Any extra white space after that will indigest iptables.

HectorinMiami commented Tue Oct 20 03:09:35 UTC 2009:

A more detailed guide for setting up security keys between the server and your private workstation can be found at http://wiki.slicehost.com/doku.php?id=getstartedwithyournewubuntuslice

This is an especially great resource for you Windows users.

However, the iptables is a good add that's not included in the link.

Luke G commented Sun Nov 08 16:04:40 UTC 2009:

I am still getting the "no command specified" error on iptables-restore, and I have confirmed there is no extra whitespace in the file. What else might be causing this?

Will G commented Thu Jul 29 08:27:45 UTC 2010:

I had the same "no command specified" problem and it seems that adding a newline at the end of the file (after COMMIT) fixes it.

stim commented Thu Jul 28 13:18:24 UTC 2011:

Great tutorial - took me a few tries but got there eventually.

One difficulty I did encounter: I'm coming from windows so I prepared my /etc/iptables.test.rules in a windows text editor. On running:

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

I was getting the error: v1.4.4: iptables-restore: unable to initialize table 'filter

The problem is that my iptables.rule.file was saved in DOS format. It neeeds to be in unix format. To solve this on Ubuntu there is a little utility you can use:

sudo aptitude install tofrodos

then run

fromdos /etc/iptables.test.rules

you should then nbe able to run # iptables-restore < /etc/iptables.test.rules

May help save another windows bod a few minutes.

On to page 2! Cheers,

Jered commented Thu Jul 28 14:42:27 UTC 2011:

Good point stim. Unix, Windows, and the Mac OS all use their own way to end lines in text files. Along with "fromdos" on Linux you can also find some text editors (free ones, even) that will recognize the difference and give you a menu option to save in Unix format before you upload. That way you can keep maintaining the file on your computer and not need to convert the file again every time you upload it.

Rick commented Mon Jul 16 21:45:46 UTC 2012:

I had problems with the iptables file until I put an extra carriage return at the end of the file. I got this error before I changed that:

/sbin/iptables-restore < /etc/iptables.up.rules

iptables-restore v1.4.12: no command specified Error occurred at line: 42

Want to comment?


(not made public)

(optional)

(use plain text or Markdown syntax)