SSH Connection Not Taking Kerberos Ticket Along

SSH connections fail to use Kerberos tickets when the client lacks a valid ticket or the server rejects GSSAPI authentication. This issue commonly arises from expired credentials, misconfigured SSH daemon settings, or platform-specific service principal name (SPN) mismatches between Linux and Windows environments.

Verify Your Kerberos Ticket Status

The most common reason for SSH ignoring Kerberos is the absence of a valid ticket-granting ticket (TGT). Before troubleshooting complex configurations, ensure your system holds an active credential cache. On Linux systems, you can inspect this using the klist utility. Run klist in your terminal to display current tickets. If the output shows "No credentials cache found" or lists only expired entries, you must re-authenticate. Use kinit [email protected] to obtain a new ticket. For Windows clients integrated into Active Directory, verify that the machine has successfully logged in via the GUI or command line. The presence of a TGT is a prerequisite; without it, no amount of SSH configuration will force Kerberos negotiation.

Configure the SSH Client Correctly

Once you have a valid ticket, you must instruct the SSH client to attempt GSSAPI authentication. Edit your local ~/.ssh/config file or the system-wide /etc/ssh/ssh_config. Add or modify the following directives for the target host:

Host target-hostname
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
    ForwardAgent no

The GSSAPIAuthentication yes directive explicitly enables the protocol. Some older configurations may require GSSAPIAuthentication auto, but yes is more explicit. The GSSAPIDelegateCredentials option allows you to forward your credentials to subsequent hops if needed. Note that enabling agent forwarding (ForwardAgent yes) is generally discouraged for security reasons unless absolutely necessary. After saving these changes, test the connection with verbose output by running ssh -v target-hostname. Look for lines indicating "Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic". If these are missing, the client is not offering GSSAPI at all.

Adjust Server-Side Settings

If the client offers GSSAPI but the server refuses it, the issue lies on the remote machine. You must edit the /etc/ssh/sshd_config file on the server. Ensure the following lines are present and uncommented:

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

The first line permits the server to accept Kerberos-based logins. The second ensures that credentials are cleaned up after the session ends, which is good practice. After modifying this file, restart the SSH service. On systemd-based Linux distributions, run systemctl restart sshd. On older SysVinit systems, use service sshd restart. Verify the service status to ensure it restarted without errors. If the server still rejects the connection, check the server logs at /var/log/auth.log or /var/log/secure for specific rejection reasons.

Address Windows-Specific Challenges

Connecting to or from Windows adds complexity due to differences in how Kerberos is implemented. When connecting from Linux to a Windows host, ensure the Windows account is part of a domain that trusts the Kerberos realm. The SPN for the SSH service on Windows must be correctly registered. Typically, this is handled automatically by the OpenSSH for Windows installation, but manual verification helps. On the Windows side, open PowerShell as Administrator and run Get-Service sshd to ensure the service is running. Check the event viewer for any Kerberos-related errors. For Windows clients connecting to Linux servers, ensure the Windows machine is joined to the domain. Local accounts cannot use Kerberos. If you are using WSL, remember that it shares the network stack with the host. However, WSL does not automatically inherit Windows Kerberos tickets. You may need to configure /etc/krb5.conf within WSL to match your domain's configuration. Refer to our guide on Troubleshooting SSH WSL Machine: Can't Connect to Localhost for deeper insights into WSL networking quirks that might interfere with ticket visibility.

Debugging Common Errors

If you encounter "Permission denied (publickey,gssapi-with-mic)", it usually means the server accepted the GSSAPI offer but failed to validate the ticket. This often happens if the clock skew between client and server exceeds five minutes. Synchronize time using NTP on both machines. Another common error is "Unable to exchange encryption keys". This indicates a fundamental mismatch in cryptographic algorithms or key types. Ensure that both the client and server support the same GSSAPI mechanisms. Use ssh -vvv for extremely detailed debugging output. Look for the exact point where the handshake fails. If you are passing passwords via bash scripts, ensure you are not inadvertently bypassing Kerberos by using other authentication methods. See Pass pw for remote user in bash line when ssh from linux to windows for context on alternative authentication flows that might conflict.

Frequently Asked Questions

Why does my SSH connection fall back to password authentication?

This happens when GSSAPI authentication fails or is disabled. Check your .ssh/config to ensure GSSAPIAuthentication yes is set. Also, verify that you have a valid ticket using klist. If the server rejects the ticket, it will try the next method listed in its allowed auth list.

Can I use Kerberos with local Windows accounts?

No. Kerberos requires integration with a directory service like Active Directory. Local Windows accounts do not have Kerberos principals in the domain realm. You must join the computer to the domain and use a domain user account for Kerberos SSH authentication.

How do I fix clock skew issues with Kerberos?

Kerberos is sensitive to time differences. Install and configure an NTP client on both the client and server machines. Ensure they synchronize with the same time source. A skew greater than five minutes will cause immediate ticket validation failures.

What is the difference between GSSAPI and Kerberos?

GSSAPI (Generic Security Service Application Program Interface) is the API used by SSH to perform authentication. Kerberos is one of the security mechanisms that can operate under GSSAPI. When you enable GSSAPI in SSH, you are allowing it to use Kerberos (or other supported mechanisms) for login.

Does WSL support Kerberos out of the box?

WSL does not automatically inherit Windows Kerberos tickets because it runs a separate Linux kernel and user space. You must manually configure krb5.conf and potentially install MIT Kerberos packages within the WSL distribution to manage tickets independently.