Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint

Recipe 4.14. Using Kerberos with SSH

4.14.1. Problem

You want to authenticate to your SSH server via Kerberos-5. We assume you already have an MIT Kerberos-5 infrastructure. [Recipe 4.11]

4.14.2. Solution

Suppose your SSH server and client machines are myserver and myclient, respectively:

  1. Make sure your OpenSSH distribution is compiled with Kerberos-5 support on both myserver and myclient. The Red Hat OpenSSH distribution comes this way, but if you're building your own, use:

    $ ./configure --with-kerberos5 ...

    before building and installing OpenSSH.

  2. Configure the SSH server on myserver:

    /etc/ssh/sshd_config:
    KerberosAuthentication yes
    KerberosTicketCleanup yes

    Decide whether you want sshd to fall back to ordinary password authentication if Kerberos authentication fails:

    KerberosOrLocalPasswd [yes|no]

  3. Restart the SSH server:

    myserver# /etc/init.d/sshd restart

  4. On myclient, obtain a ticket-granting ticket if you have not already done so, and connect to myserver via SSH. Kerberos-based authentication should occur.

    myclient$ kinit
    Password for username@REALM: ********
    
    myclient$ ssh -1 myserver                     That's the number one, not a lower-case L
    
    					  

4.14.3. Discussion

We use the older SSH-1 protocol:

$ ssh -1 kdc

because OpenSSH supports Kerberos-5 only for SSH-1. This is not ideal, as SSH-1 is deprecated for its known security weaknesses, but SSH-2 has no standard support for Kerberos yet. However, there is a proposal to add it via GSSAPI (Generic Security Services Application Programming Interface, RFC 1964). A set of patches for OpenSSH implements this authentication mechanism, and is available from http://www.sxw.org.uk/computing/patches/openssh.html.

Continuing with our example using the built-in SSH-1 Kerberos support: if all works properly, ssh should log you in automatically without a password. Add the -v option to see more diagnostics:

$ ssh -1v myserver
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /home/res/.ssh/config
...
debug1: Trying Kerberos v5 authentication.
debug1: Kerberos v5 authentication accepted.
...

confirming the use of Kerberos authentication. You can also see the new "host/hostname" ticket acquired for the connection:

$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: pat@DOGOOD.ORG

Valid starting     Expires            Service principal
03/05/03 03:48:35  03/05/03 13:48:35  krbtgt/DOGOOD.ORG@DOGOOD.ORG
03/05/03 06:19:10  03/05/03 15:55:06  host/myserver.dogood.org@DOGOOD.ORG
...

If Kerberos for SSH doesn't work, test it using the SSH server debug mode. In one window, run a test server on an alternate port (here 1234) in debug mode:

myserver# sshd -d -p 1234

and in another, connect with the client to the test server:

myclient$ ssh -v1p 1234 myserver

See if any enlightening diagnostic messages pop up on either side—you can increase the verbosity of the logging by repeating the -d and -v switches up to three times. If sshd reports "incorrect net address," try adding ListenAddress statements to /etc/ssh/sshd_config, explicitly listing the addresses on which you want the SSH server to listen; this can work around a bug in the handling of IPv4-in-IPv6 addresses, if your system has IPv6 enabled.

Note that if you use the same host as both client and server, you cannot use localhost instead of the hostname on the ssh command line. For Kerberos authentication, the SSH client requests a ticket for the host login service on the server; it does that by name, and there is no "localhost" principal (host/localhost.dogood.org@DOGOOD.ORG) in the KDC database. There couldn't be, because the database is global, whereas "localhost" means something different on every host.

If your Kerberos server is also an Andrew Filesystem kaserver, enable KerberosTgtPassing in /etc/ssh/sshd_config:

KerberosTgtPassing yes

If you want to allow someone else to log into your account via Kerberos, you can add their Kerberos principal to your ~/.k5login file. Be sure to also add your own as well if you create this file, since otherwise you will be unable to access your own account!

~/.k5login:
me@REALM
myfriend@REALM

4.14.4. See Also

sshd(8), sshd_config(5), kinit(1). OpenSSH also has support for Kerberos-4.

  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint