How to fix Connection closed by authenticating user in SSH

SSHINTERMEDIATEMEDIUMUpdated Jan 4, 2026· 658 views

This error occurs when SSH authentication succeeds but the session is immediately terminated by the server after the user authenticates. It typically indicates file permission issues, configuration problems, or incompatible authentication settings between client and server.

Quick fix

Fixes Connection closed by authenticating user

# 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-------
  1. Check .ssh directory and file permissions on the server
  2. Check home directory permissions
  3. Verify user's login shell is valid
  4. Run sshd in debug mode to see detailed error messages
ssh — error
# 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-------
Connection closed by authenticating user

What this error means

The "Connection closed by authenticating user" error appears after successful authentication (your credentials were accepted) but before a shell session is established. This happens when the SSH server receives valid credentials, verifies them successfully, but then abruptly closes the connection. This is different from authentication failures—the server verified you are who you claim to be, but something prevents the session from continuing. Common causes include incorrect file permissions on .ssh directories, PAM configuration issues, shell configuration problems, or incompatible cipher/MAC algorithms.

Typical symptoms

  • SSH authentication prompt appears and accepts your password/key, but then immediately disconnects
  • SSH commands fail without showing any shell error messages
  • You can see 'Authenticated' in server logs but connection drops before bash/shell starts
  • Manual SSH connections fail, but other users on the same system can connect
  • The error appears in /var/log/auth.log with 'Connection closed by authenticating user' message
  • SSH works from some clients but not others connecting to the same server
  • ForceCommand scripts (if configured) execute but then disconnect

Common causes

  1. Incorrect file permissions on ~/.ssh directory (should be 700) or ~/.ssh/authorized_keys (should be 600)
  2. Home directory has group write permissions (group or others writable when they shouldn't be)
  3. PAM (Pluggable Authentication Modules) configuration errors after system updates
  4. SSH key type not in server's PubkeyAcceptedKeyTypes list (e.g., ssh-rsa deprecated on newer systems)
  5. Public key on client doesn't match the key in server's authorized_keys file
  6. User's login shell (/etc/passwd) is set to /bin/false or a non-existent shell path
  7. SSH configuration mismatch: server has 'PasswordAuthentication no' but client is trying password auth
  8. Incompatible SSH ciphers or MAC algorithms between client and server versions
  9. Encrypted home directory or .ssh directory mounted via encfs or similar, preventing key access
  10. Shell configuration issues (~/.bashrc, ~/.bash_profile, ~/.login) that exit abnormally on non-interactive shells

How to fix "Connection closed by authenticating user"

1Check .ssh directory and file permissions on the server

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

bash
# 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:

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

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

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

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

2Check home directory permissions

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

bash
# 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:

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

Verify:

bash
ls -ld ~
# Now should show drwxr-xr-x (755) or more restrictive
3Verify user's login shell is valid

Check that your login shell exists and is executable:

bash
# 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:

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

Verify the shell exists:

bash
ls -l /bin/bash  # Should exist and be executable
4Run sshd in debug mode to see detailed error messages

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

bash
# 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:

bash
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:

bash
sudo systemctl start ssh
# or: sudo systemctl start sshd
5Review and fix PAM configuration if needed

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

bash
# 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:

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

On RHEL/CentOS/Fedora:

bash
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.

6Check for incompatible SSH key types on newer systems

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

bash
# 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:

bash
sudo nano /etc/ssh/sshd_config

Add or uncomment:

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

Then restart sshd:

bash
sudo systemctl restart ssh

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

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

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

7Verify authorized_keys file content and remove bad entries

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

bash
# 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:

bash
# 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:

bash
# 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.

8Check for shell configuration issues

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

bash
# 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:

bash
# 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:

bash
# 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

Advanced notes

Advanced debugging and edge cases:

Using SSH Verbose Output: On your client machine, connect with verbose flags to see the negotiation process:

bash
ssh -vvv username@host
# -v: verbose
# -vv: very verbose
# -vvv: maximum verbosity

Look for where the output stops—this indicates where the disconnect happens.

Encrypted Filesystems: If your home directory or ~/.ssh is on an encrypted filesystem (encfs, eCryptfs), the SSH server may not be able to access the keys even if permissions look correct. Consider moving .ssh to an unencrypted partition or disabling filesystem-level encryption for that directory.

Firewall/iptables Rules: Some systems have iptables rules that reset SSH connections after authentication. Check for stateful firewall rules that might be interfering:

bash
sudo iptables -L -n | grep ssh
# Or with nftables:
sudo nft list ruleset

SELinux Policies: On RHEL/CentOS systems with SELinux enabled, SSH connection issues can be caused by restrictive SELinux policies. Check if SSH is generating policy violations:

bash
sudo grep sshd /var/log/audit/audit.log | grep denied

If you see denials, you may need to adjust SELinux policies or use restorecon to reset file contexts.

Duo Security and MFA: If Duo Security or other MFA systems are configured, they can cause unexpected disconnections. Check /etc/pam.d/sshd for MFA configuration and temporarily disable it to test if that's the cause.

Connection Limits: Some SSH configurations have per-user connection limits. If you've exceeded the limit, connections are closed after authentication:

bash
# In /etc/ssh/sshd_config, look for:
MaxAuthTries
MaxSessions

Frequently asked questions

What does "Connection closed by authenticating user" mean?
The "Connection closed by authenticating user" error appears after successful authentication (your credentials were accepted) but before a shell session is established. This happens when the SSH server receives valid credentials, verifies them successfully, but then abruptly closes the connection. This is different from authentication failures—the server verified you are who you claim to be, but something prevents the session from continuing.
How do I fix "Connection closed by authenticating user"?
This error occurs when SSH authentication succeeds but the session is immediately terminated by the server after the user authenticates. It typically indicates file permission issues, configuration problems, or incompatible authentication settings between client and server.
What causes "Connection closed by authenticating user"?
Incorrect file permissions on ~/.ssh directory (should be 700) or ~/.ssh/authorized_keys (should be 600) Home directory has group write permissions (group or others writable when they shouldn't be) PAM (Pluggable Authentication Modules) configuration errors after system updates
Is the "Connection closed by authenticating user" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading