Debian Etch setup - page 1

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

Not only that, you will have a better understanding of what is going on and, more importantly, why it's going on.


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

Give the 'visudo' command:

visudo

At the end of the file add:

demo   ALL=(ALL) ALL

SSH preparation

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

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

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

testing

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

Lee Joramo commented Sat Nov 17 17:13:12 UTC 2007:

Mac OS X does not include the ssh-copy-id

I found the solution in the slicehost forums

Lee Joramo commented Thu Nov 22 14:13:42 UTC 2007:

If sftp doesn't work for you after these instructions. You probably manually edited your sshd_config, and did not use the example file that was linked to above. The fix is to uncomment the line:

Subsystem sftp /usr/lib/openssh/sftp-server

.

Sam commented Wed Nov 28 00:37:47 UTC 2007:

Brilliant. 1 spelling mistake SSH preperation should be SSH preparation

PickledOnion commented Wed Nov 28 11:02:47 UTC 2007:

Sam,

Thanks - changed it :)

PickledOnion

comb commented Sun Jan 13 23:25:53 UTC 2008:

Can you point to help on opening up ports for specific services as you add them? For example, I added memcache and need to open up the specified port to retrieve data. Thanks

PickledOnion commented Mon Jan 14 12:38:12 UTC 2008:

comb,

Have a look at the iptables example file I show.

Look at where port 80 and 443 are shown - you can use these as an example of opening a specified port.

PickledOnion

comb commented Tue Jan 22 20:56:09 UTC 2008:

I am specifically having trouble with it connecting to its own memcached server using the example config you presented.

I was able to add a line using the examples to open up the default memcached port (11211). I know it worked because I could connect to it and retrieve data from other hosts. However, when I try to either telnet into it from my slice or have the same web page running on the slice, it breaks.

For example, telnet localhost 11211 just sits there. telnet <hostname> 11211 does the same thing.

Thanks for your help (and helpful articles!)

comb commented Tue Jan 22 20:59:31 UTC 2008:

Additionally, I attempted to 'reset' the iptables to default by removing the line which loads the iptable rules created above and rebooted the server. I then saved out those rules to a separate file. Same symptoms as I described in the previous post.

Either I incorrectly 'reset' the iptables to default (open to everything), or something else is inherently preventing that loopback connection.

castral commented Sun Jan 27 14:34:03 UTC 2008:

Just a quick note, some users may find an odd error when they try to load their newly written iptables rules because they didn't add a new line at the end of the file after the COMMIT statement.

Adam commented Mon Apr 28 15:53:33 UTC 2008:

If you're a Windows user, and you don't want to mess with Cygwin, you can download (for free, no hassle, and all that) WinSCP, which will allow you to SFTP/SSH into your setup to transfer the public key. I used PuttyGen to generate the keys, Pageant to maintain the keys, and WinSCP to transfer the public one to my slice. :)

Jon commented Wed Jul 16 03:01:20 UTC 2008:

As a cygwin user, I had a very difficult time getting ssh keys to work. However, this tutorial http://pkeck.myweb.uga.edu/ssh/ helped me immensely.

womanseevaca commented Fri Sep 05 12:13:24 UTC 2008:

student site kitchen pets this

Fauzan commented Sun Sep 21 09:46:05 UTC 2008:

Hello!

Great article! Well done! :)

Small question, I can't run visudo!

Maybe you could also remind readers to change the port in the iptables configuration file in accordance with the port that the reader used in the ssh configuration file!

Many thanks!

Drew commented Fri Oct 24 20:25:37 UTC 2008:

@Fauzan

I had the same issue with visudo. You will have to apt-get sudo because it is not installed by default.

Martin Cleaver commented Sat Nov 08 03:45:10 UTC 2008:

Might be better to give people a wizard that generates the correct instructions for: 1) user name 2) ssh port number

You could even do: 3) distro

davide commented Sat Dec 06 14:00:04 UTC 2008:

Just a short suggestion for the iptables stuff.

Instead changing the /etc/network/interfaces use the debian builtin iptables stuff.

when the correct iptables settings are imported (check via iptables -L) just do the following:

/etc/init.d/iptables save active

this way you'll save the current iptables firewall setting as the "active" rule set.

(the rulesets are stored in /var/lib/iptables/*)

if you type: /etc/init.d/iptables stop the inactive ruleset is loaded (=firewall off)

if you type: /etc/init.d/iptables start the active ruleset is loaded (=the one we configured before via "save active")

debian automatically loads the active ruleset on boot.

i guess this is much nicer instead of "manually messing around with the /etc/network/interfaces

cheers,

davide

Ryan commented Tue Jan 13 16:00:37 UTC 2009:

Quick question about the iptables example (http://articles.slicehost.com/assets/2007/9/4/iptables.txt): why do the HTTP/S lines omit the "state" argument, or, if it makes more sense, why does the SSH line include the "state" argument? Is it intentional because of differences in the protocol (HTTP/S has some use for state==INVALID packets)?

Dave Taylor commented Tue Mar 17 02:54:04 UTC 2009:

davide, that doesn't seem to be available in the default lenny, but i found a good script that suggests to be the clean soln:

http://www.debian-administration.org/articles/615

Daniel commented Wed May 27 21:31:33 UTC 2009:

I can't call visudo, which package should I install?

thx.

beefsalad commented Thu Oct 29 01:20:41 UTC 2009:

beefsalad@ubuntu:~$ apt-file search visudo manpages-ja: /usr/share/man/ja/man8/visudo.8.gz sudo: /usr/sbin/visudo sudo: /usr/share/man/man8/visudo.8.gz sudo-ldap: /usr/sbin/visudo sudo-ldap: /usr/share/man/man8/visudo.8.gz so unless you are using ldap, I'd say the sudo package... which you should already have. are you sure you are logged in as root? "

Want to comment?


(not made public)

(optional)

(use plain text or Markdown syntax)