Ubuntu Hardy setup - page 1

These Ubuntu Hardy Heron articles will take you from a 'barebones' Ubuntu Hardy 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@123.45.67.890

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.

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 they 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' (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@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 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 (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 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.

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.

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 of the Hardy install which includes updating and installing some base programmes.

PickledOnion

Article Comments:

Luke commented Tue Apr 29 10:33:27 UTC 2008:

You guys rock!

Steven K. commented Tue Apr 29 22:51:57 UTC 2008:

Did something change in this version of visudo? I'm having trouble editing. It seems as though the key mappings are all messed up. It was find on Gusty, but hardy is acting up.

Delete and backspace doesn't work right, and my arrow keys have been replaced with uppercase A and B etc.

I've never had this sort of trouble before.

Btw, I'm running leopard and using it's native terminal.

Any ideas?

PickledOnion commented Wed Apr 30 09:33:00 UTC 2008:

Hi Steven,

visudo uses 'vi' as the editor - you will need to google for a quick 'vim cheatsheet'.

I can't remember the keys offhand I'm afraid.

PickledOnion

Scott Miller commented Thu May 01 20:42:38 UTC 2008:

Or use nano /etc/sudoers

Darryl Hamilton commented Thu May 08 20:18:23 UTC 2008:

What you'll want to do is set vi (or in this case, vim) into nocompatible mode. To do this, type ':set nocompatible' (without the quotes) in any vi session.

To make that change permanent, create a file called .vimrc in your home dir, with 'set nocompatible' in it (without the quotes)

Eric commented Sun May 11 16:51:15 UTC 2008:

I had never used visudo before today, and it would have been helpful for me (and probably others that lack visudo or vi experience) to quickly explain that when the file opens they need to hit "j" until they get to the last line, then hit "o" to create a new line below the current line and puts them in insert mode to type the "demo ALL..." and the hit ESC and then type "ZZ" to save and exit.

chris commented Sun May 18 20:19:39 UTC 2008:

It's barfing on me at: iptables-save > /etc/iptables.up.rules if i try it (with sudo) while logged in as my admin user, i get permission denied. when i try it as root, i get: -bash: iptables-save: command not found

no idea

Jon commented Mon May 19 04:58:16 UTC 2008:

Chris, if you're not signed in as root, use:

sudo su -c "iptables-save > /etc/iptables.up.rules"

(include the quotes)

That got me too.

For the iptables -L part the second time, the first line reads:

ACCEPT all -- anywhere anywhere

Is this correct? Shouldn't it reject all from anywhere?

Ken commented Wed May 21 20:40:57 UTC 2008:

I'm curious how I would modify my firewall to allow access for sftp and also to allow access to mysql on port 3306 (or some other port). What entries would I need in the iptables.test.rules file? Also, can I just repeat the steps listed even if I have already followed the instructions above to create a firewall?

steve commented Wed Jun 04 13:16:02 UTC 2008:

On another post for setting up SSH keys on windows with putty

eric commented Thu Jun 05 18:55:30 UTC 2008:

If I remember right, it's generally a bad idea to edit /etc/sudoers except through visudo. It has extra checks to make sure you don't accidentally lock everyone out of sudo access.

Antonio commented Tue Jun 10 21:52:49 UTC 2008:

Thanks for these tutorials. They're amazing. You really narrow it down.

Ben Alman commented Wed Jul 02 11:52:26 UTC 2008:

If you're unfamiliar with vi, before launching visudo, type this into your shell:

export EDITOR=nano

Now, visudo should use nano instead of vi, which will make things a little easier for you.

Kenneth Bengtsson commented Wed Jul 02 16:49:07 UTC 2008:

Excellent article!!

Gavin commented Sat Jul 12 10:54:16 UTC 2008:

Perfect! Thanks!

Toord commented Tue Jul 15 19:01:30 UTC 2008:

Fantastic tutorial! Best I've read in a while. I'm well versed in setting up servers and I'm moving from Gentoo (for convenience reasons) and this article was very helpful.

eman commented Sun Jul 27 14:12:30 UTC 2008:

If you are having problems logging in via ssh with sshvulnkey public key denied. It is because your version of openssh has had a faw for the past 2 years (Debian based distros). You can test your keys on the server - ssh-vulnkey authorized_keys

Simply run apt-get install openssh-server on your local workstation and regenerate the keys and re-send your public key to the remote server. This will solve your problems.

Good luck. Hopefully this comment will be added to the main article.

Jacek commented Thu Jul 31 23:28:08 UTC 2008:

One question: how is sudo + "demo ALL=(ALL) ALL" different than running as root? Doesn't it give all the same privili^H^H^H^H^H^H^Hopportunities to mess up?

Trepex commented Wed Aug 06 13:46:35 UTC 2008:

In general, you just never want to do an interactive root login. Aside from advertising the fact that root logons are enabled, your root credentials could also be intercepted. Once your secure connection is established, everything is encrypted and you can safely su/sudo.

Trepex commented Wed Aug 06 13:48:16 UTC 2008:

... there's also the fact that you're making the attacker break two passwords to gain access, if you've been sly enough to use a different user password than your root password ;)

James commented Thu Aug 07 21:37:30 UTC 2008:

Regarding the iptables, and the suggestion that "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." Actually, we cannot use sudo to redirect output, so you need to do the following (note the quotes around the command): sudo bash -c 'iptables-save > /etc/iptables.up.rules'

Otherwise, these articles are all extremely helpful and set SliceHost apart from more generic hosting systems.

Richard commented Tue Aug 12 09:08:34 UTC 2008:

Ubuntu's Server Guide and Wiki suggest using ufw as the firewall. Ufw looks simpler than iptables.

Sidharth commented Tue Aug 19 15:32:54 UTC 2008:

I change the /etc/ssh/sshd_config file so that Port 30000 instead of Port 22 is used.

After /etc/init.d/ssh reload, I'm getting a connection refused at port 30000. ssh is still available at port 22.

What do you think I may be doing wrong?

Daniel commented Sat Aug 23 05:37:25 UTC 2008:

If you're using OSX, you should probably use vim rather than vi or nano (as the latter two have some kind of weird problem with keys).

PickledOnion commented Sat Aug 23 12:58:16 UTC 2008:

Daniel,

I use OSX all the time and have no issues with nano or vi (I personally prefer nano).

I wonder if you need to set the keyboard in your terminal application. I use iTerm and use the default settings with no issues.

PickledOnion

Dash commented Sun Aug 24 04:14:56 UTC 2008:

Thank you very much for this article - its a snap now to setup my slice!

Paul commented Tue Aug 26 04:57:12 UTC 2008:

in the iptables config, I'm doing as you say for my slice.

But how come replacing one line ..

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

.. with ..

-A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

.. seems to break the loading of the rules?

Yes yes, I'm some lame Java user needing Jetty or Tomcat on port 8080 !

Eric Fields commented Tue Aug 26 15:35:21 UTC 2008:

Perfect article. Up and running just fine. Some weirdness w/ the Macbook keyboard but quickly figured things out (hint: the fn key stands for 'magic')

Bob Sherron commented Tue Aug 26 15:42:44 UTC 2008:

@Darryl Hamilton: Thanks much for the set nocompatible tip. Works like a charm.

Jon commented Thu Aug 28 00:24:58 UTC 2008:

When I try to reload the SSH, I get:

ignoring bad proto spec: '30000'. /etc/ssh/sshd_config line 9: Bad protocal spec '30000'.

I switched the port to 30000 and copied the file exactly as you had it. Any ideas?

Jon commented Thu Aug 28 00:51:49 UTC 2008:

OOPS! Never mind. I got the protocol and port mixed up. I'm not supposed to run with scissors either.

Brent commented Sun Aug 31 03:32:23 UTC 2008:

+1 for Ken's question. How should I tweak these settings to enable MySQL access from another box (for replication).

blake borgeson commented Wed Sep 03 05:02:02 UTC 2008:

excellent guide. thanks.

eduardopa commented Wed Sep 03 20:21:26 UTC 2008:

When I apply th new rules, I get this erro: iptables-restore < /etc/iptables.test.rules
iptables-restore v1.3.8: Can't use -A with -A Any ideas? Thanks

PickledOnion commented Thu Sep 04 09:31:14 UTC 2008:

Eduardopa,

It would seem you have an error or typo in the test.rules file.

The rules work perfectly well (I use them most days with test Slices).

Double check the file for any errors.

PickledOnion

Quang Tran commented Thu Sep 04 15:51:38 UTC 2008:

eman: You rock! It took me over 6 hours to configure ssh working with public/private key in my slice using various methods without success until I tried your suggestion. Thanks a lot!

PickledOninon: can you add eman's suggestion to the article? It would definitely help.

djwonk commented Sun Sep 07 17:01:16 UTC 2008:

I suspect that you have put the pre-up line in the wrong place. I think it belongs with the primary interface, not the loopback one.

To repeat a comment that I put on the Feisty install page:

djwonk commented Fri Oct 12 18:39:59 UTC 2007 ago: In my case, the pre-up line should go after the 'iface eth0' line: auto eth0 iface eth0 inet static pre-up iptables-restore < /etc/iptables.up.rules

Putting it "just after 'iface lo inet loopback'" like you locked me out from external ssh access. I had to use the console to repair things.

James Foster commented Mon Sep 08 03:42:05 UTC 2008:

I have a screencast where I follow these instructions. You can view it at http://programminggems.wordpress.com/2008/09/07/slicehost/

GMAN commented Thu Sep 11 13:03:35 UTC 2008:

Hey this is a great tutorial, but have one minor problem. A geek friend is gonna help me out with developing and I want to give him ssh access. How is he supposed to login? Do I have to scp him a copy of the key? I know you said not to.

PickledOnion commented Thu Sep 11 15:55:40 UTC 2008:

Hi,

In your case gman, you will likely need to enable password authentication.

This does allow for brute force attacks on the SSH port but long, secure passwords will help.

PickledOnion

Spencer Alexander commented Fri Sep 12 20:53:54 UTC 2008:

I'm a bit of a linux noob, and I found this tutorial incredibly easy to follow! Thanks for the help Pickled!

An extra tip that might be helpful to users scanning the comments: add an entry to your local computer's .ssh/config file. The following would be a good option


host slice
 user demo
 hostname demoslice.com
 port 30000

This will not only keep you from having to type in -p 30000 every time you do something ssh related, but it will also allow you to set up other services (ie git repository) with ease!

Thanks again for the help Pickled.

Neil commented Mon Sep 22 00:36:49 UTC 2008:

I've gone through the instructions twice and it keeps coming back with "Operation Timed Out" when I try to SSH in with the user account. Any guesses?

James commented Wed Sep 24 05:54:14 UTC 2008:

Excellent tutorial. Thank you!

Carson commented Fri Oct 03 04:51:43 UTC 2008:

Spot on tutorial. Worked the first time for me. Thanks.

Dan Collis-Puro commented Fri Oct 10 03:53:10 UTC 2008:

@Gman - just have your buddy generate an SSH keypair and put his public key into your /root/.ssh/authorized_keys file. No need to enable password auth, and any SSH client worth using can auth with a public key.

A couple more comments - put a passphrase on your ssh keypair and use "ssh-agent" (via "ssh-add") and you won't need to type your passphrase for every connection (it's cached into ssh-agent). You get two-factor authentication for free.

I personally leave SSH on the default port and firewall it off from everywhere but a few IP addresses, but that's me. Better to lock down the port than move it around.

Juliano commented Mon Oct 20 05:05:44 UTC 2008:

Yes, this tutorial requires careful attention it seems - I chose not to change my sshd port, or anyhow hadn't restarted my ssh session - and then running the iptables config blocked the port I was using (same with a couple folks above, it seems), requiring a reboot of the server.

So, be sure to ensure that the port you are accessing the server through at the time remains open in the iptables config before testing it.

Juliano commented Tue Oct 21 02:15:55 UTC 2008:

Note, I was wrong in the above note - sorry! Established connections are not blocked, as explained later in the tutorial.

What I did, though, was

iptables-restore > etc.iptables.test.rules

note the wrong sign - now, this totally disabled connectivity until a reboot. I know what '<' and '>' mean in bash, too, so I should have known better!

Brenton commented Wed Oct 29 00:36:58 UTC 2008:

Just a note to those having problems with vim in Ubuntu hardy with it inserting wierd cahracters for the arrow keys, I figured out the problem.

Basically, hardy ships with the vim-tiny package instead of the vim package, and there's some difference that makes everything work OK in regular vim but not vim-tiny.

To fix, run sudo apt-get remove vim-tiny vim-runtime vim-common followed by sudo apt-get install vim-runtime vim-common vim

You might actually only have to remove vim-tiny and add vim but I wasn't sure so I did all the vim packages.

Fernando Correia commented Sun Nov 02 23:00:44 UTC 2008:

This command will show more info about the firewall rules:

sudo iptables -L -v

Rob commented Thu Nov 06 04:08:58 UTC 2008:

I can't setup sudo priviliges for one of the accounts I created with adduser. I visudo and added the line demo ALL=(ALL) ALL at the end of /etc/sudoers but I still get and error when I sudo from demo: sudo ls / [sudo] password for pts: Sorry, try again.

Nige commented Thu Nov 06 15:30:49 UTC 2008:

Really good series of articles.

Just some important things to keep in mind for setting up ssh that I found useful:

Changes to /etc/ssh/sshd_config are not noted by the the ssh daemon until you load them with /etc/init.d/ssh reload. You must do this every time you edit the file to change the port, add a user, etc. Then the changes take place. If you don't do this reload then you are only doing password authentication and not key authentication. Worse still - you think you're fully secure because you may not know any better (like me for the last week).
To add another user to ssh you can simply get him to generate the public-private key pair, then get him to email you public key and follow the instructions as above for his new user account.
It's not a good idea to switch off passwords on the private key. You can still log on securely without the private key password with ssh_agent as follows:
Go to /home/<your_acc>/.ssh directory on your local machine (not the slice)
Type ssh-add <private>
Enter private key password
You can now log on more securely without pwd
If you didn't add a pwd on your private key file at the start then you can still do this as follows
Go to /home/<your_acc>/.ssh directory on local machine (not the slice)
Type ssh-keygen -p
You are prompted to enter relevant private key file name and to set new password on it.

angryrabbit commented Tue Nov 11 07:58:27 UTC 2008:

I've completed the tutorial (twice). When I attempt to SSH in, I'm still asked for a password. Given that I have PasswordAuthentication to "no", I cannot log in.

I'm on Leopard.

PickledOnion commented Tue Nov 11 11:14:37 UTC 2008:

Hi,

It is possible that when you setup the ssh keys on your local machine you set a passphrase.

Note that this is not the same as logging in with a password.

A passphrase is an extra security aspect in that you can enter a password for the key itself. It is not a password for the SSH login - hence it is called a passphrase.

If you don't want a passphrase to unlock your ssh key then you may need to create a new one and ensure you don't enter a passphrase when it is created.

If that is not the case, then I don't know what the issue may be as this setup has been used hundreds of times.

PickledOnion

angryrabbit commented Tue Nov 11 18:32:31 UTC 2008:

I ran through the tutorial again, this time forgoing a password for the SSH key, and I can now log in without a password. However, I had to type the following on my local machine (again, running OS X 10.5):

ssh-add nameof_mykey

After that it worked. I'll also add that I named my key something other than the id_rsa. While I can log in okay, I get the following error every time I do:

key_read: uudecode (bunch of characters) failed

Any ideas?

Budo Kam commented Wed Dec 03 09:53:50 UTC 2008:

Thanks for the well written tutorial! I can't wait to get my site up and running on a real host. I think I'm going to burn my copy of windows and learn unix after this...

David Jacobs commented Thu Dec 04 05:27:08 UTC 2008:

No matter what I do I can never save my sshd_config. I always get the following error: [ Error writing /etc/ssh/sshd_config: Permission denied ]

I have followed the article to the letter several time with the same result. If I log out and try again I get a warning about a .tmp file and no matter what I can proceed no further. Please help.

PickledOnion commented Thu Dec 04 10:59:47 UTC 2008:

David,

You are either not using sudo or have not set the user to be a sudo user correctly.

PickledOnion

Yashesh Bhatia commented Tue Dec 16 10:30:44 UTC 2008:

Really good article...

Matt commented Tue Dec 16 11:14:40 UTC 2008:

I need to use password authentication as I need access from several locations.

Are there any other settings in the supplied sshd_config file that need to be changed apart from 'PasswordAuthentication no' to allow me access. PuTTy is connecting but closing as soon as I enter my user password.

Nick W commented Thu Dec 18 01:09:33 UTC 2008:

Worked like a charm. Appreciate the time put into this.

Andy commented Wed Jan 07 07:55:07 UTC 2009:

I was getting crazy behavior when running the vi commands, so I just did a quick: apt-get install vim and everything 300% more sane.

Douglas commented Sun Jan 11 19:50:41 UTC 2009:

I've noticed that the /etc/network/interfaces file gets overwritten each time I get a new IP address assigned to the slice. Might be something worth paying attention to.

Matt commented Thu Jan 15 17:53:27 UTC 2009:

Hi - thanks for a great article. I have one annoying problem though - I have turned off root login, created the new user, allowed access to the user and set 'ALL' privileges. The new user can login just fine from SSH and SFTP - I can do most things I want but when I try to edit files using Coda (my SFTP client), I get a permission denied message. I have re-checked the "[myusernmae] ALL=(ALL) ALL" line and that seems to be intact. Any ideas?

Gurinder commented Fri Jan 16 08:06:18 UTC 2009:

Hi, Thanks for this great service. i just setup my slice and everything went fine. I was just installing proftpd on my slice.

i installed proftpd using "sudo aptitude install proftpd" command. proftpd is running as inetd. not as a standalone server.

But i am not able to connect to server using ftp client. I guess ftp ports 21 and 20 are not allowed in iptables firewall.

can you please help me on how to open ftp ports in iptables.

Thanks

Andy Hume commented Thu Jan 29 15:22:35 UTC 2009:

I've always locked the root account as well with passwd root -l

Is there still any value in that if root ssh has been disabled?

sipskin commented Thu Jan 29 21:31:17 UTC 2009:

How in the world does one get multiple SSH keys to work on a server? I can log in from my mac to my primary server no problem - the generated key works fine. I have then generated a public/private key from my second server and SCP'd the public key across to the primary server, and then edited the authorizedkeys file to add in the pub key, but it still asks me for a password. I have also tried creating a authorizedkey2 file on the primary server for the second pub key, but no luck. Any ideas?

dmsuperman commented Sat Jan 31 22:06:26 UTC 2009:

Just as a quick note, > redirects stdout into a file. If you don't have permission to edit that file, however, it'll fail. If you want to replicate this, pipe to sudo tee to write stdout to a file.

For example:

sudo iptables-save | sudo tee /etc/iptables.up.rules

JD Justice commented Thu Feb 05 02:44:48 UTC 2009:

@sipskin re: multiple SSH keys on a server... see here

hope that helps!

Ashutosh commented Sat Feb 07 02:00:55 UTC 2009:

What settings should I use in the IPtables to allow remote connections to MySql? Thanks!

ballona commented Mon Mar 09 11:30:18 UTC 2009:

I've made it wrong the first time, so I'd like to suggest a change:

Where you read: 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.

I think you'd better add something like: Don't forget to change 3000 port in the rule bellow: -A INPUT -p tcp -m state --state NEW --dport 30000 -j ACCEPT

It's silly but I've made it wrong and could't log in again after restarting ssh until I fixed it.

Sorry for the english.

conficker commented Mon Mar 16 01:22:58 UTC 2009:

Thanks for this tutorial. I hate doing Linux stuff on my own, and I especially hate trying to figure out what things to do.

ahabman commented Mon Mar 16 17:39:52 UTC 2009:

Running the 'ssh-copy-id' command locally was a lot easier for me than the 6 manual commands shown here.

Kill Conficker commented Wed Apr 01 02:16:23 UTC 2009:

I didn't have any problems using nano with OSX

remove conficker commented Wed Apr 01 04:18:07 UTC 2009:

Wow! Thanks for this tutorial. I hate doing Linux stuff on my own, and I especially hate trying to figure out what things to do.

Fiona commented Tue Apr 14 16:01:03 UTC 2009:

Thanks a million for the above article. I am having one issue though...

I'm using Putty to ssh to my slice as my machine runs on windows. I followed the article except for

the generation of the private public keys.. (I used this article for that bit... http://articles.slicehost.com/2009/2/4/ssh-puttygen) - as a result I left out SSH KeyGen
I also left out the SSH Copy sections

I continued to follow this articles instructions from SSH Permissions where permissions get set.

Anyhow my issue is that logging on as Root works perfectly... however I get the 'Server refused our key' when attempting to logon as the new admin user set up at the very start. Anyone any ideas where i might be going wrong please?

Thanks

pbass98 commented Sat Apr 18 05:43:50 UTC 2009:

For those asking for how to allow mysql connection from another slice-- add a rule like this after the HTTP/HTTPS rules:

-A INPUT -p tcp --dport 3306 -j ACCEPT -i eth1

You can restrict further using the source's IP with the -s flag I think.

Jordan Lev commented Fri May 01 23:37:58 UTC 2009:

Note that you should set the ssh port number to something between 49152 and 65535. (see http://www.iana.org/assignments/port-numbers for details). I was having problems with the "iptables-restore" command, getting an "invalid port/service specified" error, because I inadvertently used a number higher than 65535.

Morten Blaabjerg commented Mon May 04 11:26:17 UTC 2009:

Remember to restart the SSH daemon :

sudo /etc/init.d/ssh restart

after you’ve finished changing your SSH settings and have save your changes to the sshd_config file.

Failing to do so got me locked out in my first attempt and I had to rebuild my slice.

aslan commented Thu May 07 19:16:49 UTC 2009:

thanks for the effort worked first time. thumbs up to slicehost so far :)