Kerberos/GSSAPI Support in OpenSSH

OpenSSH now contains support out of the box for GSSAPI user authentication using the 'gssapi-with-mic' mechanism. If you're running a small site, and looking to deploy Kerberos from scratch, this will probably be all that you need.

Larger sites may find the key exchange patch below useful. Using GSSAPI key exchange allows you to leverage an existing key management infrastructure such as Kerberos or GSI, instead of having to distribute ssh host keys throughout your organisation. With GSSAPI key exchange servers do not need ssh host keys when being accessed by clients with valid credentials.

Key exchange

This patch adds support for doing GSSAPI key exchange (and user authentication based on the results of that exchange) to OpenSSH. It extends the current GSSAPI support in OpenSSH to perform server (as well as user) authentication through GSSAPI, therefore removing the need for maintaining site-wide maps of ssh host keys*

* Whilst you can get away without generating host keys at all with this patch, to do this safely you will have to be able to ensure both that your clients will only be performing GSSAPI authenticated connections and that clients will have valid credentials when rekeying occurs.

As of the patch for 5.2p1 support for cascading credentials is included as standard (see below for details)

The GSSAPI extensions to OpenSSH are now managed via a github repository. from which the following patches are extracted.

Patch for OpenSSH 5.7p1 (updated 2011-01-25)

Older patches...

Patch for OpenSSH 5.6p1 (updated 2011-01-01)
Patch for OpenSSH 5.3p1 (updated 2010-01-24)
Patch for OpenSSH 5.3p1 without cascading credentials (updated 2010-01-23)
Patch for OpenSSH 5.2p1 (updated 2009-07-26)
Patch for OpenSSH 5.2p1 without cascading credentials (updated 2009-07-26)
Patch for OpenSSH 5.0p1 (updated 2008-04-04)
Patch for OpenSSH 4.7p1 (updated 2007-09-27)
Patch for OpenSSH 4.6p1 (updated 2007-03-12)
Patch for OpenSSH 4.5p1 (updated 2006-12-20)
Patch for OpenSSH 4.4p1 (updated 2006-10-02)
Patch for OpenSSH 4.3p2 (updated 2006-02-23)
Patch for OpenSSH 4.2p1

Cascading Credentials

Cascading Credentials support allows credentials provided via key exchange to be propagated through a set of ssh connections. When a user reauthenticates to their workstation, the new credentials become available on all machines to which they are currently connected. Checks are made to ensure that credentials are only propagated when the new credentials match the old ones on the originating machines, and where the receiving machine still has the old set in its cache.

The cascading credentials behaviour is controlled via two new options.

GssapiRenewalForcesRekey
This client side boolean option makes the client check if the credentials in its cache have changed, and forces a rekey with the server when they have. This rekey transmits the new credentials to the server.
GssapiStoreCredentialsOnRekey
This boolean server option controls whether the server will save out credentials that it receives on a rekey operation.
In addition, a new PAM stack sshd-rekey is available. The setcred section of the auth stack will be run following a rekey operation - this permits the regeneration of things like AFS tokens, or X509 certificates when a new key arrives.

Acknowledgements

Fixes and suggestions have been provided by Jeffrey Altman, Love Hornquist Astrand, Jim Basney, Derrick J Brashear, Chris Chiappa, Nalin Dahyabhai, Douglas E Engert, Bill Fithen, Sam Hartman, John Hawkinson, Greg Hudson, Karsten Huneycutt, John Kilburg, Daniel Kouril, David Leonard, Dan Russell, Vern Staats, Von Welch, Nicolas Williams and Colin Watson.