Securing SSH
SSH or Secure Shell is one of the most useful applications for administering computers remotely. In reality it is a suite of applications that were created to replace a number of insecure equivalents. Telnet was replaced with SSH which allows for command line access to remote hosts. SCP replaces out RCP, which allows for copying of files or directories to a remote host. Lastly SFTP replaced out FTP and allows for the placing of files on a remote host for later retrieval from a third party. Why replace out the old standards? All data transmitted using these older standards are sent in the form of clear-text. This includes your user ID and password! Data sent via these newer standards are encoded using strong encryption algorithms (Triple DES, Blowfish, AES to name a few). SSH encrypts your data before it is put on the wire. The result is transparent encryption: users can work normally, unaware that their communications are safely encrypted on the network (Barrett, 2001). SHH has a number of benefits. You can get more information at the OpenSSH website.
Out of the box Apple does a great job of securing the OS but there are a number of ways to help SSH further. Apple by default allows root access via SSH. This is not a bad thing per say IF the passwords are strong. The reality is that passwords are never as strong as they should be. Often the passwords are based on normal everyday words and user accounts are normally easy to guess… How about Administrator for example? This can lead to a brute force dictionary attack that if the host is compromised root access is achieved…a bad thing to say the least.
Disabling root
Apple allows root access by default because it needs this to set up replica servers in Open Directory (OpenLDAP). Once the replicas are bound to the directory root access should be turned off. Unfortunately this is not something that can be accomplished easily from Server Admin. There are two ways to accomplish this:
1. Edit the /etc/sshd_config file using a text based editor and add the following line to the end of the file:
PermitRootLogin no
This is by far the most direct method to accomplish this.
2. The other is to allow other users to access the host via SACLs (or Service Access Control Lists).
Figure 1
The downside to option 2 is that you are forced to allow users you may not want having access to you server. As you can see from this above image we have disabled root by allowing the user Bill Heese to have SSH access to the server. This may not always be the desired outcome. The nice thing about disabling the root account this way is the ease of this can be configured. Apple provides a very nice GUI application to accomplish this, Server Admin. One thing to note is that if you are administrating a large number of desktop as well as server this needs to be done on the workstations too. And have SSH enabled you should be editing the sshd_config file on those machines as well.
SSH Keys
Let’s say that you have to log into 20 or 30 machines per day, at the end of that day that can lead to a lot of keystrokes. Even the most focused individual can get interrupted may times during the course of a day. Trying to remember exactly why you are access a host can be a challenge at times now add to that, the servers password.
There are those that feel that using SSH keys is an unsafe practice (and it CAN be) if you don’t protect your host correctly. I have this implemented behind a gateway firewall and behind IPFW rules. This being the case a hacker would have to compromise the network and then the host itself. Is this a guarantee that a hacker can’t get to you? No, but it does make it somewhat more difficult to get at the machines.
So the first thing that I need to do is generate the keys that I am going to use.
ssh-keygen -t dsa
You can use other algorithms based on your comfort levels. See the man pages on ssh-keygen to see which flags are built into your version of ssh. You should see something very much like this:
control:~ bheese$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/bheese/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/bheese/.ssh/id_dsa.
Your public key has been saved in /Users/bheese/.ssh/id_dsa.pub.
The key fingerprint is:
52:d4: ee:d5: c9:b9: 2e:0a: 0a:ac: 6a: 8d:c9: ee: 9c:cc bheese@control.randomdog.net
I did not put a passphase in as I want to be able to access the server using only my SSH keys! ls produces the following out in the .ssh directory.
control:~/.ssh bheese$ ls -al
total 48
drwx------ 7 bheese bheese 238 Mar 2 18:58 .
drwxr-xr-x 30 bheese bheese 1020 Feb 29 22:51 ..
-rw------- 1 bheese bheese 672 Mar 2 18:58 id_dsa
-rw-r--r-- 1 bheese bheese 626 Mar 2 18:58 id_dsa.pub
-rw-r--r-- 1 bheese bheese 5828 Dec 27 19:14 known_hosts
To be able to log in to remote systems using your pair of keys, you will first have to add your public key on the remote server to the authorized_keys2 file in the .ssh/ directory in your home directory on the remote machine. Once this is completed… Log into the machine with the account you created the authorized_keys2 for. You will not be prompted for a password.
One reason for doing this is to allow for scripting across the network. Now you can create a script that can be run against a file that contains (or any input from STDOUT) a list of all machines you want the script to deploy on.
Resources:
Barrett, D. & Silverman, R., (2001, Feb), SSH – The Secure Shell: The Definitive Guide, Sebastopol, CA: O’Reilly Press
