It has been reported that Kerberos/GSSAPI authentication does not work with multihomed hosts (see URL). (To be clear: I don't use Kerberos and I can't judge the merit of the patch in the URL. I'm creating this bug so it can be tracked.)
Created attachment 715 [details] Add an option to select the gss_import hostname This is a patch for version 3.9p1 and allows a new sshd configuration option #GSSAPIImportHostname hostname #GSSAPIImportHostname connection-ip #GSSAPIImportHostname gss-c-no-name hostname is the default setting. This should allow sshd to work on multihomed systems.
I'd rather see us move towards just using GSS_C_NO_NAME as the acceptor credential. However, library support for this is still emerging. [Sorry for the bad formatting of this, and my previous bug posts ...]
Created attachment 1182 [details] Add new option to allow better operation on multi-homed hosts This fix takes advantage of recent movements in both Heimdal and MIT Kerberos to support the use of GSS_C_NO_CREDENTIALS to indicate that any credential in the default keytab may be used to accept connections on a multi-homed host. The attached patch adds a new option, 'GSSAPIStrictAcceptorCheck', which defaults to 'yes'. If it is disabled, then GSS_C_NO_CREDENTIALS is used instead of the default acceptor credential. This relies on the system administrator only having trusted server keys in /etc/krb5.keytab - but if they haven't, they've lost anyway. Note that this patch needs to be applied after the code tidy up patch in bug #1225
What are the risks to a server of having this option enabled?
I don't see any additional risk to the server. Markus
The potential risk (with my patch, which is the correct way to implement this with modern Kerberos libraries) is that it allows any principal contained within the system keytab to be used, rather than just the host/hostname one. However, Kerberos administrators already have to ensure that principals contained within the system keytab have the same, high, level of trust ascribed to them, so I don't believe that there is any practical increase in risk caused by applying this patch. Simon.
Is there any movement in one direction or another on this patch?
only changes to portable OpenSSH are being considered for 5.3 at this stage.
Created attachment 1775 [details] sshd-gssapi-multihomed.patch I updated patch #1182 to OpenBSD current and fixed a few minor whitespace things. I also removed this warning from the man page: +Note that this option applies only to protocol version 2 GSSAPI connections, +and setting it to +.Dq no +may only work with recent Kerberos GSSAPI libraries. We would probably want to add that back in Portable.
*** Bug 1650 has been marked as a duplicate of this bug. ***
Sorry, this had dropped off my radar. I'll try and take a look at the patch soon.
We are freezing for the OpenSSH 5.6 release. Retargetting these bugs to the next release.
Targetting OpenSSH 5.7
Retarget unclosed bugs from 5.7=>5.8
+1 on this, very useful for boxes behind a load balancer sharing a common dns name and host principal. Any idea if/when it might get applied?
Retarget unresolved bugs/features to 6.0 release
Retarget unresolved bugs/features to 6.0 release (try again - bugzilla's "change several" isn't)
Retarget from 6.0 to 6.1
Retarget 6.0 => 6.1
Any chance getting this to 6.1 or 6.2?
Retarget uncompleted bugs from 6.1 => 6.2
Retarget bugs from 6.1 => 6.2
retarget to openssh-6.3
This bug's been open over 8 years 8-/. Is there an objection to applying the patch, or?
Good Morning, Apart of be very useful for systems behind load balancers, this patch is needed for High Availability Clusters. We can not use Kerberos / GSSAPI without this patch in place and also it is very useful for Kerberos authentication and SSO. Thanks, Jose Luist
MIT Krb5 v1.10 has an option [libdefaults] ignore_acceptor_hostname, which achieves the same functionality for all services using GSSAPI.
Hi, We are using IBM NAS Kerberos implementation. It is a MIT derived version unfortunatelly not upgraded to this MIT version. Anyway have you tried it? I have dealed with this issue several years ago and I have to review it but I think that it is sshd whot is not accepting it. The Kerveros server side is reponsible to check the user credentials not the underlying Kerberos software. Sshd adds a extra check denying (almost in our case) access to the users who has not the hostname kerberos principal ticket. Thanks for your response. José Luis
Retarget to openssh-6.4
Retarget 6.3 -> 6.4
Retarget incomplete bugs / feature requests to 6.6 release
Retarget to 6.7 release, since 6.6 was mostly bugfixing.
Remove from 6.6 tracking bug
Retarget incomplete bugs to 6.8 release.
These bugs are no longer targeted at the imminent 6.7 release
OpenSSH 6.8 is approaching release and closed for major work. Retarget these bugs for the next release.
Retarget to 6.9
Created attachment 2571 [details] openssh-6.8_p1-sshd-gssapi-multihomed.patch
applied (at last). will be in openssh-6.9
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1