Kerberos provides single sign-on authentication for SSH, but when it fails, you see errors like:

bash
$ ssh user@server.example.com
Permission denied (gssapi-with-mic,publickey,password)

Or specifically:

bash
$ ssh user@server.example.com
debug1: Attempting GSSAPI authentication...
debug1: GSSAPI authentication failed: Server not found in Kerberos database

This guide covers Kerberos authentication issues specific to SSH.

Understand Kerberos SSH Flow

For Kerberos SSH to work:

  1. 1.You have a Kerberos ticket from your realm's KDC
  2. 2.The SSH server has a service principal (host/server.example.com@REALM)
  3. 3.Your ticket can authenticate to that service principal
  4. 4.SSHD is configured to accept GSSAPI

Verify Your Kerberos Ticket

First, check your current ticket:

bash
klist

Healthy output:

``` Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: admin@CORP.EXAMPLE.COM

Valid starting Expires Service principal 04/03/2026 10:00:00 04/03/2026 18:00:00 krbtgt/CORP.EXAMPLE.COM@CORP.EXAMPLE.COM renew until 04/10/2026 10:00:00 ```

If empty or expired:

bash
kinit admin@CORP.EXAMPLE.COM

Enter your Kerberos password. Verify:

bash
klist

Check Ticket Cache Location

SSH needs to find your credential cache:

bash
echo $KRB5CCNAME

If unset:

bash
ls -la /tmp/krb5cc_*

Set the environment variable:

bash
export KRB5CCNAME=FILE:/tmp/krb5cc_1000

Make it permanent in ~/.bashrc:

bash
export KRB5CCNAME=FILE:/tmp/krb5cc_$(id -u)

Verify Kerberos Configuration

Check /etc/krb5.conf:

bash
cat /etc/krb5.conf

Must include:

``` [libdefaults] default_realm = CORP.EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true ticket_lifetime = 24h forwardable = true

[realms] CORP.EXAMPLE.COM = { kdc = kdc01.corp.example.com kdc = kdc02.corp.example.com admin_server = kdc01.corp.example.com }

[domain_realm] .corp.example.com = CORP.EXAMPLE.COM corp.example.com = CORP.EXAMPLE.COM ```

Test Kerberos Independently

Before debugging SSH, test Kerberos directly:

bash
kinit admin@CORP.EXAMPLE.COM
klist

Get a service ticket:

bash
kvno host/server.corp.example.com@CORP.EXAMPLE.COM

This tests if you can authenticate to the SSH service principal.

If kvno fails:

bash
kvno: Server not found in Kerberos database while getting credentials for host/server.corp.example.com

The service principal doesn't exist.

Check Server Service Principal

On the KDC or using kadmin:

bash
kadmin -q "listprincs" | grep host/server

If missing, create it:

bash
kadmin -q "addprinc -randkey host/server.corp.example.com@CORP.EXAMPLE.COM"

Extract keytab for the server:

bash
kadmin -q "ktadd host/server.corp.example.com@CORP.EXAMPLE.COM"

Copy the keytab to the server:

bash
scp keytab server:/etc/krb5.keytab

Verify Server Keytab

On the SSH server:

bash
klist -k /etc/krb5.keytab

Should show:

bash
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- ----------
   3 host/server.corp.example.com@CORP.EXAMPLE.COM

Check Keytab Permissions

bash
ls -la /etc/krb5.keytab

Fix permissions:

bash
sudo chown root:root /etc/krb5.keytab
sudo chmod 600 /etc/krb5.keytab

Enable GSSAPI in SSHD

On the server:

bash
sudo grep GSSAPIAuthentication /etc/ssh/sshd_config

Enable it:

bash
sudo sed -i 's/^#*GSSAPIAuthentication.*/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Also enable:

bash
sudo sed -i 's/^#*GSSAPICleanupCredentials.*/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo sed -i 's/^#*GSSAPIKeyExchange.*/GSSAPIKeyExchange yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Enable GSSAPI in SSH Client

In ~/.ssh/config:

bash
Host *.corp.example.com
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
    GSSAPIKeyExchange yes

GSSAPIDelegateCredentials forwards your ticket to the server.

Debug SSH Kerberos

Verbose SSH:

bash
ssh -vvv admin@server.corp.example.com 2>&1 | tee kerberos_debug.log
grep -i gss kerberos_debug.log

Look for:

bash
debug3: send SSH2_MSG_KEXINIT_KEXGSS_HOSTKEY
debug1: Offering GSSAPI proposal: gss-gex-sha1-krb5,gss-mic-sha1-krb5

If it shows "Permission denied" after GSSAPI offer, check server-side logs.

Check Server Logs

On the server:

bash
sudo journalctl -u sshd -f

Connect and watch:

bash
Apr  3 10:15:22 server sshd[12345]: gssapi-with-mic-krb5: Miscellaneous failure
Apr  3 10:15:22 server sshd[12345]: Permission denied for user admin from 192.168.1.50

Check Clock Synchronization

Kerberos requires clocks within 5 minutes:

```bash # Check client time date

# Check server time ssh server 'date' ```

If more than 5 minutes apart:

bash
# Sync both to NTP
sudo systemctl restart chronyd
# or
sudo systemctl restart ntpd

Handle Cross-Realm Authentication

If your ticket is from a different realm:

bash
klist
# Shows: Default principal: admin@OTHER.REALM.COM

But server is in CORP.EXAMPLE.COM:

You need a cross-realm trust or ticket for the target realm:

bash
kinit -S host/server.corp.example.com@CORP.EXAMPLE.COM admin@OTHER.REALM.COM

Fix Principal-to-Username Mapping

If Kerberos principal differs from SSH username:

bash
# Kerberos principal: alice@CORP.EXAMPLE.COM
# SSH username: alice_admin

Create .k5login:

bash
echo "alice@CORP.EXAMPLE.COM" > ~/.k5login
chmod 600 ~/.k5login

Or configure mapping in sshd_config:

bash
sudo grep -i authusers /etc/ssh/sshd_config

Add:

bash
GSSAPIAuthUsers yes
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Create principals file:

bash
sudo mkdir -p /etc/ssh/auth_principals
echo "alice@CORP.EXAMPLE.COM" | sudo tee /etc/ssh/auth_principals/alice_admin

Handle Hostname Mismatch

Kerberos principal hostname must match SSH server hostname:

bash
# Check server's actual hostname
hostname -f

If hostname is server.internal.corp.example.com but principal is host/server.corp.example.com:

Create principal matching hostname:

bash
kadmin -q "addprinc -randkey host/server.internal.corp.example.com@CORP.EXAMPLE.COM"

Or set canonical hostname in client config:

bash
Host server.corp.example.com
    CanonicalizeHostname yes
    CanonicalDomains internal.corp.example.com corp.example.com

Check DNS and Service Records

Kerberos uses DNS for discovery:

bash
dig _kerberos._tcp.corp.example.com SRV
dig _kpasswd._tcp.corp.example.com SRV

If missing, add to krb5.conf manually:

bash
[realms]
    CORP.EXAMPLE.COM = {
        kdc = kdc01.corp.example.com:88
        admin_server = kdc01.corp.example.com:749
    }

Test with Explicit Principal

Specify your principal:

bash
kinit -p admin@CORP.EXAMPLE.COM
ssh -o GSSAPIAuthentication=yes admin@server.corp.example.com

Forward Ticket to Server

If you need to SSH further from the server:

bash
ssh -o GSSAPIDelegateCredentials=yes admin@server.corp.example.com

On the server:

bash
klist

Should show forwarded credentials.

Resolution Checklist

  1. 1.Verify Kerberos ticket: klist
  2. 2.Get fresh ticket: kinit principal@REALM
  3. 3.Set KRB5CCNAME environment variable
  4. 4.Check /etc/krb5.conf configuration
  5. 5.Verify service principal exists: kadmin -q "listprincs"
  6. 6.Check server keytab: klist -k /etc/krb5.keytab
  7. 7.Fix keytab permissions
  8. 8.Enable GSSAPI in sshd_config
  9. 9.Enable GSSAPI in ~/.ssh/config
  10. 10.Synchronize clocks
  11. 11.Use .k5login for principal mapping
  12. 12.Verify hostname matches principal

Kerberos SSH errors usually stem from missing service principals, expired tickets, or clock synchronization. Start by verifying your ticket and the server's principal configuration.