I have a situation where I am attempting to take advantage of GSSAPI (Kerberos) forwarding to connect to another Linux server that is also joined to a Windows AD and using SSSD.

The Linux machines are joined to the domain using a different machine name than the actual FQDN of the server. When I log into the first machine with my domain credentials, PAM succeeds and I'm issued a valid token. It shows up with klist. However, even after enabling GSSAPI and Kerberos logins on SSH on another linux host also joined to the domain, I still get the "Server not found in the kerberos database" client error and it falls back to using password authentication. I am passing along -K to enable the Kerberos token forwarding.

If my memory serves correctly, this is potentially due to an SPN issue in AD (the Kerberos server in this case) with the Linux machine joined with a different machine name than the actual machine's FQDN that I am connecting to (or from?) but I'm not certain and need some help pointing me in the right direction.


You can use the principal name known to your domain controller by passing the GSSAPIServerIdentity option to your ssh client:


From the ssh_config manpage:

GSSAPIServerIdentity If set, specifies the GSSAPI server identity that ssh should expect when connecting to the server. The default is unset, which means that the expected GSSAPI server identity will be determined from the target hostname.

  • On Fedora 30, I was able to avoid having to use the parameter described here, by removing from /etc/ssh_config the option: GSSAPITrustDns yes and adding to /etc/krb5.conf dns_canonicalize_hostname = true. I don't know why this combo works, but it does. Ref: bgstack15.wordpress.com/2017/12/11/… – bgStack15 May 5 at 18:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.