You want to authenticate to your SSH server via Kerberos-5. We assume you already have an MIT Kerberos-5 infrastructure. [Recipe 4.11]
Suppose your SSH server and client machines are myserver and myclient, respectively:
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.
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:
Restart the SSH server:
myserver# /etc/init.d/sshd restart
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
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:
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
sshd(8), sshd_config(5), kinit(1). OpenSSH also has support for Kerberos-4.