Description of problem: Users probably expect to "skate" around their FreeIPA domains using GSSAPI with ssh. The FreeIPA client installer explicitly adds a dns_canonicalize_hostname setting, and configures it to be false. This results in a surprising inability to SSH by short name. (Though this seems to have been set in FreeIPA long ago - maybe a recent krb5 lib upgrade made this suddenly visible? https://bugzilla.redhat.com/show_bug.cgi?id=1481655 was about this issue last year. Version-Release number of selected component (if applicable): python3-ipaclient-4.6.90.pre1-7.fc28.noarch Note that this also seems to affect Fedora 27 (I was able to reproduce it there; seems krb5 1.16.1 are common on both) How reproducible: Always, seems like Steps to Reproduce: 1. Install FreeIPA client 2. SSH to another FreeIPA client to which you have login rights via SSH by short name (ssh login via FQDN works, as expected) 3. Actual results: Password prompt, as SSH debug indicates that service principal name not found in database Expected results: Login on system Additional info:
Added in commit 566c86a782bfd7d50938866e9f89faf56cea773f disable hostname canonicalization by Kerberos library By default, Kerberos client library attempts to canonicalize service hostname in TGS requests. This can fail e.g. if hosts file on the client machine references short names before FQDNs. In this case the short name is used in TGS_REQ which KDC fails to resolve. Since we do not (yet) support referencing hosts by their short names it is safe to just disable this behavior in krb5.conf and use supplied FQDNs. https://fedorahosted.org/freeipa/ticket/6584
I see that the behavior is deliberate, but lots of people use short names, especially for SSH. It seems like something broke relatively recently in this. Would it make sense to make this behavior tunable with an installer flag?
There is a way to add a snippet in /etc/krb5.conf.d/ to override a default. There is also a support for Kerberos principal aliases in FreeIPA. Both provide enough methods to handle this at a particular deployment. I'm closing this bug as WONTFIX.