When connecting to hosts that are accessed via Round Robin DNS (e.g pub.<my.domain> resolves to the ip addresses of pub[1-5].<my.domain>) GSSAPI authentication failes often. That's because the server's address lookup is done twice. First when actually connecting to the server, the second time when determining the host's principal name. If the ssh client gets two different answers here, the authentication failes. On the sshd server the following error message appears in debug mode in this case: debug1: Miscellaneous failure (see text) Decrypt integrity check failed debug1: Got no client credentials On the client I can see that I got a ticket for a different host than the one I'm actually connected to. That's the reason for the error message.
Is that related to bug #928?
(NOTE: this might be a repost as the mail reply ended up with a postix error message: Diagnostic-Code: X-Postfix; unknown user: "bitbucker") (In reply to comment #1) > Is that related to bug #928? I don't think so. If I understand the patch for bug #928 correctly, it solves a problem when hosts have more than one ip address / host name. It's furthermore situated on the server side. My problem is situated on the client side. The ssh client should obtain the kerberos ticket for exactly that host it has connected to. With the current lookup behaviour this is not possible. Round robin dns offers more than one ip address. These addresses belong to hosts that are completely independent from each other, except that they share the same ssh keys (ssh_host_rsa_key et al). Example: [fuchur] ~ % host pub.ifh.de pub.ifh.de is an alias for pub.iss.ifh.de. pub.iss.ifh.de has address 141.34.15.194 pub.iss.ifh.de has address 141.34.1.150 [fuchur] ~ % host pub.ifh.de pub.ifh.de is an alias for pub.iss.ifh.de. pub.iss.ifh.de has address 141.34.1.150 pub.iss.ifh.de has address 141.34.15.194 [fuchur] ~ % Greetings Andreas
a workaround at http://blog.macnews.de/unspecific/stories/4581/
Yes, the client should only do the hostname lookup once (or, in an ideal world, GSSAPI should use the hostname as entered by the user, not what DNS resolves it to!). I'll look into this.
There isn't an easy fix for this, at least with today's GSSAPI libraries. Most of these use the DNS to canonicalize the hostname passed into them - so there's no way of stopping them from resolving it a different way from OpenSSH. Perversely, the only way to fix this is to pass the canonicalized name into the GSSAPI library, rather than the one supplied by the user. Generally, this is a bad idea, but it's the only way to fix this problem. I've got a patch which does this dependent on a configuration variable, if it would be likely to be considered for inclusion.
Created attachment 1177 [details] Add option to do GSSAPI canonicalization in the client, rather than the library Here's the patch. This creates a new configuration directive 'GSSAPITrustDNS', which if set, will cause the ssh client to canonicalize the hostname before passing it to the GSSAPI libraries. As the client caches canonicalization results, this means that the libraries are always called with the hostname that the client is connected to. Whilst GSSAPI libraries perform canonicalization internally, this is the only way of avoiding the GSSAPI picking a different hostname than the ssh client. In the long term, GSSAPI implementations should not be performing canonicalization, and should be using the hostname passed by the user to request service tickets - but this seems a long way off.
Created attachment 1202 [details] (simplified patch - no config option) Given that the GSSAPI library will (unconditionally) use DNS anyway, perhaps we don't need yet another client-side config option? Btw, the old SSH1 Kerberos4/5 authentications used canonical hostnames as well for service tickets.
FYI, we (or our users) are now encouraging distributions (which typically have older OpenSSH releases anyway) to consider adding this patch. SuSE: https://bugzilla.novell.com/show_bug.cgi?id=257034 Debian: http://www.mail-archive.com/debian-ssh@lists.debian.org/msg02727.html RedHat: IssueTracker#107219 please feel free to add more.
I've noted this on the mailing list too, but just for the record, the simplified patch is incorrect. GSSAPI != Kerberos, and even within the Kerberos space, some vendors ship with canonicalisation disabled. If we are going to ship a workaround for this issue (and we should), it has to be configurable, and default to 'off', so users get the current behaviour unless they specifically request that we trust the DNS. I'll look into porting my patch across to the OpenBSD codebase.
Is this considered to be "fixed" now? Cause the ticket is still open...
(In reply to comment #10) > Is this considered to be "fixed" now? Cause the ticket is still > open... Unfortunately is not. The patch is not included in the mainstream version which is supplied by most of the linux distribution. For instance with openssh 6.2p2-1 supplied by Arch Linux '#man ssh_config' doesn't know anything about the directive 'GSSAPITrustDNS' and I'm not able to resolve DNSs. This is really crazy: a patch has been there since 7 years ago, but still not fixed!
I just wanted to chime in here to say that this is still not fixed. I am having serious issue with not being able to use kerberos. Why has the patch not been merged since 2006?
well it was never ported to openbsd upstream (see comment #9) and in its current form won't compile because the get_canonical_hostname() it uses doesn't exist any more.
(In reply to Darren Tucker from comment #13) the original patch written in 2006 was against openbsd cvs, and it included a config option to turn it on/off (with the default being off). it largely applied cleanly up through 7.2 until the get_canonical_hostname refactor. since that func only lives in auth.c now, how do you want it to work ? basically have to revert the get_canonical_hostname -> auth_get_canonical_hostname change to make it work.
I think it would make a degree of sense to move remote_hostname back to canohost.c and give it external linkage. The commit message for that refactoring said that it was removing all the caching from canohost.c, but only (auth_)get_canonical_hostname has that, not the underlying remote_hostname function. Given that, it's easy to make the GSSAPI bits use remote_hostname rather than get_canonical_hostname, although I think it's best to also make kex->gss_host be allocated rather than relying on sharing memory with something else. I've done this in the latest Debian patch set.
Apparently, some good Samaritan already made patches compatible with the current version of OpenSSH. There is a package on the Arch User Repo (openssh-gssapi 7.1p2-1) that implements them. Here are the patches themselves: https://aur.archlinux.org/cgit/aur.git/tree/gssapi-p0.patch?h=openssh-gssapi https://aur.archlinux.org/cgit/aur.git/tree/gssapi-p1.patch?h=openssh-gssapi https://aur.archlinux.org/cgit/aur.git/tree/gssapi-p2.patch?h=openssh-gssapi I hope this helps.
(In reply to kgizdov from comment #16) > I hope this helps. Not really. Those have a lot of other changes (mostly the GSSAPI key exchange support) and it still uses get_canonical_hostname() which is currently not available in the client. According to Damien reasoning behind moving get_canonical_hostname was to remove anything that maintained state from canohost.c to make more useable in library code. We'll have a look at making it available in the client somehow.
Hey guys, what's the status here? 12 years later, still NEW ;) Had problems with this recently when working on one of our sites. https://www.mrkortingscode.nl