When setting up passwordless authentication between Windows clients (Putty) and Linux servers joined to Active Directory, we often encounter silent failures in the GSSAPI negotiation process. The packet trace reveals an interesting sequence:

Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)

This indicates successful credential exchange but ultimate rejection by the server. Let's break down the components.

For Putty GSSAPI to work with AD:

• SSH server must have GSSAPIAuthentication yes in /etc/ssh/sshd_config
• Client-side Putty must enable GSSAPI in Connection > SSH > Auth
• Windows machine must be AD-joined or have explicit trust
• Kerberos ticket must exist before connection attempt

First verify your Windows credential state:

klist
Current LogonId is 0:0x1e4a2
Cached Tickets: (0)

# If empty, manually acquire:
kinit username@DOMAIN.COM

For Putty-specific debugging, enable these settings:

1. Session > Logging > "SSH packets" and "SSH raw data"
2. Connection > SSH > Auth > GSSAPI: Check "Allow GSSAPI credential delegation"

Your /etc/ssh/sshd_config should contain:

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIStrictAcceptorCheck no  # Critical for AD interoperability
GSSAPIKeyExchange no
UsePAM yes

After changes, restart sshd:

service sshd restart

Scenario 1: Successful GSSAPI exchange but still prompted for password

Solution: Check PAM configuration. Edit /etc/pam.d/sshd:

auth sufficient pam_sss.so use_first_pass
account [default=bad success=ok user_unknown=ignore] pam_sss.so

Scenario 2: Time synchronization issues

# On Linux server:
ntpdate -u ad-dc.domain.com

# On Windows:
w32tm /resync

If GSSAPI continues to fail, consider these workarounds:

1. Use Pageant with Kerberos tickets:

   # In Cygwin:
   kinit
   ssh-add -t 10h -c /tmp/krb5cc_%{uid}
   

2. Configure Putty with Kerberos commands:

   Connection > SSH > Auth > GSSAPI:
   GSSEXE: C:\Program Files\MIT\Kerberos\bin\kinit.exe
   GSSARGS: %U@REALM
   

Enable debug logging on the SSH server:

# In /etc/ssh/sshd_config:
LogLevel DEBUG3

# Then monitor logs:
tail -f /var/log/secure | grep -i gssapi

Key things to look for:

• "Accepted gssapi-with-mic" messages
• SPN (Service Principal Name) verification errors
• Ticket expiration warnings

---

When examining the packet log, we can see the authentication sequence follows this pattern:

1. SSH protocol negotiation
2. Key exchange (Diffie-Hellman group exchange)
3. Encryption setup (AES-256 SDCTR)
4. GSSAPI authentication initialization
5. Token exchange
6. Final MIC (Message Integrity Code) submission
7. Unexpected failure despite successful GSSAPI negotiation

The critical portion reveals:

Event Log: GSSAPI authentication loop finished OK
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex,gssapi-with-mic,password.

This indicates the GSSAPI authentication technically succeeds, but the server still rejects the attempt.

For PuTTY to work with AD Kerberos authentication:

• Ensure Use GSSAPI authentication is checked in Connection > SSH > Auth
• Verify Allow GSSAPI credential delegation is enabled
• The client machine must be domain-joined or have valid kerberos tickets
• Server-side SSH daemon must have GSSAPI enabled

Your /etc/ssh/sshd_config should contain:

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes

Time Synchronization: Kerberos is extremely sensitive to time differences. Ensure all systems use NTP:

# On RHEL6:
service ntpd restart
chkconfig ntpd on

DNS Configuration: Reverse DNS must work correctly. Verify with:

host $(hostname -f)
host $(ip addr show eth0 | grep "inet " | awk '{print $2}' | cut -d/ -f1)

On Windows, check tickets with:

klist

If no ticket exists, acquire one with:

kinit username@DOMAIN.COM

Unlike OpenSSH, PuTTY doesn't automatically use the Windows credential cache. Try these alternatives:

1. Use Pageant (PuTTY authentication agent)
2. Configure PuTTY to explicitly use SSPI
3. Generate keytab files for non-interactive auth

For deeper investigation, compare working vs non-working sessions. Notice in successful cases:

SSH2_MSG_USERAUTH_GSSAPI_MIC followed by SSH2_MSG_USERAUTH_SUCCESS

Versus failed cases where the server falls back to password authentication despite GSSAPI success.

Test the authentication flow with these commands:

# On Linux:
ssh -vvv -o GSSAPIAuthentication=yes user@host

# In PuTTY:
Enable SSH packet logging and compare with working OpenSSH sessions

Remember that PuTTY's GSSAPI implementation differs from OpenSSH, particularly in how it handles Windows' native security subsystem.