This post is obsolete and screenshots have been removed.
This is the third installment in my Ubuntu Server Project series which documents my efforts to get a working copy of WordPress running on Ubuntu Server 7.10. It’s summarized, with links to past articles, on my Linux page.
Ok, technically security should have been set up immediately after installation so this should have been the second installment and not the third. But Ubuntu was a VM on my own desktop and wasn’t on the Internet so I wanted everything nice and up to date before proceeding.
Setting Up Networking
I could keep working with the Ubuntu 7.10 Server locally on my desktop and get right to the installation, but I want to start dealing with it as if it’s a remote server. So the first thing I’m going to do is get the IP Address and Mac Address for my Ubuntu server so I can connect remotely. I log onto the console and issue the command ifconfig to get the ip address along with the mac address. The screenshot below shows the results on my Ubuntu Server (click to enlarge) with the ip and mac addresses indicated.
It’s worth mentioning that I set up the Parallels vm to connect via a bridged network so it gets it’s own unique ip address rather than sharing (via NAT) with the host OS. While the IP address will probably stay the same, it’s assigned by DHCP and could change. It’s my internal DHCP server (actually my Airport Extreme) so I’m going to reserve the DHCP address for this Ubuntu Server instance. To do that I need both the IP and Mac addresses.
I’m concerned with the adapter labeled eth0. The ip address is on the second line and is labeled inet addr. The mac address is on the first line and is indicated by HWaddr. Most home routers can do DHCP reservations although the methods vary. Look for the tern DHCP reservation. All you should need is the ip and mac addresses. A note for Airport Extreme users like me – even though there’s no good reason for it, adding a DHCP reservation forces a router restart.
If you don’t want to set up a reservation you can just lookup the ip address when it changes and you can’t connect.
Installing SSH Server
I want to install an SSH server so I can securely connect to the server remotely. (Remember, I’m treating this like a remote server.) I log on to the Ubuntu console and run the following commands:
I want to make sure my package list is up to date:
sudo aptitude update
Then to install the SSH server:
sudo aptitude install ssh
Aptitude tells me (click for full size):
and I approve the installation which finishes without error. SSH server is installed am I’m done with the SSH server install. For information about aptitude see my previous article.
The whole point of SSH is security. In the next step we’ll see that our first SSH connection from a workstation says the host is unknown and provides a fingerprint. Now, this is a internal private network and the host is really a VM running on the same machine and we’ll be connecting via IP address. But for security purposes we’ll get the “RSA key fingerprint” while we’re here. I execute the command (on Ubuntu server):
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
Note that I don’t need to use sudo. As the extension .pub implies, this information is public for all to see. The response I get is:
2048 64:93:11:41:b7:31:cf:66:41:cb:7c:4f:37:3b:89:e8 /etc/ssh/ssh_host_rsa_key.pub
That long colon delimited number is the servers RSA Key Fingerprint. Whenever I attempt a SSH connection from a new machine I will be presented with that number. If it doesn’t match then I’m connecting to another machine, either by error or by mischief.
There’s also another type of key generated during the install called a dsa signature key which is another form of key signature. To get this fingerprint execute:
ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub
From this point on I will do everything on my Mac and treat the Ubuntu Server as if it’s a remote server. Although for simplicity doing the server stuff from the console running the Ubuntu server and doing the local computer stuff from terminal would be much simpler.
Setting Up SSH Public/Private Key
SSH provides secure, encrypted access to the server’s console. I’ll set up a public/private key for my iMac and the server, this way when I want to connect I don’t need to enter a password. Public/private keys should only be used when the local workstation is secure since anyone who has access to the workstation can access the server.
I’m going to test the SSH connection before proceeding. I open terminal on my Mac and execute:
I’m told the authenticity of the host can’t be established and I’m presented that 16 digit(hex) number. It matches what I know to be the server so I type yes to continue connecting. The I’m told
Warning: Permanently added '10.0.1.200' (RSA) to the list of known hosts. This means future SSH logons from this machine will not generate the authenticity error. The SSH connection is working.
I logout of the connection but stay in terminal. (I could just open another terminal window, but I’m easily confused.)
First, I’ll create a folder on my local Mac to hold the keys. I execute:
This folder may already exist, and should have been created when the server was added to the known hosts list. If it does exist you’ll get an error that it can’t be created and you can move on. The ~ indicates your user home directory. The folder will be created in your home directory and the “.” means it will be hidden (at least in Finder).
Now I create a public/private key combination for my Mac by executing:
ssh-keygen -t rsa
This will generate a public/private key using rsa encryption. Two files will be created in ~/.ssh called id_rsa and id_rsa.pub. The private key is id_rsa and should never be put in any public place. The public key is id_rsa.pub. During the key creation I was asked to confirm where I wanted to put the files and if I wanted a passphrase. I accepted the default for location and hit enter for an empty passphrase.
Now I copy this to the server using the secure copy command.
scp ~/.ssh/id_rsa.pub email@example.com:/home/ray/
This will copy the public key file to my home directory on the server. I’m prompted for a password but since scp encrypts the password it’s safe to enter it. Change the ip address to your own address and substitute your ID for ray.
Now I need to configure the public key on my Ubuntu server. Still in terminal I execute
and enter the password to connect to the Ubuntu server console. I’ll create a directory for the authorized public keys and move my key into it, changing the name of the file in the process.
mv ~/id_rsa.pub ~/.ssh/authorized_keys
This copies the id_rsa.pub file to the newly created .ssh directory and renames it to authorized_keys. Now I need to set the permissions for the directories.
chwon -R ray:ray ~/.ssh
This changes ownership of the directory. -R means to apply recursively and I’m saying to change to owner to the user and group ray. Substitute whatever ID you created.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
This changes the access permissions for the directory and file. The 700 means only my ID can read, write, or execute files in the directory. The 600 means only I can read or write the file (no execute privilege).
Now I need to configure the SSH server.
sudo nano /etc/ssh/sshd_config
The ssh_config file is loaded in the nano text editor. Scroll up and down using the arrow keys. Help is along the bottom, ^ means the control key.
Scrolling down the file I make the following changes:
Near the top you’ll see Port 22. For security purposes it’s good to change this port number, since it makes it a little harder for people to find the SSH server connection. You need to pick a port that’s above 1024 and that’s not being used on your system. Port number in the range 1024 to 49151 may be registered and used by specific applications. Port numbers between 49152 and 65535 are dynamic and aren’t reserved for any particular use. You can pick any port above 1025 as long as it won’t be used by something else on your server. A list of registered ports is maintained by iana. I picked 22222 because it’s easy to remember and not currently registered to anyone.
This means the root user can’t log in through ssh. This is a bit redundant with Ubuntu since the root user can’t logon in a typical installation.
I just needed to uncomment this by removing the # at the beginning of the line. Notice it points to the public key file we created (%h is expanded to the user’s home directory).
I uncomment this so that I can log on with password in addition to keys. The key will be used if available, if not there will be a password prompt. Setting this to no means the key must always be used. If all your PCs are secure and can use public/private keys you can set this to no, which means that the keys must be used. Just don’t lose the keys.
Since there’s no GUI on this server so I turned this off.
I’m not using the PAM module.
I added the following new lines at the end of the file.
I’ve seen there were some past issues resolved with this setting and I don’t need DNS lookups for my clients.
This specifies which users are allowed to connect via SSH. Separate multiple users with spaces.
I write the file with ^O and then exit with ^X. (^X will prompt to save but I’m paranoid and save first anyway).
Finally I need to restart SSH so I enter:
sudo /etc/init.d/ssh restart
Then I logout and login again. If everything is set up right I shouldn’t be prompted for a password, and I’m not. The proper ssh command (from OS X terminal) with the port change is:
ssh -p 22222 firstname.lastname@example.org
If you want to enable the dsa key instead, or create the dsa keys in addition to the rsa keys you can repeat the process, substituting dsa for rsa. Instead of the command
mv ~/id_rsa.pub ~/.ssh/authorized_keys you will need to concatenate the new file with the authorized_keys file. Use the following command to do this after copying id_dsa.pub to your home directory.
cat ~/id_dsa.pub ~/.ssh/authorized_keys >~/.ssh/newkeys You can chain multiple key files together in one command. Then copy the newkeys file over the authorized keys file:
cp ~/.ssh/newkeys ~/.ssh/authorized_keys
To delete the id_rsa.pub file from your home directory after it’s concatenated to authorized_keys run
I can repeat the public/private key generation from my other computers and use the above concatenation command to add the public keys to the authorized public keys list or stick to passwords since I won’t be using those computers very often.
So the server is up and running and we can securely connect. Next up I’ll get a basic firewall going and then I’ll finally be ready to install some software.
OpenSSH Quick Reference (PDF)
SSH Host Key Protection – An article From Security Focus that describes the use of SSH and provides some background.