[ Team LiB ] |
Recipe 4.14 Using Kerberos with SSH4.14.1 ProblemYou 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 SolutionSuppose your SSH server and client machines are myserver and myclient, respectively:
4.14.3 DiscussionWe 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: [email protected] Valid starting Expires Service principal 03/05/03 03:48:35 03/05/03 13:48:35 krbtgt/[email protected] 03/05/03 06:19:10 03/05/03 15:55:06 host/[email protected] ... 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/[email protected]) 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 Alsosshd(8), sshd_config(5), kinit(1). OpenSSH also has support for Kerberos-4. |
[ Team LiB ] |