oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Inside SSH, Part 2
Pages: 1, 2

Testing the Server and First Client Setup Step

You now have a fully functional SSH server running on this Mac. In order to test it, plug your administrative machine into the same subnet and open a Terminal window. Then, enter the magical "ssh username@ipaddress" command that you wrote down. This command simply starts the ssh client built into Mac OS X and causes it to establish a connection to the SSH server you just set up, requesting to be logged as the specified user.

I wish you could login directly but, unfortunately, that's not what happens. You see, in order to make SSH connections secure, the client and the server try to prove their identities to each other before dialoging. In order to do that, they engage in a cryptographic exchange based on keys that are preinstalled on both machines.

This is a way to prevent someone from impersonating your server and capturing your sensitive data -- a process known as a "man-in-the-middle" attack that involves passing back and forth data between an unsuspecting client and server who both think they are talking directly to each other. Since this is the first time that your client and your server meet, they have no way to make sure that they are who they claim to be. Therefore, SSH will call you for help and display the fingerprint of the cryptographic key used by the computer that pretends to be your server to identify itself -- also called the "host key."

Go to your server and enter the following command and press return:

ssh-keygen -l -f /private/etc/

It will get the fingerprint of the server's RSA key, which will be used as a unique identifier by SSH.

Simply compare the two strings. If they match, you can be sure that your computer is indeed talking to the server and not to some evildoer. Type "yes" to confirm the connection and to reassure SSH. SSH will then resume the normal login procedure.

You normally should not see this message again since SSH has written down the key it asked you to check as a "trusted" key for future reference. If you see it again this may mean that someone is impersonating your server. You should immediately disconnect your computer, pick up your phone, and call your network administrator.

SSH will then ask you for the password of the account you are logging into. Type it, press return, and you will be logged in as the user you specified (user "username" in our example). Any action you perform in this Terminal window will act on the other computer. For example, typing a command that causes the CD tray to open will open the CD tray of this machine, not yours. Be careful with that since it is easy to make mistakes and frighten unsuspecting users thousands of miles away from you who will see their optical drive wake up for no apparent reason.

To give you feedback of what you are doing, try typing a command like:

say I sure love being inside this fancy computer

That will cause Victoria's sweet voice to be heard through the remote computer's speakers.

Finally, in order to close the SSH session and go back to your local command line interface, enter exit and press return.

This Setup Is Insecure

We now have a Mac listening on the network for SSH requests, ready to grant privileges to anyone guessing the password of any account it contains. This is the default behavior of most SSH servers and, if you have picked a good password, the chances of someone guessing it are not too high. However, they do exist and should not be neglected.

In order to compensate for these issues, we are going to disable password authentication and only allow public key-based authentication, meaning that the SSH server running on the Mac will only grant access to someone possessing a specific private key, even if this person guesses an account password. Since private keys never leave your computer, stealing them requires breaking into your machine.

Furthermore, since the private keys you store on your Mac can be encrypted by the use of a password, successfully logging into the remote server requires two things: something that you have (the key) and something that you know (the password for the key), making this authentication method very solid.

Note that this is theoretical. If a vulnerability is discovered in the OpenSSH server, a remote attacker could try to exploit it to gain access to the computer without possessing the key or knowing the password for the account. This is why it is especially important to stay on top of security announcements while running a server on a computer.

Of course, there are some features built into OpenSSH that lessen the chance of a vulnerability being exploited in a useful way -- one of them being called "privilege separation." You should, however, not rely on them to counter each and every threat that could arise.

Generating Keys

Obviously, before we can think of using keys to authenticate ourselves, we need to have some. The good news is that -- unlike when you were setting up mail certificates -- you do not need to ask a certification authority for your keys. Indeed, we do not need to prove our identity to the world and can therefore create our own keys from the comfort of our Terminal windows.

In order to generate the keys, we are going to use a built-in command-line tool called ssh-keygen from the client -- i.e., your administrative computer.

As usual, open a Terminal window and type the following command, followed by return:

ssh-keygen -b 1024 -t dsa

It will create a dsa key (DSA being one of the two algorithms used by SSH2, the other being RSA) with a length of 1024. If you decided you need to use SSH1 protocol do not reuse your SSH2 RSA key. They are used differently, and the results could expose information that can be used to compromise your private key. Thus, it is always better to generate a separate SSH1 RSA key (ssh-keygen -b 1024 -t rsa1).

Ssh-keygen will ask you for the location where it should store the generated keys. Simply press Enter to install them into the default location, where the various SSH components will expect to find them.

When prompted for a pass phrase, enter a "good password" -- as defined in our Mac OS X security primer article -- that will be around 15 characters long. Remember that this password prevents a malicious program on your Mac or an attacker from using a stolen key. It is therefore extremely important and sensitive. Of course, make sure that you do remember it.

Ssh-keygen will then exit gracefully, printing the key's fingerprint on the screen.

Copying the Public Key to the SSH Server

Ssh-keygen saved the two keys it generated on your computer. However, in order for the server to make use of them, you must upload your public key onto it, in a location where it will be able to automatically locate it and use it.

In order to do so, we are going to use scp, a command that rides along SSH. Despite having an easy-looking syntax this command is capable of handling secure file transfers transparently. Indeed, by just entering the scp line, you will open a secure connection, transfer the files over it, and close it, all in one go.

To copy the files, type the following command in a Terminal window:

scp ~/.ssh/ username@serverip:~/.ssh/authorized_keys

As you can see, it copies (scp) the public dsa key we just created (~/.ssh/ into the .ssh folder of the remote user's home and renames it authorized_keys.

As a side note, you may sometimes hear of a file called authorized_keys2 -- while it should work with the current version of OpenSSH, the generic name is now preferred. This file can be used by both SSH1 and SSH2.

In case you were wondering why I advised you to manually create a folder called .ssh on your server's earlier. This is simply because this scp command needs it!

Authentication will take place like it did with our previous SSH login trial. However, scp exits all by itself and you do not need to type a special "exit" command.

A First Step Only

Now that you have uploaded your public key onto the server, it's time to test whether SSH sees it. In order to do so, log in from your administrative machine. Instead of the password of the remote account, you should be asked for the password that you used to encrypt the key.

However, you will soon notice that failure to provide SSH with this password won't terminate the connection, as we would like. Instead, it will fall back to the less secure password prompt.

Here is a troubleshooting tip. If the SSH server does not work as expected and doesn't prompt you for the password, this may be because your home, .ssh folder, and authorized_keys file are world- or group-writable. This is a security measure that prevents the server from relying on keys that could be easily compromised. If you still experience issues, make sure that your client (the Mac you are using to perform the remote administration) is correctly set up, too, and that its permissions scheme is strict enough.

Therefore, our next step will be to edit the SSH server configuration files in order to disable all these weaker authentication options that we do not like.

Next week I'll get into editing configuration files and show you some great tips for maintaining secure control of your SSH communications.

FJ de Kermadec is an author, stylist and entrepreneur in Paris, France.

Return to