-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm pleased to (finally) announce the availability of my GSSAPI Key Exchange patch for OpenSSH 4.7p1. Whilst OpenSSH contains support for doing GSSAPI user authentication, this only allows the underlying security mechanism to authenticate the user to the server, and continues to use SSH host keys to authenticate the server to the user. For many sites who already have security infrastructures such as Kerberos deployed, managing large numbers of SSH host keys is an additional, unneccessary, burden. GSSAPI key exchange allows the use of security mechanisms such as Kerberos to authenticate the server to the user, removing the need for trusted ssh host keys, and allowing the use of a single security architecture. This patch adds support for the RFC4462 GSSAPI key exchange mechanisms to OpenSSH, along with adding some additional features to the GSSAPI code that is already in the tree. The patch implements: *) gss-group1-sha1-*, gss-group14-sha1-* and gss-gex-sha1-* key exchange mechanisms. (#1242) *) Support for the null host key type (#1242) *) Support for CCAPI credentials caches on Mac OS X (#1245) *) Support for better error handling when an authentication exchange fails due to server misconfiguration (#1244) *) Support for GSSAPI connections to hosts behind a round-robin load balancer (#1008) *) Support for GSSAPI connections to multi-homed hosts, where each interface has a unique name (#928) (bugzilla.mindrot.org bug numbers are in brackets) There are no code changes since the previous release. As usual, the code is available from http://www.sxw.org.uk/computing/patches/openssh.html I'm also interesting in hearing from people who might be interested in testing some new cascading credentials delegation code. When you renew your Kerberos credentials on the client, this code will automatically propagate these renewed credentials to the server, allowing the seamless renewal of credentials across ssh sessions distributed across many different machines. If you have an interest in testing this code in a non-production environment, please let me know! Cheers, Simon. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFG/CG9qWndc26pXmcRAikbAKDLw84hjqy2Z4dF6/H4ZmK6/gY4XwCffEWm FQleDwIuPJI8sJQ/I9SSRDo=RJHh -----END PGP SIGNATURE-----
Simon Wilkinson wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I'm pleased to (finally) announce the availability of my GSSAPI Key > Exchange patch for OpenSSH 4.7p1. Whilst OpenSSH contains support for > doing GSSAPI user authentication, this only allows the underlying > security mechanism to authenticate the user to the server, and > continues to use SSH host keys to authenticate the server to the > user.O-o-o-ops , I'm not familiar with GSS-API but partially support is not a option for an open-source product. [SNIP] Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/
Sounds interesting. And yes, I would be interested in the cascading credentials delegation code. Does the delegation code depend on the key exchange code? What would it take to get both of these in to PuTTY? Simon Wilkinson wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I'm pleased to (finally) announce the availability of my GSSAPI Key > Exchange patch for OpenSSH 4.7p1. Whilst OpenSSH contains support for > doing GSSAPI user authentication, this only allows the underlying > security mechanism to authenticate the user to the server, and > continues to use SSH host keys to authenticate the server to the > user. For many sites who already have security infrastructures such > as Kerberos deployed, managing large numbers of SSH host keys is an > additional, unneccessary, burden. GSSAPI key exchange allows the use > of security mechanisms such as Kerberos to authenticate the server to > the user, removing the need for trusted ssh host keys, and allowing > the use of a single security architecture. > > This patch adds support for the RFC4462 GSSAPI key exchange > mechanisms to OpenSSH, along with adding some additional features to > the GSSAPI code that is already in the tree. > > The patch implements: > *) gss-group1-sha1-*, gss-group14-sha1-* and gss-gex-sha1-* key > exchange mechanisms. (#1242) > *) Support for the null host key type (#1242) > *) Support for CCAPI credentials caches on Mac OS X (#1245) > *) Support for better error handling when an authentication > exchange fails due to server misconfiguration (#1244) > *) Support for GSSAPI connections to hosts behind a round-robin > load balancer (#1008) > *) Support for GSSAPI connections to multi-homed hosts, where each > interface has a unique name (#928) > > (bugzilla.mindrot.org bug numbers are in brackets) > > There are no code changes since the previous release. > > As usual, the code is available from > http://www.sxw.org.uk/computing/patches/openssh.html > > I'm also interesting in hearing from people who might be interested > in testing some new cascading credentials delegation code. When you > renew your Kerberos credentials on the client, this code will > automatically propagate these renewed credentials to the server, > allowing the seamless renewal of credentials across ssh sessions > distributed across many different machines. If you have an interest > in testing this code in a non-production environment, please let me > know! > > Cheers, > > Simon. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > > iD8DBQFG/CG9qWndc26pXmcRAikbAKDLw84hjqy2Z4dF6/H4ZmK6/gY4XwCffEWm > FQleDwIuPJI8sJQ/I9SSRDo> =RJHh > -----END PGP SIGNATURE----- > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > >-- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hmmm.... The cascading credentials code sounds interesting, but raises the practical question of how does one deal with derived credentials. For example some sites configure the pam_session code to use delegated krb5 credentials to acquire additional credentials such as afs tokens, or x509 certificates. Since there would be no new session created, these derived credentials would not get refreshed. I think you'd need some way to hook site specific actions into the refresh activity, and of course that raises the hairy problem whether this refresh activity occurs in the same process, or one of it's descendants where the pam_session was established. In any case I'm interested in the feature, but am trying to think of what other features are needed to take full advantage of it in a number of common environments. - -Matt Andrews Nicolas Williams wrote: | On Fri, Sep 28, 2007 at 04:26:14PM -0500, Douglas E. Engert wrote: |> Sounds interesting. And yes, I would be interested in |> the cascading credentials delegation code. Does the |> delegation code depend on the key exchange code? | | Protocol-wise, yes, it does. | | There's two ways to use the GSS-API in SSHv2: | | - userauth only, but this happens once at the start of the session, so | you can't delegate credentials after that | | - key exchange (and optionally userauth), which can be done again and | again over the lifetime of the session | | Nico -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHyMVcpLF3UzlwZVgRAutsAKD7a33FKqROnIzPzXP5hbO6CqXkzgCfezdH G+Fzx1/0z8OwPEgU2WNY+gc=gfd7 -----END PGP SIGNATURE-----
On 1 Mar 2008, at 03:12, Russ Allbery wrote:> Matthew Andrews <matt at slackers.net> writes: > >> Hmmm.... The cascading credentials code sounds interesting, but >> raises >> the practical question of how does one deal with derived credentials. >> > Just re-run the session PAM stack with PAM_REFRESH_CREDS set, the > same as > what a screensaver would do. This does all the right things with > derived > credentials if your PAM modules are properly written.This is exactly what my cascading credentials code for OpenSSH does. It uses an additional PAM stack (so you can set different options than the 'main' ssh PAM stack) which it calls the session layer of whenever credentials are renewed. We use this to renew both AFS tokens, and KX509 certificates. Informatics are now running this code in production. I expect to be making a public release next week. Cheers, Simon.