DEV Community

dpm_bush
dpm_bush

Posted on Originally published at sshflow.com

SSH GSSAPI Authentication: Using Kerberos Tickets for Login

#productivity #tutorial #devops #beginners

If your organization uses Kerberos, SSH can authenticate you with a ticket you already have instead of asking for an SSH key or password. The SSH option that enables this is GSSAPIAuthentication—but turning it on does not create a Kerberos realm, issue a ticket, or configure the server’s identity.

That distinction matters: GSSAPI is the interface SSH uses to negotiate authentication. Kerberos is typically the mechanism providing the tickets and verifying identities. In everyday OpenSSH setups, “GSSAPI authentication” usually means Kerberos authentication through GSSAPI.

Check the prerequisites first

Before changing SSH configuration, confirm that the surrounding Kerberos setup exists:

  • A working Kerberos realm, such as an Active Directory domain, FreeIPA/IdM, or MIT Kerberos realm.
  • A valid ticket-granting ticket (TGT) for the user connecting.
  • A host service principal for the SSH server, commonly in the form host/server.example.com@REALM, stored in a keytab the server can read.

Without those pieces, enabling GSSAPI in SSH won’t provide ticket-based login.

Check whether you already have a ticket:

klist
Enter fullscreen mode Exit fullscreen mode

If you need to obtain one, use your realm’s principal:

kinit user@EXAMPLE.COM
klist
Enter fullscreen mode Exit fullscreen mode

An empty or expired ticket cache is a Kerberos problem to solve before debugging SSH options.

Enable the method on the client and server

OpenSSH clients default GSSAPIAuthentication to no. Enable it for only the hosts that need Kerberos, rather than applying it indiscriminately:

Host *.example.com
    GSSAPIAuthentication yes
Enter fullscreen mode Exit fullscreen mode

If you regularly manage host-specific SSH settings, SSH config examples for hosts, keys, and connection options can help keep this setting scoped to the right machines.

The server must also enable GSSAPI authentication in its sshd_config:

GSSAPIAuthentication yes
Enter fullscreen mode Exit fullscreen mode

The server option also defaults to no. Apply configuration changes using the service-management method supported by your system. They won’t affect SSH sessions that are already running.

Two other server options are worth understanding:

GSSAPICleanupCredentials yes
GSSAPIStrictAcceptorCheck yes
Enter fullscreen mode Exit fullscreen mode

GSSAPICleanupCredentials controls whether GSSAPI credentials are destroyed when a session ends; its default is yes. GSSAPIStrictAcceptorCheck defaults to yes and requires authentication against the host service for the current hostname. Leave that default in place unless your Kerberos deployment has a specific reason to change it.

Confirm what SSH is negotiating

Try a verbose connection:

ssh -vvv user@server.example.com
Enter fullscreen mode Exit fullscreen mode

Look for the authentication methods the server says it will accept. A line like this indicates that GSSAPI is being offered:

debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Enter fullscreen mode Exit fullscreen mode

You may also see SSH attempt the method and report success:

debug1: Next authentication method: gssapi-with-mic
debug1: Authentication succeeded (gssapi-with-mic)
Enter fullscreen mode Exit fullscreen mode

If gssapi-with-mic is missing from the offered methods, check the server configuration first. If SSH offers and attempts it but authentication fails, investigate the ticket, server keytab, and service principal. A guide to reading ssh -v, -vv, and -vvv output can help you follow the negotiation step by step.

Check the keytab and server identity

On the server, inspect the keytab entries with:

klist -kt /etc/krb5.keytab
Enter fullscreen mode Exit fullscreen mode

Check that the keytab contains the expected host principal and that the SSH server can read it. How a keytab is created or managed depends on the environment: a domain-join tool, FreeIPA/IdM, and a standalone MIT Kerberos setup don’t necessarily use the same process.

The principal also has to match the identity the client is using. A connection made with a short hostname, fully qualified domain name, or alias can lead to different hostname canonicalization behavior. Reverse DNS matching is not a blanket SSH requirement. If the name looks wrong, check the client’s GSSAPITrustDns setting and the Kerberos hostname-canonicalization configuration before assuming DNS must be rebuilt. GSSAPIServerIdentity can specify the server identity explicitly when hostname guessing is the problem.

Common failure patterns

  • No Kerberos credentials available: Run klist; obtain or renew a ticket if needed.
  • gssapi-with-mic isn’t offered: Check that the server enables GSSAPIAuthentication and that the client isn’t excluding the method through its authentication preferences.
  • Server not found in Kerberos database: Check the hostname and expected service principal. Consider whether explicit GSSAPIServerIdentity is appropriate.
  • SSH falls back to a password: Confirm that the server has a readable keytab containing the matching host principal.
  • The method is attempted but rejected: Use ssh -vvv to locate the failure, then check server logs, the keytab, and hostname identity.

KerberosAuthentication is a separate server-side option. It can validate an ordinary SSH password against Kerberos; it does not use the client’s ticket as GSSAPI authentication does, and it does not provide ticket-based single sign-on.

Treat credential delegation as a trust decision

Client-side GSSAPIDelegateCredentials yes forwards your Kerberos credentials to the remote host. That can let you use Kerberos-backed services or connect onward from that session without authenticating again. The tradeoff is that the delegated credentials are available on the remote machine for the session’s lifetime. Someone with sufficient access to that host may be able to use them as you.

Keep delegation disabled unless you need it, and enable it only for hosts you trust. When delegation is used, server-side GSSAPICleanupCredentials yes helps remove the credential cache at session end. The client setting controls whether credentials are offered; the server has its own setting controlling whether it accepts them.

GSSAPI authentication makes sense when your organization already operates Kerberos and wants SSH login to use existing tickets. For a personal server without that infrastructure, SSH key-based authentication is usually the more direct option.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Top comments (0)