Table of Contents
Note that you don’t go into a virtual session until later in this lab; the first part is done on your local Mac OS X workstation.
The Secure SHell (SSH) is a very powerful tool for administering both servers and clients. The server side is generally found on Unix like machines or other devices with a dominant Command-Line Experience (eg. enterprise-grade routers), though there are clients for most operating systems in use today.
As SSH is such a useful and powerful tool for admins and users alike, half of today’s lab will be on using ssh, and will be done on your local machine. The other half will be done on your virtual machines, and will be about administering SSH. A significant part of the labsheet is for your reference, should you want to use this outside of the lab.
The most basic use of ssh is as a secure replacement for telnet. Do these on your local machine.
ssh gallardo.otago.ac.nzThe authenticity of host 'gallardo.otago.ac.nz (22.214.171.124)' can’t be established. RSA key fingerprint is
8d:4c:e5:9c:c4:dd:79:b3:cb:68:e1:e5:fe:48:80:9f. Are you sure you want to continue connecting (yes/no)?
yes###### # # ## # # # # ###### ##### # # # # ## # ## # # # # ###### # # # # # # # # ##### # # # # ###### # # # # # # # ##### # # # # # ## # ## # # # ###### # # # # # # ###### # # AUTHORISED USERS ONLY Administrator: Admin's Name <email@example.com> Password: This is not echoed. The following text is the message of the day /etc/motd Linux gallardo 2.4.29 #2 SMP Mon Jan 24 15:14:33 NZDT 2005 i686 GNU/Linux The following text comes from the login system (PAM) You have mail. Last login: Fri Apr 1 14:51:09 2005 from somemachine.example.com And now we get our interactive shell. theauthor@gallardo:~
logoutConnection to gallardo.otago.ac.nz closed. Returned to where we started.
In the lecture on SSH you learned about public-key authentication so let’s try that now. Do this on your local machine.
Note that if you’ve done this before, your old keys will
be overwritten, so you may want to move them out of the way for
the duration of this lab. You can use this command to move the
~/.ssh directory to
Create yourself a keypair. We’ll create a RSA key with 2048 bits. Be sure to use a strong passphrase. Press Enter to accept the default location when asked where to put the key. Passphrases, unlike passwords, can contain spaces, hence their name. A good passphrase will have plenty of letters, mixed case, numbers, and symbols.
ssh-keygen -b 2048 -t rsaGenerating public/private rsa key pair. Just press enter for this next one to accept the default. Enter file in which to save the key (/Users/theauthor/.ssh/id_rsa): Use a strong passphrase! These won’t be echoed. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/theauthor/.ssh/id_rsa. Your public key has been saved in /Users/theauthor/.ssh/id_rsa.pub. The key fingerprint is: Yours will be different… 1a:91:52:bf:41:78:7b:bc:19:a7:c1:ea:1a:cd:1f:2d
If you mistype the passphrase, you may need to do it all over again, and again, until you get it right. It’s not uncommon for me to have to have three goes before I get it right, but then again, my passphrase is very long; longer even than the length of the passphrase entry dialog box.
If you find that it is taking a long time to create the key, the operating system entropy pool (which feeds the random-number generator) may have run dry. You can “stir in” some randomness by doing something like moving the mouse a lot, or causing a lot of system activity. The kernel uses the timings of such things as a source for entropy.
Remember the private key
~/.ssh/id_rsa must be kept secret, so it
should be encrypted with a suitable passphrase.
Now we are ready to install the public key of the key-pair that we generated on our Mac OS X workstation into your account on Gallardo. Still on your local workstation, output the public key, and copy it to the clipboard:
cat ~/.ssh/id_rsa.pubssh-rsa AAAAB3Nza… copy this long line to the clipboard
Now SSH into Gallardo, and edit the file
~/.ssh/authorized_keys, adding the public
key to this file, which adds your public key to the list of keys
allowed to access your account. Note that you will likely need
to create the directory, and beware that the filename uses
mkdir -m 0700 ~/.ssh
The lines in this file are very long, and would wrap onto multiple lines in your terminal. Ensure that your editor does not insert newlines to break the lines, otherwise the entire file will be unusable.
This is particularly important for users of the nano editor. If you really want to use nano, use nano -w, which turns off wrapping.
vim ~/.ssh/authorized_keysAmerican English! Paste in the public key into a single line. ssh-rsa
Now log out of your SSH session from Gallardo. In the next section, we will login without using a password.
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.
But this does assume that users choose good passwords and passphrases. One of the worrying things about passphrases on private keys is that server administrators have no way of enforcing that the private key is suitably well-protected.
Technically-speaking, public key authentication is only a single factor (something you have — although it is a thing that can be copied), as we can’t be certain there a pass-phrase protects it (something you know). Passwords, on the other hand, are just something you know, which is also a single factor.
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
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.
Procedure 1. Download, Compile and Install ssh_locker
In a terminal, create a temporary directory and cd into it.
Download the ssh-locker source code from Dave Dribbens Google Code project.
svn co http://ddribin.googlecode.com/svn/tags/ssh_locker/1.0/…
cd into 1.0 directory and open the Xcode project (open ssh_locker.xcodeproj). The open command does the same thing as if you have clicked on it in the Finder.
Ensure the Xcode Active Build Configuration in the leftmost position in the toolbar is set to Release instead of Debug and then click (you do not need to run it). Quit Xcode.
Back in terminal, cp
build/Release/ssh_locker into your
~/bin/ directory; you will need to create
this directory if it not already there (although you should
have created it during the Scripting lab).
Don’t worry about copying the manual page, as it’s only a template in this version and has not been used by the author.
Edit the property list file
change the location of the program to point to where you
copied ssh_locker. Figure 14, “Editing the Property List for ssh_locker” shows an example.
If you don’t know the path to your home directory, open a terminal window and use the command echo $HOME, which will output the full path to your home directory.
Documentation on the various elements available for use
in property list files for launchd can be
reading that, and the also the manual page on
indicates that it must be either the full path or it will look
PATH environment variable, which
will not include your home directory at that time.
Copy the edited property list file to
~/Library/LaunchAgents/; you will
probably need to create the directory first.
Tell launchd that you have a new configuration service you wish to load; you only need to do this once. Use launchctl load ~/Library/LaunchAgents/
The service will be started when it is loaded. This is because the RunAtLoad property has been set in the property list we edited previously.
Verify that it is currently running and known to launchd. Do this using launchctl list | grep org.dribin.dave.ssh_locker. If it has a number in the leftmost column, which is the PID column, then it is currently running.
launchctl list | grep ssh_locker
The purpose of ssh_locker is to ensure that ssh-agent is killed when the Mac OS X Keychain gets locked (due to timeout, screen-saver starting, laptop lid being closed, etc.)
To verify that this is actually happending, we can first ssh to Gallardo, to ensure that ssh-agent is working, then log out of the SSH session. ssh-agent should still remain running for subsequent use. Check that this is the case by attempting to log into Gallardo again via SSH (no authentication interaction should be needed).
On your local Mac OS X workstation, open up
Activity Monitor from
ssh into the search field, to limit the
processes to those with
ssh in the
name. You should see the command ssh-agent
-l running, as well as
ssh_locker. This is shown in Figure 15, “Viewing Processes with ‘ssh’ in their Name”.
Start up the Keychain Access
utility, also found in
/Applications/Utilities/. Go into the
and tick the box labelled Show Status in Menu
Bar. This should result in a black padlock icon
showing in your Mac OS X menu bar at the top of the
Now lock the Keychain by clicking on the padlock icon in
your menu bar and choosing ssh-agent soon disappears. If not,
check your local workstation logs using the
Console utility in
If you try to SSH again, you will be asked to unlock your “login” keychain (in which case you would respond with your Mac OS X login password, not your passphrase).
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 PuTTYgen gets it entropy from. When this has completed, you should see a window similar to the following:; you will notice the helpful progress meter. You will need to move the mouse as instructed… it appears that this is the only source
Change the comment to something more meaningful, and set a
good passphrase. When done, you need to click
~/.ssh on Unix hosts, so I
suggest you create a folder
and store them in there. Give the public and private key the same
base name, but distinguish them by putting
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 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.
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
~/.ssh/authorized_keys file. Open
this file in an editor and paste your key into it ensuring it is
stored as a single line.
To paste in PuTTY simply right-click. This is counter-intuitive (note that middle-click doesn’t work, but a Windows user wouldn’t expect that to work), and Ctrl-V doesn’t work because that is passed through the SSH channel.
Log out when you are done. Now when you log into the server
again you should be asked
Passphrase for key
“ 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.
Start Pageant from within the menu of the 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 item to add the key to your key list; you will be asked to unlock your private key using by entering your passphrase.
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 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 to save your session details. Then click 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.