Using ssh-agent to Securely Scoot Around PSU

Introduction

With all the computers at school, constantly reentering your your user name and password as you move from one machine to the next will quickly become annoying. In this tutorial, we will help you sidestep this hassle with a program called ssh-agent. ssh-agent uses public and private key cryptography to guard your identity by keeping it on the computer you are logged into. It then provides your credentials to all those that demand authentication, such as ssh, sftp, scp, or cvs (when used with ssh as it is at PSU).

The following steps will help you get started with ssh-agent on the computers at PSU. On Windows in the CECS domain (i.e., the Intel lab and computers in EB), you will need to connecting to a UNIX or Linux machine in the CS or ECE network via ssh with PuTTY or another ssh clients first. Once connected, it is helpful to know that SSH-2 is the default protocol and the client software is OpenSSH.

Overall, to use ssh-agent you need to:

• Create a public and private key
• Run ssh-agent
• Load the agent with your private key

• Distribute your public key
• Enable agent forwarding.

Create a Private and Public Key

The public key should probably be created with RSA unless you have a specific reason to use DSA (e.g., a server you intend to connect to requires it). Also, the key should use the SSH-2 protocol. The pass phrase that will be used to decrypt the private key should be at least 10 characters in length, alphanumeric and include punctuation to increase the size of the key space. For example, the following command can be used to create a key that conforms to these recommendations:

chandra.cs.pdx.edu> ssh-keygen -t rsa -C ${USER}@unix.cs.pdx.edu -f ~/.ssh/id_rsa

For more information on these flags and what others are available, see the ssh-keygen(1) man page.

Run ssh-agent

There are two ways to run ssh-agent: in a single shell or by forking a new shell. When ssh-agent is run, it invokes a new agent and prints some environment variables to standard out. The values of these variables are used to facilitate communication between clients and the newly spawned representative.

To run ssh-agent in a single shell, use this command:

chandra.cs.pdx.edu> `ssh-agent`

By using the eval statement, the outputted environment variables SSH_AUTH_SOCK and SSH_AGENT_PID will be set. At this point, every process that inherits the environment of the current shell will make requests to this agent for authentication. If you are a screen user, this would be an ideal time to start a new session because all new screens will inherit the ssh environment variables and be able to authenticate through the new agent (see below, Using ssh-agent with screen, for more information). The one drawback to this method is that the agent needs to be terminated by hand with a command similar to this:

chandra.cs.pdx.edu> `ssh-agent -k` 

Alternatively, there is the subshell method. This command spawns a new shell that sets the needed environment variables and runs in place of the current shell. As a result, when the shell terminates, so does ssh-agent; it will not need to be killed manually as the aforementioned method requires. To invoke ssh-agent with this method, use a command similar to the following:

chandra.cs.pdx.edu> ssh-agent $SHELL 

More information about ssh-agent can be found in the ssh-agent(1) man page.

Run ssh-add to Load Keys

Once you have an agent running, you need to load your private key. It will hold it in memory and use it to authenticate you when demanded to do so. You install keys with a command like this:

chandra.cs.pdx.edu> ssh-add ~/.ssh/id_rsa

chandra.cs.pdx.edu> ssh-add

will ask you for your pass phrase, decrypt the private key, id_rsa, and hold it on your behalf. To confirm that the key is in working order, you can use ssh-add to list all of its keys with the command

chandra.cs.pdx.edu> ssh-add -l			  				

For more information on ssh-add, see the ssh-add(1) man page.

Distributing your Public Key

After creating your keys, you must deploy a copy of your public key to every account you wish to access using the cryptographic key pair. Specifically, you will probably need a key on the CS or ECE networks. Also, if you have a CS account, you will have to deploy a key to the Linux lab as well. The public key belongs in a file called authorized_keys2 which resides in the ~/.ssh directory. To deploy it quickly, use a command such as this:

chandra.cs.pdx.edu> cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys2

chandra.cs.pdx.edu> ssh linux.cs.pdx.edu "cat >> ~/.ssh/authorized_keys2" < ~/.ssh/id_rsa.pub

If you don't have a CS account, the command may look something more like this:

home> ssh ece.pdx.edu "cat >> ~/.ssh/authorized_keys2" < ~/.ssh/id_rsa.pub

Maintaining all these copies of the authorized_keys file can quickly become a pain. To reduce the chore, it is recommended that you put the file in a CVS repository and check it out on each network. This way CVS will help determine if the key is outdated. For instance, if the authorized_keys file in your CS account is modified and you forget until one day when you can't sftp to the Linux lab, you can just ssh over real quick and update it. If the file has been modified there as well, CVS will alert you to the fact and your changes will not be overwritten.

Agent Forwarding

An agent is only useful for authenticating you to the next machine you login to. For example, if you are logged into your machine at home and you ssh to baham.cs, your agent will not accompany you. At that point, if you try to scoot over to wasat.cs, you will have to provide your credentials. This limits an agent's usefulness to the current host unless you enable agent forwarding. Agent forwarding allows clients to converse with an agent running on a remote machine. The process basically works like this:

1. From your home computer (H in the diagram below) you login to baham.cs (B in the figure) by running the command
   

   		home> ssh baham.cs.pdx.edu 
   
   		
   	

2. If ssh-agent forwarding is enabled on H, it asks baham to enable it as well while making the connection.
3. Because sshd on baham allows agent forwarding, the request will be granted.
4. Now, from baham you want to securely copy a file to the tmp directory of wasat were your classmate is working with a command such as this:
   

   		baham.cs.pdx.edu> scp prog.c wasat:/tmp && ssh wasat 'chmod 660 /tmp/prog.c' 
   
   		
   	

5. Because sshd is posing as an agent on baham, the credentials demanded of by wasat will be passed back to the agent running on your machine at home which will use your private key that it has stored in memory on your computer.
6. The response will be forwarded back to baham and then on to wasat were the challenge will be met.

To permit this feature, simple create the ssh client configuration file ~/.ssh/config if it doesn't already exist and add the following line to it:

ForwardAgent yes

Now, when you move from one machine to the next, you won't be alone. Your agent will be there representing you to everyone who may demand proof of identification.

Using ssh-agent with screen

ssh-agent and screen fit together like hand and glove; however, if you use them together incorrectly, they will end up fighting each other until you have no choice but to give up on one or the other.

The most important thing about using these tools together is that they need to be run on the same machine. Otherwise, when you disconnect and later reconnect from a different computer, all requests for authentication will fail because your agent won't be accessible from the new host.

The proper procedure for using these programs together goes something like this:

1. Login to a host that you can connect to from anywhere (e.g., unix.cs or fastunix.ece)
2. Start a new ssh-agent using the single shell method
3. Start a new screen

Now, every new screen will inherit the needed environment variables and you will be able to use your agent continuously from any computer.

For more information about screen, visit any of these Web pages:

• Screen Homepage
• screen (1) man Page
• Official Mailing List
• The Anitdesktop
• ssh-agent forwarding and screen

Conclusion

By using the ssh-agent suite of tools, there is no need to constantly reenter one's credentials every time you need to communicate across the network. With ssh-agent, you can work securely in a disparate environment like PSU. Its use of private and public key cryptography makes it a safe way to login to remote computers. This useful tool is worth learning sooner rather than later.

For more information, you man find these sources and links helpful:

• SSH, The Secure Shell: The Definitive Guide by Daniel Barrett and Richard Silverman