SSH Frequently Asked Questions
UNIX at SLAC
SSH at SLAC
|Updated: October 1, 2007|
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:
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:
If the background process
some-command </dev/null >/dev/null 2>&1 & exit
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 &'
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:
file://afs/slac.stanford.edu/public/admin/known_hosts file://afs/slac.stanford.edu/public/admin/known_hosts_dsa file://afs/slac.stanford.edu/public/admin/known_hosts_rsa or ftp://ftp.slac.stanford.edu/admin/known_hosts ftp://ftp.slac.stanford.edu/admin/known_hosts_dsa ftp://ftp.slac.stanford.edu/admin/known_hosts_rsa
For protocol 2, you can use either (or both) of the other two files. No matter what file you download, you should merge it 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.
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:
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.
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:
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.