When your SSH connection terminates immediately after the server accepts your public key, despite having properly configured authorized_keys, it can be particularly frustrating. The server logs show the key was accepted, yet the connection drops without explanation.

From the log snippets provided, we can extract several important clues:

• The key format is SSH-RSA (shown in pkalg ssh-rsa)
• Authentication reaches the sign_and_send_pubkey stage
• The closure originates from the server side

Beyond the basic checks you've already performed, consider these often-overlooked areas:

# Check PAM authentication logs
grep sshd /var/log/auth.log | grep pam

# Verify SELinux status (if applicable)
sestatus

# Inspect system resource limits
ulimit -a

# Check for forced commands in authorized_keys
grep "command=" ~/.ssh/authorized_keys

The user's shell configuration might be causing immediate termination. Test with:

# Temporarily change the shell to /bin/sh
sudo usermod -s /bin/sh username

# Or create a test user with minimal configuration
sudo adduser ssh_test_user --shell=/bin/bash

When standard logs don't reveal the issue, try these approaches:

# Run SSH server in debug mode
/usr/sbin/sshd -d -p 2222

# Check for TCP wrappers restrictions
strace -f -e trace=network -p pgrep sshd

# Monitor process execution
sudo bash -c "strace -f -o /tmp/sshd_trace -p \$(pgrep -o sshd)" &

Examine these often-misconfigured SSH server settings:

# Check for these in /etc/ssh/sshd_config
Match User agladysh
    ForceCommand /bin/false

# Or potentially problematic settings like:
PermitRootLogin no
AllowAgentForwarding no
X11Forwarding no

Modern SSH servers may reject older key formats. Try regenerating your key:

ssh-keygen -t ed25519 -f ~/.ssh/new_key
ssh-copy-id -i ~/.ssh/new_key.pub user@host

When working with SSH public key authentication, encountering a connection that closes immediately after key acceptance is particularly frustrating. The logs show:

# Server auth.log
Failed publickey for user from IP port 12345 ssh2

# Client debug output (-vvv)
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp SHA256:xxxx
debug3: sign_and_send_pubkey
Connection closed by SERVER

Beyond the obvious authorized_keys checks, we need to examine:

• Shell initialization files (~/.profile, ~/.bashrc)
• PAM module configurations (/etc/pam.d/sshd)
• SSH forced commands in authorized_keys
• Resource limits (ulimit -a)

The most common culprit is often shell initialization scripts. Try this diagnostic sequence:

# On the server:
sudo -u youruser /bin/bash --norc
# If this works, then test with:
sudo -u youruser /bin/bash -i

For a more surgical approach, temporarily rename your shell config files:

mv ~/.profile ~/.profile.bak
mv ~/.bashrc ~/.bashrc.bak

Examine these critical SSH daemon settings in /etc/ssh/sshd_config:

# Ensure these aren't restricting access
AllowUsers youruser
AllowGroups sshusers
PermitRootLogin no

# Key authentication specific settings
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

SSH is particular about file permissions. Verify these requirements:

# Home directory and .ssh permissions
chmod 700 ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_rsa  # For the private key

# SELinux context (if applicable)
ls -Z ~/.ssh/authorized_keys
restorecon -Rv ~/.ssh

Sometimes firewall rules or TCP wrappers interfere:

# Check for tcp wrappers
grep sshd /etc/hosts.deny
grep sshd /etc/hosts.allow

# Examine firewall rules
sudo iptables -L -n -v
sudo ip6tables -L -n -v

Create a minimal PAM configuration for testing:

# Backup existing config
cp /etc/pam.d/sshd /etc/pam.d/sshd.bak

# Create minimal config
echo "auth required pam_permit.so" > /etc/pam.d/sshd.test
echo "session required pam_permit.so" >> /etc/pam.d/sshd.test

# Test with this config
/usr/sbin/sshd -ddd -o PAMAuthentication=yes -o UsePAM=yes -o PAMService=sshd.test