This section is relevant to Mac OS X 10.5 “Leopard” and 10.6 “Snow Leopard” only. To do the same thing on Mac OS X 10.4 “Tiger” and previous, please look for software called “SSH Keychain”.

When Apple released Mac OS X 10.5 “Leopard” they integrated the SSH agent with the local Keychain subsystem, which is the part of the system responsible for remembering passwords, assuming you have allowed it to do so. It also has security features such as locking the keychain, which includes the SSH keychain, upon a timeout, screensaver or when you sleep the computer which would happen when you close the lid on a notebook computer.

The system Keychain is generally (rarely is it otherwise) encrypted with the users login password, and here I shall take pains to try and get to you understand something. Which is likely to be stronger: a typical users login password or a typical users SSH passphrase? Actually, this is something of a moot point due to the typical qualifier: a typical user will likely have as poor of a password and passphrase as they can.

A security-conscious user on the other hand will have a fairly good password and hopefully an even better passphrase. When a key is added to the users Keychain, it is first decrypted by asking the user for their passphrase, and then adding the decrypted private key to the user’s Keychain. Remembering that the user’s Keychain is encrypted on disk with the user’s login password, and that a well-chosen passphrase should be stronger than a well-chosen password, you should be able to see that we have likely reduced the strength of the protection for the private key.

Now if you’ve added your public key to the authorised keys list in your target account you should see the following dialog pop up when you SSH into the account. Let’s just compare this to other systems for a moment. In Mac OS X 10.5 “Leopard” you have the option to Remember password in my keychain (the password here is the SSH passphrase). Unlike other systems, you won’t be prompted for this on subsequent SSH connections OR subsequent (local) login sessions, as we’ve essentially unlocked it when we logged into our local machine, rather than having to enter our passphrase.

Think about what the security implication of this design decision, and come up with three good policies/practices that users should be encouraged or even required to do. This is part of your assessment.

Unfortunately, that is not all there is to it. It appears that this version of Apple’s version of ssh-agent (when run with Apple’s l option) is not as well integrated with the Keychain as we would like, as when the Keychain is locked ssh-agent doesn’t remove the key, thus ssh can still access the private key. Alas, sometimes the world of system administration overlaps with the world of programming. Fortunately a nice fellow by the name of Dave Dribin has already written a very useful article called Securing ssh-agent on Mac OS X 10.5 (Leopard). Have a read of it to see how he used multiple keychains to affect different policies. Dave created a program, ssh_locker, to stop the ssh-agent when the Keychain is locked. Here is the procedure, which you should follow, to download, compile and install it.

This section is optional; but it is useful to know in order to access a server from off-campus using a Windows machine. Public-key authentication can be really useful, and sometimes it can even be required (to prevent dictionary attacks on passwords); we shall see more of this in the section on Section 7, “[Optional] Preventing Dictionary Attacks”.

Windows XP or Vista doesn’t come with its own SSH client software, so third party software must be used. PuTTY is a very common application for this task, which does a good job and is freely available. PuTTY is also available on other platforms such as Linux; its position in that market can be seen as a GUI SSH client.

In this section we shall look at PuTTYgen for generating our key-pair; PuTTY for our SSH client program; Pageant for our SSH Key agent and WinSCP for transferring files using SFTP. All software mentioned here is also Open Source software.

You could reuse (import) an existing key-pair, but for this section we shall assume that we will create a new key-pair for ourselves. To do this we shall use PuTTYgen. Launch PuTTYgen from within the Start menu (you’ll find it under the PuTTY folder). Select the SSH-2 RSA option (it will likely already be the default), and make the number of bits in the key 2048 instead of 1024, which is a little short for today.

Click Generate; you will notice the helpful progress meter. You will need to move the mouse as instructed… it appears that this is the only source PuTTYgen gets it entropy from. When this has completed, you should see a window similar to the following:

What you should see after initial creation of a key-pair using PuTTYgen. The default comment is not useful and should be changed, and the passphrase needs to be set.

Change the comment to something more meaningful, and set a good passphrase. When done, you need to click Save public key and also Save private key. There appears to be no standard location for this, such as ~/.ssh on Unix hosts, so I suggest you create a folder My Documents\SSH and store them in there. Give the public and private key the same base name, but distinguish them by putting public and private at the end of the name (not as the extension).

Before you can use the key to log into an OpenSSH server, you must first convert the public key to the format expected by OpenSSH. Fortunately, PuTTYgen recognises this as a very common requirement and in its main window has the public key which in the correct format. Select and copy the public key.

Now login to your server using PuTTY. You will want to make some changes and set up a session for the particular server. This includes data such as: what host you wish to connect to; what username (if any) you want to log in as by default; which private key you want to use to authenticate and whether agent forwarding should be enabled. Save the session using the Save button in the Session pane. The first time you log into a machine from the client you will be prompted regarding the server’s fingerprint, as the client will not have seen the server’s certificate before and by default has no way of knowing if it is legitimate. Click Yes, noting that it is right to be suspicious if you don’t expect this dialog.

It is best to check the fingerprint of the key to ensure that you are connecting to who you think you are connecting to.

You will see that PuTTY outputs Server refused our key on the terminal. This is because we have yet to install our public key in the target account’s ~/.ssh/authorized_keys file. Open this file in an editor and paste your key into it ensuring it is stored as a single line.

The server refuses our key because our public key has not been installed into the account.

Log out when you are done. Now when you log into the server again you should be asked Passphrase for key “key comment” rather than for the password. We will be asked this each time because we’re not using a key agent (Pageant) at this time; let’s remedy this now.

We are asked for our passphrase each time because there is key agent currently running.

Start Pageant from within the PuTTY menu of the Start menu. A new icon will appear in your system tray. If you right-click on this icon you will get a menu from which you can interact with Pageant or start any saved PuTTY session. Use the View Keys item to add the key to your key list; you will be asked to unlock your private key using by entering your passphrase.

Pageant is software that caches unlocked private keys; it plays the role of the key agent.

Now, when you use PuTTY to connect Pageant will be consulted for the unlocked private key instead of prompting the user for the passphrase.

Now that our private key has been unlocked and loaded into the key agent our SSH client doesn’t need to ask the user.

Now let’s try WinSCP, which is made by different people. WinSCP also includes Pageant and PuTTYgen as part of its installation, so it should work.

Launch WinSCP. Fill in the entries for hostname, username and private key (not password). I would also suggest setting the SSH protocol version to 2 only and only selecting Enable compression if you are going over an Internet link or WAN. Click Save… to save your session details. Then click Login to log into the server.

You will notice that a different server key cache is used, so you will need to tell WinSCP to trust the server’s key since this is the first time you will have connected to the given server using WinSCP on this machine. WinSCP is not a bad program, but it does have one major annoyance: it doesn’t have good support for Unicode filenames… the WinSCP program was not written as a Unicode application, and it would apparently take a lot of work to make it so.