Simon, I would like to complement you on the excellent GSSAPI mods for OPenSSH-2.9p2. We are currently evaluating them and are awaiting mods for 3.0.2 as well.
We have used ssh-1.2.* with GSSAPI (Kerberos) and native Kerberos support for some time. As you point out, the Kerberos mods to sshv1 are a mess, and I agree that using GSSAPI is a much better way to get Kerberos authentication into ssh, then calling Kerberos directly. The SecureCRT packaged for WIN32 has GSSAPI support for SSHv1 protocol and we have the equivalent mods to ssh-1.2.* These are not standardized. But the SecureCRT developers are active in the IETF, so we expect to see the standards in their product eventually. In the meantime to get away from ssh-1.2.* we need a common Kerberos type method across all the platforms, and so have modified the openssh-2.9p2 GSSAPI mods for sshv2 to also work with the older sshv1 GSSAPI mods, and allow for a transition from ssh-1.2.* to openssh using sshv1, then to openssh sshv2. So I would like to encourage you to update your GSSAPI mods in line with the IETF drafts for openssh-3.0.2. Any idea when these might be available? Thanks. Simon Wilkinson wrote: > > Mathieu Nantel ([EMAIL PROTECTED]) wrote: > : Thanks for the answers. I guess I'll give OpenSSH another try at > : compiling with Kerberos. I've read that the problems I used to have were > : due to the implementation that they did which had functions that were > : only compatible with the Heimdal release. I didn't verify this fact > : though, so if anyone could clarify, that would he a handful. > > The entire ssh (and OpenSSH) with Kerberos history is a little complex. > I'll try and clarify things a bit: > > OpenSSH supports both secure shell protocol version 1 and 2. Protocol version > 1 is that used by the original ssh client, its use is now depreciated due > to a number of design problems, although many sites still rely upon it. The > version 2 protocol is undergoing standardisation within the IETF, and is > a different beast with regard to Kerberisation (and a large number of other > areas, which I won't go into here). > > Kerberos support in protocol version 1 has tread a long and winding path. > Kerberos v4 support has been present in both ssh.com and OpenSSH's code > for a while now. Kerberos v5 support has been available in the ssh.com > codebase for ages, but as it was added after the licence change, OpenSSH > were unable to add it to their release. So, an independent implementation > was required. After a large number of people produced patches with varying > degrees of compatibility with the ssh.com code, OpenSSH added the FreeBSD > implementation to their releases somewhere around 3.0. However, these patches > are Heimdal only, and aren't enable in the portable version. I have produced > patches to add MIT Kerberos support, and to add options to configure to enable > this support. You can view the current state of these patches in the OpenSSH > Bugzilla at http://bugzilla.mindrot.org/show_bug.cgi?id=55. This patch has > not yet been added to the OpenSSH portable codebase. > > There is an additional complication with the protocol 1 Kerberos > support. OpenSSH decided to fix the original ssh.com client's broken > behaviour of sending the TGT before authenticating the user. This has > resulted in a compatibility problem which means that credentials > cannot be passed between ssh.com and OpenSSH clients and servers. I > believe that there is a patch for this also, which enables backwards > compatible behaviour when talking to ssh.com code. This patch has yet > to make it into the OpenSSH codebase. > > So after that, now for the good news - things could be better with v2. > There is a draft in the IETF secure shell working group which > describes a standard means of adding GSSAPI support to ssh protocol 2. > As others have noted, this draft removes the need for host keys when > using GSSAPI to secure the key exchange. I've implemented this draft > for OpenSSH, and it should work with both MIT and Heimdal Kerberos. I'm > eager to hear of progress with SEAM. > > One final dark cloud. ssh.com have implemented Kerberos authentication > for their version 2 product. This uses proprietary message types, which > AFAIK, no one has yet investigated or decoded. OpenSSH with the GSSAPI > patches will not interoperate with these ssh.com messages. > > So, in summary. No version of OpenSSH will work with MIT Kerberos > out of the box for Kerberos v5 support. Patches are available to make it > work with varying degrees of effectiveness. Things are better with > protocol v2 than protocol v1, and hopefully will continue to improve. > > Hope that is of some use! > > Cheers, > > Simon. -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
