Secure Shell at CFHT

NOTE: This document is for CFHT personnel only and should only be made available on local-access Web pages. Please do not redistribute it.
The ssh program (secure shell) is similar to rlogin and telnet, but provides additional security and functionality. CFHT restricts rlogin and telnet connections that originate outside of our own network because these connections are now commonly traced by hackers and used to break in. The instructions below are meant for CFHT employees who would like to run ssh in a unix environment. A similar procedure will work under MS Windows if you install the cygwin32 unix-like tools first, but I would recommend that anyone attempting that come talk to the software group about it first. If you have Linux on your laptop/PC or have access to a unix host at another facility from which you'd like to connect to CFHT, these instructions are for you.

If you follow the directions here, it should only take about 15 minutes to set up ssh, but you should take the time to do it before leaving on a trip, as it is easier to set things up and test them locally first.

Why do I have to read all this?

Having ssh on your computer is like having a key to the building. Except, with a regular lock and key, we all understand the basic precautions that should be taken to avoid leaving open invitations to intruders. If you take a few minutes to read this page, you will not only get a quick tutorial on how you can use ssh, but you'll also learn how not to do the equivalent of leaving a key in a lock or propping a door open. The secure shell protocol may be safer than telnet or rlogin, but it is not foolproof, so please do us all a favor and use it responsibly!

For example: you should always use ssh from your local machine's console, directly to CFHT. If you first telnet or rlogin to the machine where you've installed ssh, then someone can pick up your passphrase and we will eventually get a break-in! This is important: Do not telnet or rlogin first to the machine from which you run ssh! The security chain is only as strong as its weakest link.

If you already know all about ssh you can jump to Installation which contains special information related only to CFHT, but please read the following before reporting problems with the ssh installation at CFHT.

System Requirements

  1. SunOS, Solaris, IRIX, HP-UX, or Linux. If you have one of the above operating systems, chances are you can just download our precompiled binaries of the client utilities (ssh-keygen. ssh, and scp). It is also possible that the client software already exists on the outside machine. Try: (NOTE: In the following examples, stuff in bold is usually what you type, and outside% and cfht% refer to the unix shell prompts on the outside machine and the cfht machine you are trying to get access to.)
        outside% which ssh
    
    If something like /usr/local/bin/ssh already shows up, you can probably just use the existing version. If you prefer to compile ssh yourself, or the correct binaries are not available here, then you can still download the source from the ssh home page at http://www.ssh.fi/sshprotocols2/. We are currently still running SSH1. I have not researched SSH2 to see what the difference is, but it looks like it is becoming more of a commercial product now. Please contact the software group if you need to run ssh on a platform that's not listed on this page.

  2. Normal User Access. Even if you have to install your own client software, you should be able to do everything without having root access on any machine.

  3. TCP/IP. Whether you are using ssh from home, or while traveling, your computer must be properly networked with a TCP/IP stack. Sun and HP workstations will almost always be properly networked, but when dialing in on a modem connection, you must use PPP or SLIP so your computer has an Internet address. (Note: modem pools that supply you with a "random" address from a pool are OK with this procedure. There's also nothing special to do as far as ssh is concerned if you are given an IP number for your laptop at another facility.) If you usually dial a modem pool from a terminal window and run a telnet or rlogin session from that window without starting PPP or SLIP, ssh will not work. Please see Sidik in software to get a copy of a document on how to get SLIP working under Linux or Windows NT. Bernt has information on his home page on how to configure Windows 95 PPP.

What Exactly does SSH do?

I mentioned above that ssh lets you log in to CFHT machines from the outside. As it turns out, ssh is also useful as a way to connect your Linux machine to CFHT from our local modem pool. Since the modem pool is inside our local network, there are ways to telnet or rlogin, but using ssh from the inside gives you more:
  1. Compression. All traffic sent over the ssh connection can be compressed to improve performance. This is especially useful when combined with X-protocol tunneling and secure copy functions described below.

  2. Encryption. Telnet and rlogin send your password in plain text over the network. Today it is easy for someone with even very little computer background to collect these passwords and cause havoc on our machines. Normally, ssh will encrypt your regular Unix password, making it much more difficult for a hacker to get anything useful. With our configuration of ssh, we go even one step further: your ssh password is NOT the same as your unix password. Instead, we use something called public key encryption, where the password never has to be sent at all! The details of how it works are too complicated to go into here, but the important thing I think all users should realize is how something called key pairs will operate. When you generate a key, there will be two files on the harddrive of your computer: ~/.ssh/identity   and   ~/.ssh/identity.pub

    For encryption to remain secure, all users must be aware of the following: You only give out/copy the "identity.pub" file. No one ever has to see .ssh/identity. If it is compromised, please notify us immediately. The ssh tools will generate the identity file for you with the permission: (see also the note on permissions of all ssh files.) In these examples, "outside%" is just supposed to represent the command prompt of a machine "outside" the CFHT network.

        outside% ls -l ~/.ssh/identity*
    ->  -rw-------   1 you      users         526 Mar 18  1998 ~/.ssh/identity
        -rw-r--r--   1 you      users         329 Mar 18  1998 ~/.ssh/identity.pub
    
    This means only you can read it. Never copy identity somewhere else or change these permissions! If you copy your hard disk for someone else, remove at least this one file and you are safe. This is really the only thing you have to remember to keep ssh safe.

  3. X-protocol tunneling. You will be able to start X-Windows programs on CFHT machines and have them display at home and on machines outside of the CFHT network.

    Assuming you have your DISPLAY variable set correctly at the local end (the machine on which you run the ssh client) and assuming you do not override DISPLAY in your .cshrc/.login (or equivalent) on the outside host (in your CFHT account)

  4. Secure Copy. Instead of FTP (which is blocked to any machine except our anonymous FTP server) you can use the scp program to safely copy files back and forth on the outside machine. scp can automatically compress (gzip) files as they are copied back and forth, and uses the same syntax as the BSD rcp command. In fact, the ssh tools are designed to be a drop in replacement for rexec, rsh (remsh), and rcp which already exist on most modern Unix systems.

Installation

  1. Install ssh client programs. On the "outside" machine, you will need at least three programs. If ssh-keygen, ssh, and scp don't already exist, you can try our pre-compiled binaries for Solaris 2.x, Solaris 2.6+, SunOS 4.x, HP-UX, or Linux. Download the appropriate file and untar the three programs to a directory somewhere in your PATH.
        outside% tar xvf ssh-1.2.26-clients-osname.tar
    
    Where "osname" will depend on which operating system you are using on the outside machine.

  2. Generate a key-pair on the outside machine.
        outside% ssh-keygen
        Initializing random number generator...
        Generating p:  ..........++ (distance 198)
        Generating q:  ..........................................++ (distance 672)
        Computing the keys...
        Testing the keys...
        Key generation complete.
        Enter file in which to save the key (~/.ssh/identity): [Return]
        Enter passphrase: [Please enter a passphrase here!]
        Enter the same passphrase again: [...]
        Your public key is:
        1024 35 150...859 you@outside
        Your public key has been saved in ~/.ssh/identity.pub
    
    Unfortunately, we have no way to enforce a proper passphrase (without modifying ssh), so we ask for your cooperation in entering a passphrase, preferably at least 8 letters and perhaps similar to, but not identical to your Unix password. Again, PLEASE DO NOT SKIP THIS STEP!.

    Once you're generated the key, it will be valid on any other machine that sees this same home directory. (You only have to do this, and the next step, once per home directory, not per machine.)

  3. Copy identity.pub to CFHT. If you still have access to your CFHT account, you can email the file to yourself, or you can cut and paste it from a terminal window. If you cannot log in at CFHT, email the contents of identity.pub to ssh-admin and ask us to do the following step for you... The contents of identity.pub need to be appended to a file ~/.ssh/authorized_keys. The whole string must be on a single line. If you already have a ~/.ssh/ directory on your CFHT account, you can skip the first command, but it must be mode "755" or ssh will not work.
        cfht% mkdir ~/.ssh
        cfht% chmod 755 ~/.ssh
        cfht% echo "1024 35 150...859 you@outside" >> ~/.ssh/authorized_keys
        cfht% chmod 644 ~/.ssh/authorized_keys
    
    The string inside the echo "..." is just an example. Paste the contents of your identity.pub in there and the command should do the right thing. You could also load ~/.ssh/authorized_keys into your favorite editor and add to the end of it that way. But be careful. The entire key must appear on one line.

    You might want to compare the final result with the example in the note on permissions of all ssh files.

    To summarize, you have to copy identity.pub from the outside host to authorized_keys on the CFHT host. These files are kept in subdirectories ~/.ssh/ at both ends.

  4. Create a config entry. Back on your "outside" machine, use your favorite text editor to create an entry in a file called ~/.ssh/config that will make logging in faster and allow you to tweak compression options. If the config file doesn't exist yet, you'll want to make sure you create it with the appropriate permissions so that only you can read it:
         outside% touch ~/.ssh/config
         outside% chmod 600 ~/.ssh/config
    
    (Again, compare with the example in note on permissions of all ssh files.) Now edit the file and add the following entry, replacing the bold text with the appropriate strings:
         Host cfht
           Port 2266
           HostName 128.171.80.56
           Compression yes
           CompressionLevel 6
           FallBackToRsh no
           KeepAlive yes
           User your_cfh_userid
    
    Note that we do not use the standard port (22). The IP address given above is for kuanalu.cfht.hawaii.edu (you could also use the real hostname there, but using the IP address will give you less trouble. Instead of cfht, you could use any other name (like "kuanalu"). You can create as many of these entries as you want in your config file. You could create an entry for each of the following machines:
    128.171.80.56   kuanalu.cfht.hawaii.edu kuanalu
    128.171.80.57   ono.cfht.hawaii.edu ono
    128.171.83.61   makani.cfht.hawaii.edu makani
    128.171.80.131  saturn.cfht.hawaii.edu saturn
    
    For security reasons, please only include the machines you think you will actually need for now. If you need multiple machines, include the set of lines "Host" ... "User" for each one.

  5. Test it. If you want X forwarding to work, make sure your DISPLAY variable is set properly on the outside machine:
        outside% echo $DISPLAY
        outside:0.0
    
    Now try logging in from the outside host to the cfht host that you've chosen:
        outside% ssh cfht
        Enter passphrase for RSA key 'you@outside': [the passphrase chosen above]
     
        [The following appears only if this is the first time you are connecting:]
        Host key not found from the list of known hosts.
        Are you sure you want to continue connecting (yes/no)? yes
        Host 'kuanalu' added to the list of known hosts.
    
        Welcome to CFHT ...
        cfht%
    
    Now when you look at your DISPLAY variable on the cfht host, it should say something like:
        cfht% echo $DISPLAY
        cfht:X.0
    
    Where cfht is the hostname (like "kuanalu") and X is not 0. If it says nothing, :0.0, unix:0.0, kuanalu:0.0, or anything else that doesn't match the above, you probably have a problem with your .cshrc/.login setting DISPLAY for you. To get things working smoothly, you might consider switching your login shell at CFHT to bash. See the main software page for information on how to use Bash.

    Start an X client to actually test the connection. For example:

        cfht% xclock
    
    It should pop up on outside:0.0's desktop after a while. The more complex the application, the longer it will take to appear (can be up to several minutes, so be patient.) Also, X is not designed to be operated over networks with significant lag, so be prepared to wait for pull-down menus to catch up with you, and button presses to take a second or two to react. This is normal, and is a limitation of the X11 protocol.

    If you want an equivalent to (non-anonymous) ftp, test out scp also. To copy a file from your PC to CFHT, use the following. There is no need to compress the file first, since scp will do it on the fly as long as you have compression enabled in your ~/.ssh/config

        outside% scp .login cfht:PC.login
        Enter passphrase for RSA key 'you@outside': [...]
        outside%
    
    Or to copy a file from CFHT back to your machine:
        outside% scp cfht:.login CFHT.login
        Enter passphrase for RSA key 'you@outside': [...]
        outside%
    
    You can also run commands directly on the CFHT machine without actually logging in to a shell:
        outside% ssh cfht ls -l PC.login
        Enter passphrase for RSA key 'you@outside': [...]
        -rw-r--r--   1 outside    cfht        194 Oct 25  1996 PC.login
    
    Note that no matter which direction you are scp'ing files, you always run the client programs (ssh and scp) from the outside host. Running ssh or scp from CFHT to get back out to your machine is also possible, but requires you to run the sshd (secure shell daemon) on the outside machine. Most users will not find it necessary to do this.

Precautions

  1. Always use a passphrase on your key. Otherwise, anyone with access to your PC or outside machine could just type "ssh cfht" and they will have broken in to our network!

  2. Keep your private key ( ~/.ssh/identity ) safe. Also keep the correct permissions on the ~/.ssh/ directory ( . "dot" in the example below) and the files in it. Things should look something like this (you may not have all files at each end, but if they exist, the -rw-... lines should match what you see here.)
        % ls -al ~/.ssh
        drwxr-xr-x   3 you      users         1024 Nov 18 16:21 .
        -rw-r--r--   1 you      users         1646 Oct  7 15:02 authorized_keys
        -rw-------   1 you      users          806 Nov 18 16:21 config
        -rw-------   1 you      users          522 Apr  9  1998 identity
        -rw-r--r--   1 you      users          326 Apr  9  1998 identity.pub
        -rw-------   1 you      users         7897 Dec  1 20:32 known_hosts
        -rw-------   1 you      users          512 Dec  1 20:32 random_seed
    
    Note that only the directory itself, authorized_keys, and identity.pub need to be world readable.

  3. If a private key is ever compromised, remove the corresponding line from ~/.ssh/authorized_keys   in your CFHT account as soon as possible.

  4. Keep the ~/.ssh/authorized_keys   file trimmed as much as possible. Do not leave old or redundant lines in there, because someone with the old private key could use it to log in.

  5. Run ssh directly from your local machine to CFHT. Don't log into it over the net with an insecure protocol like telnet. Read the note about this at the top of the document for more information.
If you have any other questions or problems with ssh, please contact someone in the software group for help. If properly used, ssh can be a powerful and relatively safe way to access CFHT, but we're still counting on you to be responsible!

Links (TM)


1998 December 2 ssh-admin@cfht.hawaii.edu