Ubuntu Lucid Setup - Part 1

Your Ubuntu Lucid Slice will be a bare-bones install when it's created. We need to connect via SSH and secure it as soon as possible.

Your new slice

These two articles will take you from a 'barebones' Ubuntu 10.04 (Lucid Lynx) 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.

This first part will walk you through setting up a new user and securing login access to your slice.

For convenience when we refer to running a command on your local workstation we will give the command as it would be entered into a Mac or Linux terminal window. For Windows you should be able to adapt the command based on the context. For instance, if you're told to edit a file as part of a step, you would use a text editor like NotePad instead of running the "nano" command.

Intro to SSH

SSH stands for "secure shell". It's a protocol that encrypts data that gets sent back and forth through its connection, making it much harder for someone to intercept that traffic and scan it for passwords or sensitive information. In these articles we'll have you using SSH to connect to your slice to run most administrative commands.

If you're running a Linux desktop, you'll be able to run the ssh commands we list here by using them in a terminal window.

If you're running Mac OS X you'll also be able to run the ssh commands in a terminal window. You can open a terminal by running the 'Terminal' application that was installed with your system.

On Windows you won't have command-line access to SSH by default, so you'll need to download a client. We recommend a program named PuTTY, both because it works well and because it's free. You might also want a nice interface for running scp (which uses the SSH protocol to transmit files over an encrypted connection). We recommend another free program, WinSCP, though there are other options like FileZilla that also work well.

First login

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

ssh root@

As mentioned earlier, on a Windows machine you'll need to run an SSH client like PuTTY in order to make the connection.

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 depending on the program you are using. You'll need to refer to the documentation for that program for details. For example, PuTTY stores its known hosts in the following registry entry:


User administration

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


Apart from this initial setup, you should never log in as the root user. It's safer and more secure to create a new administrative user and use the 'sudo' command from that user. Having to use sudo to run superuser commands can help prevent some potentially system-breaking accidents, and it also means that any root-level commands run through sudo will be logged to '/var/log/secure' if later review is needed.

To make managing administrative access to your slice easier let's create a group, 'wheel', that will contain users with sudo privileges. To make the group, run:

/usr/sbin/groupadd wheel

With the group ready, let's issue the 'visudo' command to edit the sudo configuration:


The visudo command runs a default editor, and will check the configuration for any syntax errors before saving it. The default editor for Ubuntu is 'nano'.

Scroll down to the bottom of the file. Add the following two lines to the end of the file:

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

Save and exit the file, and sudo is all set. Members of the 'wheel' group will now have full sudo privileges.

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.

Add a new user

Time to create a new administrative user (I've used the name demo here but any name will do).

/usr/sbin/adduser demo

You will be asked to set a password for the new user. The values for Full Name and the rest can be left blank.

Since you'll want to use this user instead of 'root' to manage your system, it will need to be able to use the sudo command. We've already granted that permission to the 'wheel' group, so we just need to add the new user to 'wheel':

/usr/sbin/usermod -a -G wheel demo

SSH keygen

One feature of SSH is the ability to require users to use, instead of a password, a "key pair" for authentication. Under this approach a user generates a public and private key pair on their workstation and then uploads the public half of the key pair to the server. When they go to connect later the server tries to match up its public key with the user's private key in order to authenticate the connection.

Using a key pair with SSH is good security policy, which is why we'll walk you through the process here. A password can be guessed through sheer brute force (running a program to try different character combinations until it gets a match), but a key pair is vastly more complex. It is almost impossible to crack a key pair with a brute force approach.

Note that using a public/private key pair is impractical if you need to log in to your slice from a workstation that is shared with other users. While you can copy the private key to another workstation, putting that key on a shared workstation would defeat the purpose of the key pair's security. In that environment continuing to use a password for SSH access would make sense.

The first step to using key pair authentication 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. For Windows users we have a separate article on key generation using Puttygen.

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

ssh-keygen -t rsa

If you do not want your key to require a passphrase when used 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 share this file with someone else or store it 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, substituting your new username and the IP address of your slice:

scp ~/.ssh/id_rsa.pub demo@

When prompted, enter the your user password. When that's done you should see scp copy the file to your user's home directory.

On a Windows machine you'll want to use a third-party client like WinSCP, using the information above to make the connection.

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 directory and move the pub key into it:

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

If you haven't run into it before, that squiggly character is the 'tilde', and it's usually in the upper-left of your keyboard. In the Linux shell it can be used as a reference to a user's home directory. Using '~' by itself refers to the current user's home directory, while using it like we did above, '~demo', refers to the home directory of user 'demo'. It's a handy shortcut to know.

Now we can set the correct permissions on the key:

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

Again, replace the 'demo' user and group above with the name of the user you created.

Additional users

If you need to add more users to your system, now or after you finish this initial setup, you can just run through the steps above again for each user.

If the user doesn't need to have administrative privileges, skip the part where you add the user to the 'wheel' group.

If the user will be accessed from the same workstation as your administrative user, you can re-use the same public SSH key for the new user.

SSH config

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

nano /etc/ssh/sshd_config

You 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
UseDNS no
AllowUsers demo

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.

If you need to allow remote logins for more than one user, add the additional users to the 'AllowUsers' setting separated by spaces.

The labels are fairly self explanatory, but the main security changes to make are to move ssh from the default port of 22 to one of your choosing (we use 30000 in the example), turn off remote root logins, and define which users can log in remotely.

PasswordAuthentication has been turned off because 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 on a secure workstation.

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.


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

Next thing is to set up our iptables (firewall) so we have a more secure installation. It's possible to skip this step, or to disable iptables entirely, but we recommend that if you follow the Slicehost tutorials, you set up iptables with our default rules. It's a good hindrance to would-be intruders. Furthermore, the comments in the file you'll create can help you remember why you made a particular change later, and you can use the examples there to take some of the headache out of figuring out what new rule to add and where.

The default rules

Let's have a look at the default iptables rules:

/sbin/iptables -L

Remember that if you come back to this part of the tutorial as a non-root user later, you'll need to put a 'sudo' in front of the iptables command to make it work.

The default setup will output 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.

When we're done, the output of that command should look something like this:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere            reject-with icmp-port-unreachable 
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:30000 
ACCEPT     icmp --  anywhere             anywhere            icmp echo-request 
LOG        all  --  anywhere             anywhere            limit: avg 5/min burst 5 LOG level debug prefix `iptables denied: ' 
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere

There's too much there to go into much detail in this article, but the basics to pay attention to when you skim those firewall rules are 'ACCEPT', 'REJECT', 'INPUT', and 'OUTPUT'. Fortunately those are reasonably understandable in context. Rules can refer to incoming traffic ('INPUT') or outgoing traffic ('OUTPUT'), and they can describe whether to 'ACCEPT' or 'REJECT' the described connections. The rest of it determines the sort of traffic being controlled, like what port or packet type it's looking for.

Roll your own

Now to set up those iptables rules we want. If the output of 'iptables -L' wasn't an empty ruleset, or if you just want to be thorough, you'll want to flush the current rules from memory:

/sbin/iptables -F

We can now set up our own rules that allow local connections and keep established connections (which is how the root SSH connection on port 22 will still work when we apply the SSH port changes and apply the new iptables rules).

We'll also open port 80 and port 443 (the normal HTTP and HTTPS ports) and, of course, allow connections to our custom SSH port. Then we'll allow pings to the Slice and, effectively, reject all other attempts to connect to a port.

To make it easier to keep track of the rules you want iptables to use and to change them later, let's create a file to store them:

nano /etc/iptables.up.rules

Now check out our example iptables rules file. Copy and paste those rules into your new file, and edit the rules however you see fit. The comments should help you decide what to change. In particular, make sure you change the line opening port 30000 to whatever you chose as your custom ssh port.

The lines opening ports for a web server should provide a good template for opening ports for other services you may add to your slice later.

If you want more complex firewall rules (restricting outbound traffic as well as inbound, for example), you might do well to research iptables more after you're done with this basic setup.

Once you're happy with your iptables rules, save the file.

Implement your rules

To tell iptables to use your new rules, run the command:

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

That will read in the custom rules from the file you just created. You can confirm that it worked by checking the rules again:

/sbin/iptables -L

See the difference between the first time we entered that command and now? Again, have a look at each line of the output and see where it marries up with the rules we entered earlier.

Although the rules are up and running, they are only active for the current session. If the Slice were to be rebooted they would be lost.

As such, let's ensure they are restored on a Slice reboot. We'll add a small script that the system will run when your network interfaces are started. Create the file by running:

nano /etc/network/if-pre-up.d/iptables

Add the following lines to the new file:

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

Save your changes, and then make the new script executable:

chmod +x /etc/network/if-pre-up.d/iptables

That should ensure that whenever your network interfaces are brought up (usually just at boot time), the firewall will be too.

Editing iptables later

You can repeat these steps if you decide you've made a mistake, or if you want to change any rules later. Just edit the rules file you created, flush the current rules from memory, then restore the edited rules.

The commands you'd use (without all the commentary) are:

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

Good work surviving the iptables setup.

Note that if you decide to use a control panel type of program like virtualmin that can manage your firewall rules you'll want to either not use that part of the control panel, or remove what we've been using to manipulate iptables. A similar choice would have to be made if you look into using another method of managing firewall rules, like UFW or Shorewall. Having two processes controlling iptables rules can lead to some real conflict. If you find an alternative, just be sure that you choose it alone or that you go back to using /etc/iptables.up.rules exclusively.


Reload sshd

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

/etc/init.d/ssh reload

Don't logout as root yet...

Logging in with the new user

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

ssh -p 30000 demo@

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

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

You should be greeted with a plain terminal prompt like this:

[demo@yourvpsname ~]$


We now know that the firewall and sshd_config work and we can log in.

Let's move on to part 2 which includes updating the install and installing some base programs.

  • -- Jered

Article Comments:

Mikkel Christiansen commented Sun May 02 20:14:53 UTC 2010:

Instead of struggling with iptables consider using 'Uncomplicated Firewall' (ufw). Now the default firewall in Ubuntu.

The following commands will create a firewall that rejects anything but ssh and Apache (http, https). Apt-get install ufw sudo ufw allow ssh sudo ufw allow "Apache Full" sudo ufw default deny sudo ufw logging on sudo ufw enable

Rob commented Sun May 02 21:56:28 UTC 2010:

Hmmm...my mac is saving its pub/private keys in /var/root/.ssh/ instead of ~/.ssh when I generate them. Any guesses as to why it's doing this now? Thanks.

Jered commented Tue May 04 15:45:51 UTC 2010:

UFW definitely works. There are a few reasons we still use iptables as the default in our articles, but the main one is that the approach we describe lets you maintain a text file with not only your rules, but also comments to go with them. Commenting can be really nice to have if you go back to something later and need to remember why you set things up the way you did.

As to the matter of ssh key locations, Rob, that sounds like you're creating the SSH keys either logged in as the root user, or using sudo to run the key generation commands (/var/root is ~root, basically). If you make sure you're running as your "regular" user in the terminal, that should get the key creation back where you want it.

Andrew Bessa commented Wed May 19 14:48:21 UTC 2010:

I had problems using Dreamweaver's SFTP after changing the IP tables...

Open up port 22 for SFTP

Change settings to:

Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)

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

(Notice the line added at the end for port 22)

It works, but I'm not sure if its 100% secure... if someone wants to confirm, let me know.

Matthew commented Tue May 25 22:32:22 UTC 2010:

The part about the SSH keys are a bit confusing and I hope more elaboration on that section is made.

So are generating SSH keys required? What happens if I login to the server with a difference Mac, will that mean I can't login anymore? What if I have to reformat? I don't get the private/public key think.


Jered commented Wed May 26 02:26:12 UTC 2010:

I'll look into making that section a bit clearer. To answer you for now, though: The SSH key generation and restriction of the ssh server to only allow connections authenticated with a key is a security measure. It prevents people from being able to "brute force" their way onto your server by trying a bunch of username and password combinations until they find one that works. So it's not required, just a good idea.

It is true, however, that if you log on from more than one computer you'll either need to have your private key on each computer, or just leave password authentication on. Though if you do that, definitely make sure that "PermitRootLogin" is set to "no".

Basically, the way the private/public key thing works is: You make a key pair on your computer, and upload the public part to the server. Then when you try to ssh in, your computer talks to the server and they compare keys. If the two keys mesh right (private on your machine, public on the server), it lets you in. If they don't have anything to do with each other, then you can't use those keys to log in.

The generated keypair is much, much more secure than a password. If someone wanted to guess your password, they could have a program run through a dictionary, or try random character combinations up to about 12 characters and have a reasonable expectation that they could, eventually, get a hit. SSH keypairs are massively more complex and will (for all practical purposes) prevent someone from ever being able to get in by guessing their way through the key authentication.

Jamie commented Thu May 27 18:37:41 UTC 2010:

Your link to part 2 is bad--you have "29" instead of "30" for the day.

Jered commented Thu May 27 19:27:57 UTC 2010:

Gah! Thanks for catching that, I messed it up when updating a section. The link should work now.

Kyle commented Tue Jun 08 06:06:41 UTC 2010:

When I run the /usr/sbin/usermod -a -G wheel demo (using my username of course) I get the error usermod: group 'wheel' does not exist

Do we need to manually create that group first?

Jered commented Tue Jun 08 11:46:05 UTC 2010:

Yes, on Ubuntu you'll need to create the "wheel" group. The command is in the "User administration" section, just before running visudo:

/usr/sbin/groupadd wheel

Dave Christiansen commented Wed Jun 09 05:15:13 UTC 2010:

About this step:

nano /etc/ssh/sshd_config

The ssh directory doesn't exist, and sshd_config is in /etc. I think this must be an error in the tutorial?

Jered commented Fri Jun 11 00:57:47 UTC 2010:

Actually, Dave, that doesn't sound right at all, if you're using one of our images (or the default Lucid installation, really). The Debian and Lucid packages for openssh both put their config files in /etc/ssh. Might you have installed a different SSH package, or are you using an older version of Ubuntu than Lucid?

George commented Wed Jun 16 01:48:07 UTC 2010:

Hey Jered I am following along your tut and everything seems to be going great except near the end. this is what I get

<--I enter this-->/etc/init.d/ssh reload

<--I get this-->Could not load host key: /etc/ssh/sshhostrsa_key Could not load host key: /etc/ssh/sshhostdsa_key

  • Reloading OpenBSD Secure Shell server's configuration sshd ...done.

then when I log in... luckily I left password logins set to yes... it forces me to enter a password. any thoughts?

oh also, when i tried "ssh-keygen -t rsa -f /etc/ssh/sshhostrsa_key" it says the file already exists

Thanks in advance

Jered commented Wed Jun 16 05:08:03 UTC 2010:

Hm, instead of reloading sshd, you might restart it: "/etc/init.d/ssh restart". Also make sure you are running this as root, or through sudo from your created user. Restarting ssh should make it regenerate any of the keys it needs.

KP commented Thu Jun 24 20:03:37 UTC 2010:

Hi, I PermitRootLogin to no in /etc/ssh/sshd_config file.. Now I want to set allow remote root login but after changing this value to yes and restarting ssh, ssh doesn't allow me to login using root.

I have set RSA for other user, Do I need to change in some other file to allow remote root login through ssh?

Jered commented Mon Jun 28 22:05:27 UTC 2010:

KP, you'll need to go through the steps to add that same RSA public key to the .ssh/authorized_keys file in root's home directory (which you can find most easily by typing "cd ~root").

nige commented Wed Jun 30 17:39:58 UTC 2010:

I had a problem with this tutorial. Everything went ok until the very end when id_rsa.pub was not found. The tutorial says you need to mv this file into authorized keys. I see there is a flag in ssh config file for authorized keys which is commented by default. So maybe if you uncomment it you won't get the problem I got.

My solutiion was run in verbose mode as follows: ssh -v -p 30000 demo@123.45.678.90

You get lots of good feedback.

From this I saw that the ssh handshake expected to see idrsa.pub on the target in /home/demo/.ssh/idrsa.pub (not as /home/demo/.ssh/authorized_keys).

Daniel commented Tue Jul 13 19:45:17 UTC 2010:

I tried running SSH through port 1987, edited IP-tables according to your example,

debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 1987. debug1: Connection established. debug1: identity file /Users/daniel/.ssh/identity type -1 debug1: identity file /Users/daniel/.ssh/id_rsa type 1 debug1: identity file /Users/daniel/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu3 debug1: match: OpenSSH_5.3p1 Debian-3ubuntu3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.2 debug1: SSH2MSGKEXINIT sent Connection closed by xxx.xxx.xxx.xxx

Note that it works when port is default (22)

Anyways thanks for a great tutorial.


Jered commented Tue Jul 13 20:17:12 UTC 2010:

Huh, that's an odd one, Daniel. It looks like it does make an initial connection when not on port 22, but the connection dies quickly. It does talk to the SSH server, so it's not outright blocked, but I would guess something is preventing the connection from being sustained on the non-standard port. Maybe your router's firewall is doing something to the non-standard port that it wouldn't do to the standard port 22? It shouldn't be iptables if you followed our example, otherwise I'd wonder if iptables was allowing a "connect", but was blocking an "established" connection on that port.

Kris commented Tue Jul 20 22:37:17 UTC 2010:

It looks like, at least with Ubuntu Lucid, there is already a group called sudo which already configured in the sudoers file to have full sudo rights.

So just: usermod -a -G sudo demo

Jered commented Wed Jul 21 16:26:24 UTC 2010:

True, but that's a fairly recent development for Ubuntu, and not all distributions have a "sudo" group. Of course, since Ubuntu doesn't have a "wheel" group I suppose that isn't much of an argument in its favor either. But we use "wheel" because it's been traditionally used as the privileged group on Unix systems, so it makes for a better standard across setup articles for the different distributions we offer. It also means that if you're used to it, you won't be surprised when you run into that use for the wheel group on other Unixes like BSD (wheel is also the group used in a default sudoers file when compiling sudo from source, or it was the last time I compiled it).

Either way, so long as you're controlling sudo access in some way (using a group, or specifically listing users in sudoers), you're good.

Gene Campbell commented Tue Aug 10 22:42:37 UTC 2010:

100% perfect documentation. Not too much, not too little. Just enough to jog the memory. Well done. Thanks!!

Phil Jones commented Thu Aug 12 21:10:36 UTC 2010:

Hey, Great article.

Im setup great just having a small issue i could do with some feedback on.

When logging in with my newly created user my session does not load bash instantly. If i run a "w" command its clear that im logged in without bash.

Running the command "bash" solves the issue but i would like out of convenience for bash to load by default. I have tried soft linking .bash_login to .bashrc but had not luck

Thanks in advance!

Oscar commented Thu Aug 12 23:52:21 UTC 2010:

Really good article. What rules can I use in the iptable to allow remote connections to MySQl?

Jered commented Fri Aug 13 17:38:42 UTC 2010:

Phil, it sounds like your user account's shell may not be set to bash. Try running the "chsh" command to see what your login shell is set to, and if it isn't "/bin/bash" set it to that value. If that's not it, then you might try hitting chat.slicehost.com and have a tech walk you through trying to find the source of the problem.

Oscar, MySQL's default port is 3306. At its simplest, you can use the rule "-A INPUT -p tcp --dport 3306 -j ACCEPT" to open that port in iptables.

Phil Jones commented Fri Aug 13 20:21:12 UTC 2010:

Jered - thanks a bunch that did the trick! It was set to /bin/sh . I didnt know about that command so thanks again!

Eric commented Fri Sep 10 19:57:14 UTC 2010:

I recommend in the sshd_config file that you use "AllowGroups wheel" instead of "AllowUsers demo". I think that is more consistant with the intention of wheel and the idea of using group management like for the sudoers file as opposed to individual users.

Jered commented Fri Sep 10 23:25:05 UTC 2010:

Tough call. Using the wheel group does make it consistent with sudo, true. But I worry that encouraging the use of the wheel group in the sshd config could lead to newer admins just adding users to wheel to grant ssh access, whether or not that user actually needs sudo privileges.

A separate group for ssh would be the best choice, I think. I'll mull that over. Ubuntu creates an "ssh" group by default, but CentOS creates an "sshd" group instead, so no help there. I prefer something that can be consistent across distributions. Maybe "humans". That appeals to my sense of whimsy.

Ronen Botzer commented Mon Oct 18 18:15:17 UTC 2010:

One of the things I do initially is change the default editor to vim. update-alternatives --config editor I recommend that you add mention of how that is done in the User Administration section.

Jim Prouty commented Mon Feb 14 18:29:17 UTC 2011:

If you set up an FTP server, don't use these iptables settings, use ufw instead. Ufw implements the PASV port tracking needed to make anonymous FTP reliable. For example, it is needed to make anonymous FTP access from web browsers work. You'll need to set the PASV port range. Using pure-ftpd:

$ sudo echo "30000 50000" > /etc/pure-ftpd/conf/PassivePortRange

$ sudo /etc/init.d/pure-ftpd restart

$sudo /sbin/iptables -F # undo the iptables stuff above

$sudo aptitude install ufw

$sudo ufw allow ssh

$sudo ufw allow "Apache Full"

$sudo ufw allow ftp

$sudo ufw allow proto tcp from any to any port 30000:50000

$sudo ufw default deny

$sudo ufw logging on

$sudo ufw enable

$sudo ufw status

Artemis Mendrinos commented Mon Mar 28 09:06:58 UTC 2011:

In case someone would like to hide "Ubuntu" from the OpenSSH headers, this is now possible under Ubuntu 10.4 with the following configuration inside sshd_config file:

DebianBanner no

Super helpful commented Sun Apr 10 13:28:40 UTC 2011:

Thanks...I've never set up this kind of thing myself before but this tutorial made it a 10-min early morning breeze

Mike Norman commented Mon May 23 06:00:16 UTC 2011:

I had to use "ssh-add" on my local machine to add the identity before it would succeed. Is this a version thing?


Ray James commented Tue Jul 05 19:57:43 UTC 2011:

Just a quick fyi: I had to run sudo /etc/init.d/ssh reload and sudo /etc/init.d/ssh restart for the changes to properly take place due to the ssh port change. Thanks.

vskarich commented Sun Aug 07 21:32:56 UTC 2011:

I've been trying to add additional new users after my first non-root user, but unfortunately I continue to get the "Permission denied, please try again." error whenever I try to ssh from my local box. I add the additional users to the ssh config file AllowUsers line, and I am sure the passwords, etc are correct. I know this error message is fairly generic, but any gotchas or clues would be much appreciated. --thanks!

Jered commented Mon Aug 08 20:25:10 UTC 2011:

If you followed the article you may have password access disabled. Check your sshd config file for the following line:

PasswordAuthentication no

If that's in there, change "no" to "yes" and that might fix the issue keeping new user accounts from connecting. Either that, or create ssh keypairs for the new accounts as well.

Matthew H. Wagner commented Wed Aug 29 19:02:30 UTC 2012:

As of right now, iptables is not in the /usr/sbin rather than /sbin as described.

Want to comment?

(not made public)


(use plain text or Markdown syntax)