Secure SHell (SSH), Version 2

• Why Use SSH? 
• Need to use both SSH1 & SSH2? 
• SSH Terminology 
• Set up the SSH environment 
• SSH Communication
• How SSH2 Protects Accounts 
• Examples with Output 
• WWW References 

Why Use SSH? 

ITC is continually on guard against passwords being intercepted, and we have taken measures, e.g. stringent password checking, that have made most users conscious of the vulnerability of our computers. A malicious intruder to even one computer could wreak havoc throughout the University's computing systems, damaging the work of an individual user or the entire computing community. Check the damage list for some examples of what can occur. All of us must protect all computers we use, and not just rely on ITC, to have a safe environment in which to work. Ultimately, this will occur only if the password exchange is circumvented. SSH plays a big role by replacing telnet, rlogin, rsh, rcp, and eventually, ftp, with a secure, encrypted means of communication between a user's computer and a remote machine.

Although SSH is used most explicitly between Unix platforms, PC and Macintosh users need to become equally cautious of their data transmissions. In fact, one of the reasons for our upgrading to SSH2 was that the software ITC provides for secure communications through Mac's and PC's requires SSH2. ITC's recommended applications for the PC are SecureCRT and SecureFX. For the Macintosh, NiftyTelnet serves as a secure-ish telnet connection. Only password authentication is supported, but it's free, stable, and widely used.

SSH2 is the focus of this document, in particular the use of the Secure SHell without a password. Before we get into the complexities ...

Anyone can use encrypted communication with a password and avoid many configuration issues outlined here. SSH is actually a protocol. It comes as a suite of tools: Secure SHell (ssh), Secure LOGIN (slogin), Secure CoPy (scp), and Secure FTP (sftp). The simplest secure connection between computers is slogin, rather than telnet or rlogin. With slogin, scp, and sftp, your password is passed through an encrypted channel based on the ssh communication protocol. All commands and processes that occur as "children" of the connecting process are protected by this same channel, as long as this "ancestor" process is active.

Listed below are a couple of documents related to this one. The first, "Secure Shell (SSH) Version 1", outlines the procedures for using SSH1, as some users may be working with computers that have not moved to SSH2. The second document, "Changing from SSH1 to SSH2", gives specific instructions to PC, Macintosh, and Unix users who must change their environment to accomodate SSH2.

http://www.itc.virginia.edu/desktop/security/ssh1.html

http://www.itc.virginia.edu/desktop/security/ssh1to2.html

For technical information beyond the scope of this document, refer to the links in the last section, WWW References.

Need to use both SSH1 & SSH2?

You do if you continue using a remote computer that is not yet running SSH2. In that case leave the .ssh directory that you created for SSH1 intact. If you need to use SSH1 to a remote computer not yet upgraded, but you have not yet implemented it, instructions for doing so are in the document

http://www.itc.virginia.edu/desktop/security/ssh1.html

SSH Terminology

SSH has numerous terms for setting up and using the public and private keys, for environment variables, and for replacements for other non-encrypting Unix commands. Here is a partial list of ones used in this document:

Set up the SSH environment

User_id: mst3k 
Computers: localcompA, remotecompB
Input; commands & output

• Run the command ssh-keygen to set up the directory, $HOME/.ssh2, in which your public and private keys are stored. Two keys are generated: id_dsa_1024_a is your private key, and id_dsa_1024_a.pub is your public key. They have been renamed to make them more identifiable.

• Using your favorite editor, create files in your .ssh2 directory with names identification and authorization. The contents of each are displayed below:  

• Use scp to copy the public key to any computers you might access from the localcompA computer, here, to remotecompB (note: command in red is typed as one line). 

SSH Communication 

• I must be able to trust your computer
• You must be able to trust mine
• My computer must be able to trust that I am who I say I am (identification)
• Your computer must know that I am recommended as a remote user (authorization)
• Our computers must be able to exchange "scrambled" information (session key)

With these mechanisms in place, it becomes virtually impossible for anyone to "read" the information we exchange. Notice that "password" was not mentioned in the conditions above.

• Machine you ssh from must have the private key in .ssh2/identification
• Machine you ssh to must have the public key in .ssh2 on remote computer

and an entry in its .ssh2/authorization file that names that key. 

    NOTES:
             
    "A" is a computer
             
    mst3k has account on ComputerA
     & .ssh2/ directory contains:
             
    identification - name of file
     that lists filenames of mst3k's
     private keys, e.g.
             
       mst3k_on_A  (secret to A)
             
    authorization - name of file 
     that lists filenames of public
     keys allowed by mst3k, e.g.
             
       mst3k_on_B.pub
             
    hostkeys/ - subdirectory on (A) 
     that contains public keys for
     computers accepted by A: names
     are Key_port#_machineName
             
    ----------------------------
    ----------------------------
    Run ssh-agent - starts ssh process
             
    Run ssh-add - gives mst3k_on_A 
      to agent - requires passphrase
    ----------------------------
             
    Run command on B via ssh:
     'ssh address(B) -l mst3k DO_THIS'
             
      
       
    A and B exchange "sessionKey" <--
             
    A sends command "mst3k DO_THIS"
       encrypted by sessionKey ----->
             
             
             
             
    Result received and decrypted 
         using sessionKey 
             
    Tasks completed:
      erase "sessionKey"
      & disconnect from B 

How SSH2 Protects Accounts

First, SSH uses an encryption technique that does not require the transfer of passwords between accounts. Using a Public Key Infrastructure (PKI), SSH generates and employs a public/private key-pair to identify a user to an account and to allow other users access to the account. Keep in mind that one's public and private keys are inverses of one another - encrypt, then decrypt and you get back the original string.

Your Private Key is yours only. Do not share this with anyone else. It should remain on the computer that generated it, unless you have good reason to copy it to another account. You'll know how and why in that case.

Your Public Key may be given to anyone who is willing to accept it. If you accept someone's Public Key, reference it by name in your authorization file, and keep a file by that name in your .ssh2 subdirectory, you are trusting the person to roam around your account, as if s/he were you. Be careful about accepting and using an SSH Public Key in this way.

How does this PKI verification work? Let's say that you trust me to access your account. I give you my Public Key that was created on the computer I use on a daily basis. You put this file into your .ssh2 directory and add the name of the file to the list in your authorization file there. When I want to work in your account from my computer, I can do so using the following steps:

• Beginning on my own computer, I run ssh-agent to create a process act on my behalf.
• Next I run ssh-add, which means I give the agent my Private Key and it is added to the agent's list.
• Before ssh-agent will accept my Private Key however, I must supply the passphrase that goes with it. If I could not supply the passphrase, the ssh-agent would refuse to take my Private Key. Assume my identification succeeded.
• Now I issue an SSH command on my computer (localcompA) asking that yours (remotecompB) run this command from your account (-l your_user_id) there.
  
  What happens?
  
  
• The computers contact one another and "prove" their identities. Do I have a public key in my .ssh2/hostkeys subdirectory that is from your computer. If there is, fine; if not, I can only continue if I'll accept one, and store it in my .ssh2/hostkeys subdirectory.
• Our computers exchange a symmetric (used for both encryption and decryption) Session Key to use for encryption during this session.
• Your computer needs to authorize me and sends a challenge to my computer. The challenge is encrypted using your authorized public keys (followed by the Session Key) until the following occurs ...
• My computer decrypts the message using the Session Key, then decrypts the result with my Private Key. The result is encrypted using the Session Key before sending it back to your computer.
• Your computer decrypts the returned message, and if it is the same as your original challenge, your computer authorizes me and mine - we must have had a matching Private Key. If no returned message were the same as the original, the game's over and your computer would refuse my access. Assume we're authorized ...
• Our computers will now encrypt and decrypt all exchanges using the Session Key.
• My computer is satisfied with my identification (I gave the correct passphrase), so it uses the Session Key to encrypt my command and sends it to your computer - to be run as if you were giving the command there.
• Your computer has authorized me to run commands remotely, so it decrypts the message, runs the command in your home directory, encrypts the result using the Session Key, and sends it back to me.

The interchange may be continued as long as the agent process runs. The ssh-agent can hold additional private keys, enabling the process to be used by more than one identifiable user.

A schematic of this process can be viewed by clicking here.

Example With Output

Note: Before using ssh commands from localcompA to remotecompB, start the SSH agent process and export the environment variables it generates for you (use copy & paste).  Run ssh-add to associate your private key with the ssh-agent process. For options, see the manpages for ssh-agent and ssh-add.

Note: When you go to a remote computer for the first time, you will be asked if you wish to accept its public key. The keyfiles from hosts you have used before
(see ) are stored in the directory $HOME/.ssh2/hostkeys. In the example below mst3k requests a listing of files in her .ssh2/hostkeys directory on the remote computer B.

Note: The above listing was on remotecompB for mst3k's account.  mst3k's .ssh2 directory on localcompA is different (see below). The user2.pub entry above (on remotecompB) enables user2 to run commands anywhere in mst3k's account on remotecompB. mst3k has allowed this by accepting user2's public key. By contrast, in the example below only user1 might be able to run commands in mst3k's account on localcompA.  An aside ... note that the files in the hostkeys subdirectory show that mst3k has used ssh to connect with remotecompB and anothercompC.

Note: In the following example, mst3k requests a long listing of the entries in user1's .ssh directory. It is no surprise to see that mst3k's public key has been given to & accepted by user1 and referenced in user1's authorization file.

WWW References

JTAN() - links to applications of SSH for Windows, SecureCRT, SSH for NT and the Palm Pilot: 
http://www.jtan.com/resources/ssh.html

SSH Communications Security: 
http://www.ssh.fi/

The SSH Frequently Asked Questions (FAQ): 
http://www.onsight.com/faq/ssh/ssh-faq.html

NiftyTelnet for the Macintosh: 
http://www.lysator.liu.se/~jonasw/freeware/niftyssh/

Links2Go:  the most commonly cited pages for SSH
http://www.links2go.com/topic/SSH

to ITC Security