Remote Terminal Services

Table of Contents

1. Logging in Without a Password
1.1. Using the Mac OS X Keychain in Leopard
1.2. [Optional] Logging in Without a Password From Windows XP
2. Using ssh
3. scp & sftp
4. Server (sshd) Configuration
5. [Optional] Local Port Forwarding
6. User Imposed Restrictions on Public Keys
7. [Optional] Preventing Dictionary Attacks
8. Assessment

Note

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.

workstation$ ssh gallardo.otago.ac.nz
The authenticity of host 'gallardo.otago.ac.nz (139.80.206.169)' 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 <admin@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:~ logout
Connection to gallardo.otago.ac.nz closed.
Returned to where we started.
workstation$ 

1. Logging in Without a Password

In the lecture on SSH you learned about public-key authentication so let’s try that now. Do this on your local machine.

Note

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 ~/.ssh.off.

workstation$ mv ~/.ssh{,.off}
  1. 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.

    workstation$ ssh-keygen -b 2048 -t rsa
    Generating 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 Comment

    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.

    Important

    Remember the private key ~/.ssh/id_rsa must be kept secret, so it should be encrypted with a suitable passphrase.

  2. 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:

    workstation$ cat ~/.ssh/id_rsa.pub
    ssh-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 American English.

    gallardo$ mkdir -m 0700 ~/.ssh

    Don’t break the lines!

    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_keys   American English!
    Paste in the public key into a single line.
    ssh-rsa AAAAB4Nza…
  3. Now log out of your SSH session from Gallardo. In the next section, we will login without using a password.

1.1. Using the Mac OS X Keychain in Leopard

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.

Important

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 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.

Procedure 1. Download, Compile and Install ssh_locker

  1. In a terminal, create a temporary directory and cd into it.

  2. Download the ssh-locker source code from Dave Dribbens Google Code project.

    workstation$ svn co http://ddribin.googlecode.com/svn/tags/ssh_locker/1.0/
    
  3. 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.

  4. Ensure the Xcode Active Build Configuration in the leftmost position in the toolbar is set to Release instead of Debug and then click Build (you do not need to run it). Quit Xcode.

  5. 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.

  6. Edit the property list file org.dribin.dave.ssh_locker.plist and 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.

    Figure 14. Editing the Property List for ssh_locker

    Editing the Property List for ssh_locker

    After editing org.dribin.dave.ssh_locker.plist


    Tip

    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 found in launchd.plist(5); reading that, and the also the manual page on execvp(3) indicates that it must be either the full path or it will look through the PATH environment variable, which will not include your home directory at that time.

  7. Copy the edited property list file to ~/Library/LaunchAgents/; you will probably need to create the directory first.

  8. 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/

  9. 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
    41217   -       org.dribin.dave.ssh_locker
  10. 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 /Applications/Utilities/. Enter 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”.

    Figure 15. Viewing Processes with ‘ssh’ in their Name

    Viewing Processes with ‘ssh’ in their Name

    We see that the processes ssh-agent -l and ssh_locker are currently running (you can see the options by clicking on a process and then clicking on Inspect).


    Start up the Keychain Access utility, also found in /Applications/Utilities/. Go into the Keychain AccessPreferences…, 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 screen.

    Now lock the Keychain by clicking on the padlock icon in your menu bar and choosing Lock Keychain “login”. When you do that, you should note that ssh-agent soon disappears. If not, check your local workstation logs using the Console utility in /Application/Utilities/.

    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).

1.2. [Optional] Logging in Without a Password From Windows XP

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.

Tip

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 “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.