Eric’s Blog

February 9th, 2007 by eric

Over the years, I have worked with many SSH boxen and had the pleasure to manage even more SSH keys. The problem with all that is the keys start to build up and then you wonder which boxes have which keys in the authorized keys file and so on and so on. Well, I can’t say I have the ultimate solution, but I do have a few tips that I have come across along the way. Hopefully they will be of use to someone else besides myself.

1. Although this should hopefully already be done (my fingers are crossed for you), check the permissions on your ~/.ssh directory and the file contained in it.
   $ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_dsa
$ chmod 640 ~/.ssh/id_dsa.pub

2. Now that SSHv2 is pretty widely accepted, try using that for all your servers. If that isn’t possible, then try to use SSHv2 whenever possible. This means a few things.
   1. Change your /etc/ssh/sshd_config file to say:
      Protocol 2
      instead of
      Protocol 1
   2. Don’t generate anymore RSA keys for yourself. Stick to the DSA keys:
      $ cd ~/.ssh
$ ssh-keygen -t dsa
   3. Use public key based authentication and not password authentication. To do this change your /etc/ssh/sshd_config file to read:
      PubkeyAuthentication yes
      instead of
      PubkeyAuthentication no
3. Keeping track of which keys are on the machine is a fairly simple yet often incomplete task. To allow for a user to login using their SSH(v2) key, we just add their public key to the ~/.ssh/authorized_keys file on the remote machine:
   1. Copy the file to the remote machine:
      $ scp id_dsa.pub user@host:.ssh/
   2. Append the key onto the authorized_keys file:
      $ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

   Before moving on here and just deleting the public key, let’s try some organizational techniques.

   1. Create a directory in ~/.ssh to store the public keys in:
      $ mkdir ~/.ssh/pub
   2. Move the public key file into that directory and change the name to something useful:
      $ mv ~/.ssh/id_dsa.pub ~/.ssh/pub/root@main.mydomain.com

   NOTE: Don’t do this unless you are sure that you can log in with your public key otherwise you WILL lock yourself out of your own machine.

4. Now a little of the reverse side of this. If a public key is no longer is use, then you should remove it from your ~/.ssh/authorized_keys file. If you have been keeping a file list in the directory, then the file should be removed from the directory tree as well. A little housekeeping is not only good for security, but also some piece of mind in efficiency and general cleanliness.
5. Although this last item isn’t really organizational, it is just really handy and I will categorize it under the title of efficiency. Using ssh-agent to ssh around. If you are a sysadmin and you want to only type your passphrase once when you login to your computer, then do the following:
   1. Check to see if the agent is running:
      $ ssh-add -L
      NOTE: If ssh-agent is not running, it will say The agent has no identities.
   2. If its running, continue to the next step, otherwise type:
      $ ssh-agent
   3. Now to add your key to the agent’s keyring, type:
      $ ssh-add

   SSH to a machine that you know has that key and you will notice that you will no longer have to type in your passphrase while your current session is active.

These are just some tricks that I use to keep things sane. They may not work for you, but some of them are good habits to get into. Good luck.

February 5th, 2007 by eric

I think I am going to get back onto my soapbox about being extraordinarily secure, only this time, I am going to compare it to ease of use. I would once again like to reiterate the fact that I am strongly for security in all its aspects. However, some people get into the presence of a security individual and freak out. They start saying that they know certain things are secure and insecure and then do them anyway.

A great example of this is SSH access to servers. Consider the following physical network layout.

                      ,---------- Server I
Inet---------|F/W|---+----------- Server II
                      `----------- Server III

If you want to leave certain nice to do’s or ease of use functionality available to your self such as leaving SSH open only to root or having a machine with anonymous FTP access available, then take a slightly different approach to securing your environment (or those particular machines): layered security. Without changing the physical layout of your network, change the network layout using iptables and/or tcp wrappers. Make the network look more like this:

                             ,------Server II
Inet-----|F/W|----Server I--<
                             `------Server III

This is essentially saying that all traffic that you want to funnel to Server II or Server III will now go through server I. This can be used in a variety of ways. Let’s say that all 3 servers are in the DMZ (De-Militarized Zone) and that Server’s II and III are hosting the services available to the outside. Allowing direct access to them via SSH or FTP probably isn’t the best idea because these are services that allow files to be changed. So what can we do to change this?

First let’s configure TCP wrappers. Starting out with the assumption that you are being paranoid where necessary, let’s set SSH up to only allow incoming connections from Server I and deny from everywhere else. In the /etc/hosts.deny file on Server II, add the following lines (everything that goes for Server II goes for Server III to mimic the setup):
sshd1: ALL
sshd2: ALL
Now in the /etc/hosts.allow file on Server II, add the IP address of Server I (IPs are all made up):
sshd1: 167.4.5.23
sshd2: none
This now ensures that the only way SSH traffic will be allowed Server II is through (or from) Server I. But let’s say that isn’t enough for you. Let’s say you want a little more security so you can sleep a little better at night. Enter netfilter and IPTables. On Server II, add the following to your firewall script:
iptables -A INPUT -p tcp --dport 22 -j SSH # Send to the SSH chain
iptables -A SSH -s 167.4.5.23/32 -j ACCEPT # Allow from Server I
iptables -A SSH -m limit --limit 5/s -j LOG # Log the problems
iptables -A SSH -j DROP # Drop everything else

So what’s the point of all this extra configuration? Simple, it allows for a little more flexibility when it comes to your setup. Although I recommend having SSH keys and not allowing direct root access from anywhere, you can get away with a little more. You can allow root access via an SSH key. And if you have enough protections/layers/security in place, you may also even consider using a password-less SSH key depending on what the role of the contacting server is (ie. rsync over SSH).

In the optimal version of a network setup with SSH, you may want to only allow user access to Server II via entry only through Server I. Then to top it off, only allow sudo access to root if the user is in the sudoers file. This throws a lot more protections behind Server II, but makes it somewhat complicated to just do something simple. This is especially true if Server II is on an internal network which isn’t very accessible anyway. The advice I generally give is in the form of the question, “What is tradeoff?” More times than not, ease of use the answer. So keeping in mind that ease of use isn’t out of the realm of possibility, just remember that layered security can be your friend. It’s usually how the tradeoff comes.

February 2nd, 2007 by eric

First off I’d like to thank Dancho Danchev for the mention in his blog entry PR Storm. Part of me creating a blog was no thanks to reading his and reposting it to Linux Security. I also plan on commenting a little on some of the things he has to say. Now that I have started a new job, I have a little more time to do such things.

I originally started my blog to keep track of a lot of things that I do on a regular basis. Now I feel like I have the time to share my ideas and make them slightly more readable for others and possibly even usable. So the likely thing to do is to cover things that I know: Perl, System’s Administration, Privacy, and Security. We’ll see where it goes from there.

My goal is to publish something at least once every other day (or 3 - 4) per week. If I have more time, I will put more up. If anyone has any topics that they would like me to cover, please feel free to let me know. My email addresses is on my site (eric AT lubow dot org). Thanks, Enjoy.