Using GSSAPI authentication at SLAC

Contents

• From one SLAC machine to another
• From offsite machines to SLAC machines.

What is GSSAPI Authentication?

GSSAPI is a IETF standard for doing strong encrypted authentication in network based applications. OPENssh uses this API and the underlying kerberos 5 code to provide a alternative means of authentication other than ssh_keys.

Protocols in use at SLAC

Only ssh V2 connections are allowed on SLAC taylored machines and GSSAPI authentication will only work over V2 Connections.

Using SSH and GSSAPI

Between UNIX machines at SLAC

All SLAC taylored machines are configured to allow you to use GSSAPI authentication by default. There are some initial setup of configuration files that are done by the wrapper script for ssh in /usr/local/bin/ssh in AFS. If you are not using that ssh by default, running it once will setup your AFS home directory correctly.

To enable password-less access to a SLAC machine, these are the steps required.

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
   

2. Enable GSSAPI authentication and credential forwarding. At SLAC, this is on by default for all taylored machines. If your machine is not taylored, add the following to 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.
   

From a non-SLAC machine to SLAC machines

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 in your SLAC home directory, you can then use

   kinit userid@SLAC.STANFORD.EDU
   ssh userid@machine.slac.stanford.edu

In order for you to obtain an AFS token when sshing in w/o a password, you must obtain an forwardable ticket when you kinit. On some OS's this is the default, check the file /etc/krb5.conf for the option

[libdefaults]
 forwardable = true
                    

Problems and Workarounds

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

• Some versions of ssh (in particular OS X Snow Leopard ) also require the option

  							
  							
  			GSSAPITrustDNS yes
  			# Set to ``yes'' to indicate that the DNS is trusted to securely canonicalize the name of the
  			# host being connected to. If ``no'', the hostname entered on the command line will be passed
  		    # untouched to the GSSAPI library.  The default is ``no''.  This option only applies to protocol
  			# version 2 connections using GSSAPI.
  

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

   
          prompt: 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

OpenSSH Manual Pages

SSH information elsewhere

• OpenSSH home page
• OpenSSH FAQ