Using SSH in the NCSA Environment

Summary

From the man pages:: SSH (Secure SHell) is a program for logging into a remote machine and for executing commands in a remote machine. It is intended to replace rlogin and rsh, and provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel.

If you are interested in more of the details of what ssh does and how it works you can look at the OpenSSH Home Page or the SSH Home Page. The purpose of this document is to explain how we have set up OpenSSH in the NCSA environment, and using it.

Version of SSH at NCSA

How SSH is set up at NCSA

Getting access to the SSH client for Linux/Unix hosts

Using SSH

Version of SSH at NCSA

NCSA is now using OpenSSH center wide. The version we use has patches applied to it that allow kerberos authentication via password or ticket passing over both protocol 1 and protocol 2. OpenSSH clients v3.9 or newer will do kerberos ticket passing without any of our additional patches.

How SSH is set up at NCSA

We have made a few modifications to the OpenSSH source code so that it is more compatible within the NCSA environment. The modifications had to do with integrating it with our current AFS/Kerberos 5 environment. Kerberos 5 ticket forwarding and authentication is provided in the standard OpenSSH distribution since v3.9 and we've added support for easlier versions. We've also added the ability to get an AFS token when a ticket is forwarded, or if a user authenticates via their Kerberos password.

We have installed the ssh server (sshd) on many machines at NCSA, so you can refer to the authentications methods below to connect to an NCSA machine. If a machine you need to access does not appear to have ssh running, then let us know and we can see about setting up SSH on the machine. If you want to set up the ssh server on your machine, then refer to the installation pages from the main NCSA SSH page.

Getting access to the SSH client for Linux/Unix Hosts

There are a few ways to get access to the ssh client. If you are currently on an NCSA machine, and the machine is running the AFS client, all of the ssh client binaries are located in the /usr/ncsa/bin directory. If this does not exist on your machine then email us and we can let you know how to set this up.

If your machine is not in NCSA environment, or you are not running AFS, you can retrieve the ssh client from our Client Binary download page. You will need to have an NCSA account which is used to authenticate you when retrieving the binaries. Windows clients can refer to the note below on how to get access.

The last method is to obtain the source from the OpenSSH Home Page and build the client on your own.

Using SSH

There are several methods for authenticating a user to a remote machine with ssh. Here are the methods we allow at NCSA (in order of preference):

Kerberos 5 authentication

Password authentication

RSA based authentication

Kerberos 5 authentication

Kerberos 5 authentication is the preferred method of authentication at NCSA. If you have a valid Kerberos 5 ticket and are using the ssh clients we distribute, or out of AFS, it will use this method to authenticate you. You should not have to type in your password, the ssh client forwards your Kerberos ticket which is used for authentication. If you have questions on how to determine if you have a valid ticket, or how get a valid ticket, then please refer to the Kerberos documentation.

Note: This is not the case with the current windows clients. For windows clients you will need to use password authentication or RSA based authentication.

Password authentication

This is the next method of authentication that should be used if Kerberos authentication is not possible. When using password authentication the ssh client works like rlogin. When connecting to the server it will prompt you for your password. At this point ssh has already established an encrypted channel, so when you type in your password, it is not in the clear. You should use your Kerberos(/AFS) password. The ssh server will authenticate you via Kerberos 5, and if successful it will get a Kerberos ticket and an AFS token. You do not need to do anything to set up password authentication, if you are not using Kerberos or RSA authentication it will automatically prompt you for your password.

Note:

If ssh was not able to establish an encrypted channel it will warn you before you type in your password. DO NOT TYPE YOUR PASSWORD IN THE CLEAR, please notify us and we can determine why it was not able to encrypt the channel.

If you already have RSA authentication set up you will not be able to use password authentication. SSH tries Kerberos, then RSA, then password authentication. You will need to move your identity key or take it out of your authorized_keys file.

RSA based authentication

This is the last method of authentication that we allow at NCSA. If none of the above solutions work, you can use RSA based authentication. However, when using RSA authentication, the machine you are connecting to will not have a valid Kerberos ticket or AFS token. Here is a description on how to set up RSA authentication at NCSA.

The first thing a user needs to do is to create a RSA key pair by running ssh-keygen. This will automatically create a public and private key pair and store them in ~/.ssh/id_rsa.pub (public key) and ~/.ssh/id_rsa (private key). Ssh needs to be able to read the ~/.ssh/id_rsa.pub file without any afs tokens. But you do not want anybody to be able to look at your private key (~/.ssh/id_rsa).

When creating your keys it will prompt you for a pass phrase. If you do not type in a pass phrase ssh will not prompt you for it when connecting to a remote host (similar to rsh). However, in this setup your security for logging in is only as secure as your private key is. This also causes a problem in our AFS environment because your identity key will then be sent from the AFS file server to your machine in the clear (AFS does not do any encryption from the file server to the client). I describe a couple of ways to store your identity key. First is if you decide to store it in your AFS home directory, and second is if you store your key on local disk.

Storing identity key in AFS:
If you store your identity key anywhere in AFS the first thing you will want to do is make sure you enter a pass phrase when creating your key. If you didn't enter a pass phrase when you first created your key pair, run the command ssh-keygen -p, which will change your pass phrase. Once this is done you will want to move your identity key to a location so that only you have access to it. A method for doing this is to create a private directory in your ~/.ssh directory.

  % mkdir ~/.ssh/private

Then set the acl for that directory so that only you have access

  % fs sa ~/.ssh/private system none
  % fs sa ~/.ssh/private system:anyuser none

The only members on that acl should be yourself and system:administrators.

Then move your identity file to that directory and create a link to it from your ~.ssh directory.

  % cd ~/.ssh
  % mv id_rsa private/id_rsa
  % ln -s private/id_rsa id_rsa

Just make sure that wherever you store your identity key, only you have access to that directory. You can then either create a link to the ~/.ssh directory, or set the IdentityFile variable in your ~/.ssh/config file (read the ssh man pages for information on the config file).

Again, you need to have a pass phrase for your key pair in this setup. The reason for this is so your identity key is encrypted with your pass phrase. Then when the AFS file server sends your identity key to your client it is not "in the clear" which is the whole reason for using ssh in the first place, so no passwords or authorizations get sent in the clear.

Storing your identity key on local disk:
This is the only recommended way of storing your identity key when it doesn't have a pass phrase on it (assuming the correct precautions have been followed in securing your key on the local disk). The drawback is this method will only work if you are connecting to remote machines from your own local machine where the private key is stored.

Copy the identity file to local disk on your machine. Make sure it is setup so that you only have access to it. Now create a link to the identity file from afs:

  % ln -s /<local disk path>/id_rsa /afs/ncsa/user/<username>/.ssh/id_rsa

In this setup, the only way to get access to your private key is if you are on your local system. This scenario will not work if you are planning on connecting to remote hosts from multiple machines. If you wanted to store the identity file on local disk on multiple machines then you should probably create multiple key pairs for each machine and have all the public keys for them listed in your ~/.ssh/authorized_keys file.

Just make sure that wherever you store your identity key on local disk, only you have access to that file. You can then either create a link to the ~/.ssh directory, or set the IdentityFile variable in your ~/.ssh/config file (refer to the ssh man pages for information on the config file).

Additional setup:
Once you have your identity key secured, you will want to set up access to your ~/.ssh directory so that your identity.pub file can be read. Set the .ssh directory acl to system rl so it can be read without a token.

  % fs sa ~/.ssh system rl

Next you need to get a copy of your id_rsa.pub file into the ~/.ssh/authorized_keys file. This can be done by copying it if the authorized_keys file does not exist:

  % cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys

or you can append it to the current authorized_keys file:

  % cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Note: The ~/.ssh/authorized_keys file should have the the following mode bit settings:

  % chmod 600 ~/.ssh/authorized_keys

It cannot have group write, even if it is in AFS.

At this point you are ready to use SSH. There is one more step you will want to do after you run SSH for the first time.

Last step:
When you run SSH for the first time it creates a ~/.ssh/random_seed file. You will want to store this in your ~/.ssh/private directory (or on local disk) along with your identity file.

  % mv random_seed private/random_seed
  % ln -s private/random_seed random_seed

If you have questions on your setup, or any of the steps above, then email us. You can customize your ssh environment by modifying your ~/.ssh/config file. Refer to the ssh man page for these settings. If there is no config file it will use the default settings. Here is an example of a config file. All lines are commented out and set to the default values or nothing.