After upgrading to Fedora 23, I encountered a bizarre SSH authentication issue where:

1. The server recognizes and accepts my RSA key (debug1: matching key found)
2. The client receives key acceptance (debug1: Server accepts key)
3. Yet the connection immediately terminates with Permission denied (publickey)

Working scenarios:

• Same key works via PuTTY on Windows
• Different key works from mobile client
• Password authentication succeeds

Relevant configuration (/etc/ssh/ssh_config):

Host *
        GSSAPIAuthentication yes
        ForwardX11Trusted yes
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

1. Verify key permissions:

chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 700 ~/.ssh

2. Check SELinux context:

restorecon -Rv ~/.ssh

3. Debug with maximum verbosity:

ssh -vvv user@host

The root cause was GSSAPI authentication interfering with key-based auth. Add this to ~/.ssh/config:

Host *
    GSSAPIAuthentication no
    PreferredAuthentications publickey

Or globally in /etc/ssh/ssh_config:

Host *
    GSSAPIAuthentication no

For systems requiring GSSAPI:

Host target-server
    HostName server.example.com
    User remote-user
    IdentityFile ~/.ssh/custom_key
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes

After making changes, test with:

ssh -T git@github.com  # For GitHub verification
ssh -v user@localhost  # For local testing

---

When analyzing SSH authentication issues, the key detail in this scenario is the server-side log showing successful key acceptance followed by immediate disconnection:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1
Postponed publickey for theo from {IP} port 60351 ssh2 [preauth]
Connection closed by {IP} [preauth]

First verify the SSH daemon configuration on the remote host:

# Check key permissions
ls -la ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Verify sshd_config settings
grep -E "PubkeyAuthentication|AuthorizedKeysFile" /etc/ssh/sshd_config

# Typical correct settings:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Enable verbose output on the client for detailed diagnostics:

ssh -vvv user@hostname

Key observations from the debug output suggest the server accepts the key but the client fails to proceed:

debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{HASH}
debug2: we did not send a packet, disable method

Try these specific fixes in order:

# 1. Regenerate the key pair with modern format
ssh-keygen -t ed25519 -f ~/.ssh/new_key

# 2. Verify key format compatibility
ssh-keygen -l -f ~/.ssh/id_rsa

# 3. Check for SELinux restrictions (Fedora specific)
ls -Z ~/.ssh/authorized_keys
restorecon -Rv ~/.ssh

For persistent cases, use tcpdump to examine the SSH handshake:

sudo tcpdump -i eth0 'port 22 and host {CLIENT_IP}' -w ssh_debug.pcap

Analyze the packet capture with Wireshark, focusing on:

• SSH_MSG_USERAUTH_REQUEST
• SSH_MSG_USERAUTH_PK_OK
• Any unexpected TCP resets

As temporary workarounds while debugging:

# Use SSH agent forwarding
eval $(ssh-agent)
ssh-add ~/.ssh/id_rsa
ssh -A user@hostname

# Or try certificate-based auth
ssh-keygen -s ca_key -I key_id user_key.pub