ncsa

Version of SSH at NCSA

Note: NCSA is currently working on upgrading to OpenSSH. We hope to have OpenSSH deployed in Spring 2002.

How SSH is set up at NCSA

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

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 SSH Home Page and build the client on your own.

Note for Windows clients:
If you are an University of Illinois/NCSA employee then you can retrieve a copy from the CCSO Software Downloads page. It is under the Site-Licensed section and you will need to know your U of I netid and password (same as NESSIE username and password). This replaces the Data Fellows clients we previously distributed. If you are not a NCSA employee then you can take a look at the free TTSSH client.

Using SSH

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:

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/identity.pub (public key) and ~/.ssh/identity (private key). Ssh needs to be able to read the ~/.ssh/identity.pub file without any afs tokens. But you do not want anybody to be able to look at your private key (~/.ssh/identity).

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

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

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

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

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>/identity /afs/ncsa/user/<username>/.ssh/identity

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

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

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

  % chmod 600 ~/.ssh/authorized_keys

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.