Stanford Linear Accelerator Center

SSH Frequently Asked Questions

SLAC Computing
UNIX at SLAC
SSH at SLAC
Updated: October 1, 2007


Q1 Why does my SSH session hang when I try to logoff?

If you login to a host via SSH, start a process in the background, and then try to logoff leaving the background process running, your logout may hang unless the background process has:

(Some older versions of SSH ignored the latter issue and would exit despite having open file descriptors associated with the pseudo terminal.)

You can force a disconnect by typing the SSH escape sequence, "~." (note that all SSH escape sequence must be entered immediately following a CR). This will break any open X connections and kill the background process.

Programs that are intended to run as daemons normally take care of redirecting their own STDxxx file descriptors. If you need to leave the background process running, you should do something like this (for csh/tcsh users):


     some-command </dev/null >&/dev/null &
     exit

The syntax for Bourne/Korn/BASH shell users is slightly different:


     some-command </dev/null >/dev/null 2>&1 &
     exit
If the background process

To launch a background process on another host from a script, you could do something like this (assuming your default shell is csh or tcsh):


     ssh -x some-host some-command '</dev/null >&/dev/null &'

Q2 Why do the host keys for SLAC's public machines keep changing?

SLAC provides several different pools of public login machines, each of which should normally be accessed via a generic name, e.g., "flora", so that a load-balancing name server can assign the least busy machine. However, each of the machines within one of these pools has a different host key, so unless some extra steps are taken, SSH will complain that the host key for "flora", say, has changed when you happen to be assigned to a different member of the flora pool.

This is not a problem for most machines at SLAC, since we automatically maintain a master known_hosts file with the proper aliases for all of these pool machines. Users logging in from offsite can avoid the problem by downloading a subset of this master file from:



ftp://ftp.slac.stanford.edu/admin/known_hosts

You should merge that file with your $HOME/.ssh/known_hosts file on your non-SLAC machine, replacing any existing entries for these SLAC machines.

Of course, host keys occasionally do change (for example, if we add machines to one of the pools) so you may need to download a fresh copy of this file from time to time.

Q3 Why do I get a long delay and a "timeout" warning message?

This usually indicates an AFS token problem.

Although you can always use the kinit command later in your session to obtain a token, there are only two ways to make sure you have one at this point in the SSH connection setup:

  1. use your AFS password to authenticate your connection so that you automatically get a fresh token during login; or
  2. obtain a kerberos ticket on the originating host and arrange for SSH to forward it to the target host.See the main ssh page.

Because of the above considerations, we recommend that most users should not set up a password-less (i.e., public-key-base) authentication method for their offsite-to-SLAC connection. You don't really lose much convenience, since to do anything useful you would almost always have to run the kinit command and type your password anyway. On most recent Linux and OS X systems it should be possible to run kinit on the remote system and ssh into SLAC w/o a password. See the main ssh page.

If you see this delay and warning message when connecting between two SLAC nodes, it probably indicates that your ticket granting ticket on the originating host has expired. Issue the kinit command and try again.

Q4 Why does my connection from home keep timing out?

From time to time users report that SSH connections from their home machines to SLAC servers suffer repeated, apparently spontaneous, disconnects. These disconnects are usually preceded by at least a few (~10) minutes of inactivity. SLAC systems do not currently impose any such inactivity timeout. We think these disconnects are most likely due to one of the following:

  1. Firewall or NAT software running on the home machine
  2. Firewall or NAT software running on the home DSL or cable router
  3. Some sort of inactivity timeout imposed by your ISP
  4. Problems with your DSL line or cable

For the first two cases, check the manual to see if there is any discussion of such an inactivity timeout and, if so, if there is some way to turn it off or to change the timeout period. For the second two cases, you'll need to contact technical support at your ISP or DSL/cable provider.


Len Moss