-- Stanford Linear Accelerator Center

The NEW Secure Shell (SSH) at SLAC

UNIX at SLAC Security
Updated: 20 May 2008
--

UPDATE:

SLAC has completed the transition to current versions of OpenSSH and the information on this page is largely out of date. We are keeping a stub page available. Please use this link for the most current information, SSH at SLAC.

Contents

What is the new version of Secure Shell?

What is the new version of Secure Shell?

Previously SLAC used a locally customized version of SSH that supported forwarding AFS tokens during login. Unfortunately, the latest versions of OpenSSH make maintaining these set of patches and keeping our software current very difficult. We have switched to a new version of ssh that supports Kerberos TGT forwarding and using this forwarded ticket to obtain an AFS token at login.

Protocols in use at SLAC

Only ssh V2 connections are allowed on SLAC taylored machines.

Machines for Testing

All SLAC taylored unix machines are using the new verison of SSH.

Using SSH

Between UNIX machines at SLAC

Here is the recommended transition procedure for user that need to access machines with ssh.

If you do not need password-less access, just continue to use the standard SLAC ssh w/username and password.

To enable password-less access to a machine, then use the following steps.

  1. Create a .k5login file in your home directory with this one line (replace "slac_id" with your current id, Realm must be UPPER CASE).
    slac_id@SLAC.STANFORD.EDU

    The default ssh wrapper at SLAC has likely already done this for you.

  2. When you need to connect to a machines from a SLAC maintained machine use the following sequence of commands.
    kinit
    ssh hostname

    If your path is not setup such that ssh resolves to /usr/local/bin/ssh, then you should fix that for the best results. The kinit command only needs to be run once per day. The new version of ssh is installed on all SLAC taylored linux and solaris machines. The version of ssh that comes with OS X is already compatible with this and only needs a minor configuration change.

Between a SLAC machine and a non-SLAC machine

If you are using an ssh client from an outside machine, there is a pretty good chance that with a few configuration changes you will be able to much more seamlessly connect to the new ssh. The key things you need are

  1. Relatively recent versions of both ssh ( 3.8 and higher ) and the kerberos kinit command. OS X Tiger, RHEL 4 and recent versions of Fedora Core all meet this requirement. The ssh client needs to be compiled with GSSAPI libraries.

  2. Turn on GSSAPI options in your ~/.ssh/config file.
     
                        GSSAPIAuthentication yes
                        # Specifies whether user authentication based on GSSAPI is allowed.
                        # The default is ``no''. Note that this option applies to protocol
                        # version 2 only.
                        
                        GSSAPIDelegateCredentials yes
                        ### Forward (delegate) credentials to the server. The default is
                        # ``no''. Note that this option applies to protocol version 2
                        # only.
    
    Using these, once you set up your ~/.k5login file, you can then use
    kinit userid@SLAC.STANFORD.EDU
    ssh userid@machine.slac.stanford.edu

Connecting from a Mac or PC

From a Mac running either Panther or Tiger, you can use the standard tools listed above.

SCCS is currently investigating the options for Windows users, Secure CRT seems your best bet at the moment if you are a SLAC employee and have an sunetid. Recent versions of Putty will do ssh V2.

Problems and Workarounds

If you encounter any problems, please report them to unix-admin@slac.stanford.edu.

  • The output of the tokens command no longer lists the user's AFS id in most cases. The new format looks like

    	
    		>tokens
    
    				Tokens held by the Cache Manager:
    
    				Tokens for afs@slac.stanford.edu [Expires Oct  4 12:08]
    				   --End of list--
    

    Any script that parses the output of tokens needs to be updated to account for the two different possible outputs. In some cases ( after running kinit), you may get the old format. A better solution is to use the program /usr/local/bin/qtoken which correctly identifies the current token, unlike the tokens command which can provide misleading UID data.

  • Realm names must be UPPER case, unlike dns names realm names are case sensitive and by convention are always UPPER case. In both the kinit command line and .k5login file, you must use an upper case realm name.

    kinit userid@SLAC.STANFORD.EDU

  • Shared accounts will need to be handled differently, rather than using the ~/.ssh/authorized_keys file to control access, you will want to use the ~/.k5login file to list the authorized users of the account. The ~/.ssh/authorized_keys method will still continue to work, but you will have to kinit after login to obtain an AFS token. SCCS has created an automated process to allow groups to manage the .k5login file effectively. See this page for more information.

  • X11 forwarding works in a more secure way than may cause problems with older or non-comforming X11 programs. If you notice strange behaviour try using

    ssh -Y

    This reverts ssh to the older X11 forwarding.

  • Only your current k5 tgt will be forwarded and kerberos is generally only setup to deal with one realm/tgt per file. If you have been getting afs tokens in multiple realms and using ssh to forward all those tokens that will no longer work. You can use the KRB5CCNAME environment variable to get tgt's for multiple realms

    env KRB5CCNAME=/tmp/myid_remoterealm kinit myid@REMOTE_REALM

    will get an alternate set of credentials.

  • Some handy ssh tricks

Reference

Man pages for the ssh commands

There are detailed manual pages for each of the primary ssh commands. Use the man command on the UNIX system, or click on the link below to view them.

OpenSSH Manual Pages

SSH information elsewhere


Owner: Booker C. Bense