How to fix Connection closed by authenticating user in SSH

Connect to the server and verify your .ssh directory and authorized_keys file have correct permissions:

# Check directory permissions (should be 700)
ls -ld ~/.ssh
# Should show: drwx------

# Check authorized_keys file permissions (should be 600)
ls -l ~/.ssh/authorized_keys
# Should show: -rw-------

Fix if needed:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Even if permissions appear correct visually, verify there are no unusual flags:

stat ~/.ssh
stat ~/.ssh/authorized_keys

The owner must be the user themselves, not root or another user.

The home directory itself must not have group or world write permissions. SSH strictly enforces this:

# Check home directory
ls -ld ~
# Should show: drwxr-xr-x (755) or drwx------ (700)
# NOT drwxrwxr-x or drwxr-xrwx

If group or world write bit is set, fix it:

chmod go-w ~
# This removes write permissions for group and others

Verify:

ls -ld ~
# Now should show drwxr-xr-x (755) or more restrictive

Check that your login shell exists and is executable:

# Show your shell
echo $SHELL
# Or check /etc/passwd directly
grep "^$(whoami):" /etc/passwd | cut -d: -f7

The shell path must exist and be executable. Common valid shells:
- /bin/bash
- /bin/sh
- /bin/zsh
- /bin/ksh

If it points to /bin/false, /usr/sbin/nologin, or a non-existent path, update it:

# As root or with sudo:
usermod -s /bin/bash username

Verify the shell exists:

ls -l /bin/bash  # Should exist and be executable

Stop the SSH service and run sshd in verbose debug mode to see exactly why the connection closes:

# As root, stop the running sshd
sudo systemctl stop ssh
# or: sudo systemctl stop sshd

# Run sshd in debug mode (shows output, doesn't daemonize)
sudo /usr/sbin/sshd -ddd

In another terminal, try to connect:

ssh -v username@localhost

The debug output from sshd will show the exact point where authentication closes. Look for messages like:
- "Authentication refused: bad ownership or modes for directory"
- "Authentication refused: bad ownership or modes for .ssh directory"
- "error: PAM: Authentication failure"
- "Connection closed by authenticating user"

Common patterns in debug output reveal the root cause. After debugging, restart SSH:

sudo systemctl start ssh
# or: sudo systemctl start sshd

If debug output shows PAM-related errors, check sshd's PAM configuration:

# View sshd PAM setup (typically /etc/pam.d/sshd)
cat /etc/pam.d/sshd

After system updates (especially major version upgrades), PAM files can become inconsistent. One quick fix is to restore default PAM configuration for SSH:

On Debian/Ubuntu:

# Reinstall openssh-server to reset PAM config
sudo apt-get install --reinstall openssh-server

On RHEL/CentOS/Fedora:

sudo yum reinstall openssh-server
# or with newer systems:
sudo dnf reinstall openssh-server

This resets /etc/pam.d/sshd to defaults without overwriting your sshd_config settings.

Newer SSH servers (OpenSSH 8.2+) deprecated SHA1-based algorithms. If you're using older keys, they may fail:

# On the server, check which key types are accepted
sudo sshd -T | grep -i pubkey

# Look for: PubkeyAcceptedKeyTypes
# Output shows which key algorithms are allowed

If ssh-rsa is not listed and you're using RSA keys, you have two options:

Option 1: Re-enable ssh-rsa on the server (less secure but more compatible)

Edit /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Add or uncomment:

PubkeyAcceptedKeyTypes=ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519

Then restart sshd:

sudo systemctl restart ssh

Option 2: Generate a modern ED25519 key on the client (recommended)

# On your client machine:
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

Then add the new public key to the server's authorized_keys.

Check if your public key is actually in authorized_keys and that there are no corrupted entries:

# View your authorized_keys
cat ~/.ssh/authorized_keys

Each line should be a single long string starting with 'ssh-rsa', 'ssh-ed25519', 'ecdsa-sha2-nistp256', etc.

Look for:
- Incomplete or truncated keys (lines that don't start with a valid key type)
- Extra whitespace or line breaks within a key
- Comments that accidentally got included in the key data

If you find corrupted lines, remove them:

# Backup first
cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.backup

# Edit with nano or vi
nano ~/.ssh/authorized_keys
# Remove any corrupted or incomplete lines

# Verify permissions after editing
chmod 600 ~/.ssh/authorized_keys

If you're unsure of your public key content, regenerate it from your private key:

# On your client machine
ssh-keygen -y -f ~/.ssh/id_rsa  # or id_ed25519, id_ecdsa
# This prints the public key without changing anything

Then carefully add it to server's authorized_keys.

If .bashrc or similar startup scripts have issues, they can cause SSH to disconnect:

# Test if bashrc has syntax errors
bash -n ~/.bashrc  # -n checks syntax without executing

If errors are reported, fix them. Common issues:
- Unclosed quotes or braces
- Commands that require a terminal (like clear, tput) in non-interactive sections
- Code that calls exit unconditionally

You can also test a minimal shell:

# Start a shell without reading any rc files
bash --noprofile --norc

# Or set empty rc
bash --rc /dev/null

If this works, your shell startup files are the issue. Temporarily rename them to test:

# Backup and disable
mv ~/.bashrc ~/.bashrc.bak
mv ~/.bash_profile ~/.bash_profile.bak

# Try SSH again - if it works, re-enable files and debug them