Fix SSH Disconnected: No Supported Authentication Methods (2026)

SSH is giving you the classic "Disconnected: No supported authentication methods" error because the SSH client and server have a fundamental disagreement about how to prove your identity.

Here’s what’s actually breaking: The SSH client on your machine initiated a connection to the SSH server on the remote host. During the authentication phase, the client presented a list of authentication methods it supports (like password, public key, etc.), and the server responded that none of those methods are acceptable for the user you’re trying to log in as. This isn’t a network issue; it’s a credential and configuration mismatch.

Common Causes and Fixes:

1. Incorrect Username: The most frequent culprit. You’re trying to log in with a username that doesn’t exist on the remote server or isn’t configured for SSH access.

   • Diagnosis: On the remote server, run grep -i "^\s*[^#]*\s*\(AllowUsers\|AllowGroups\|DenyUsers\|DenyGroups\)" /etc/ssh/sshd_config. This shows you which users or groups are explicitly allowed or denied SSH access. Also, try id <your_username> on the server to see if the user exists.
   • Fix: Ensure you’re using the correct username. If the user doesn’t exist, you’ll need to create it on the server (sudo adduser <new_username>) or log in with an existing, valid username.
   • Why it works: SSH authentication requires a valid user account on the server. If the username is wrong, the server can’t find an account to authenticate against.

2. Public Key Authentication Misconfiguration (Client-Side): Your ~/.ssh/config file might be pointing to the wrong private key, or the key itself might have incorrect permissions.

   • Diagnosis: Check your ~/.ssh/config file for IdentityFile directives. Ensure the path points to your private key. On your client machine, run ls -l ~/.ssh/your_private_key and chmod 600 ~/.ssh/your_private_key.
   • Fix: Correct the IdentityFile path in ~/.ssh/config or ensure your private key has read-only permissions for your user (chmod 600 ~/.ssh/your_private_key).
   • Why it works: The SSH client needs to present the correct private key to the server to match the public key authorized for login. Incorrect permissions prevent the client from reading the private key.

3. Public Key Authentication Misconfiguration (Server-Side): The remote server doesn’t have your public key in the correct authorized_keys file, or the file/directory permissions are wrong.

   • Diagnosis: On the server, check ~/.ssh/authorized_keys for the user you’re trying to log in as. Ensure your public key (the .pub file) is correctly appended on a single line. Check permissions: ls -ld ~, ls -ld ~/.ssh, ls -l ~/.ssh/authorized_keys. They should be drwxr-xr-x (755) for ~ and ~/.ssh, and -rw-r--r-- (644) for authorized_keys. The user’s home directory should not be writable by others.
   • Fix: Copy your public key to the server’s ~/.ssh/authorized_keys file. Use ssh-copy-id user@remote_host for simplicity. If manual, ensure permissions are correct: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, and chown -R $(whoami):$(whoami) ~/.ssh.
   • Why it works: The server checks authorized_keys to see if your public key is listed as an allowed method for authentication. Incorrect permissions prevent the SSH daemon (sshd) from reading this file securely.

4. sshd_config Disabling Password or Public Key Auth: The SSH server configuration on the remote host explicitly disallows the authentication methods you’re attempting to use.

   • Diagnosis: On the server, examine /etc/ssh/sshd_config. Look for PasswordAuthentication and PubkeyAuthentication directives.
   • Fix: If PasswordAuthentication is set to no, and you want to use passwords, change it to yes. If PubkeyAuthentication is set to no, and you want to use keys, change it to yes. Important: After changing sshd_config, restart the SSH service: sudo systemctl restart sshd or sudo service ssh restart.
   • Why it works: These directives are the master switches on the server. If they’re off, the server won’t even consider those methods.

5. SELinux/AppArmor Restrictions: Security modules like SELinux or AppArmor on the server might be preventing sshd from accessing necessary files (like authorized_keys) or performing authentication.

   • Diagnosis: On the server, check audit logs: sudo ausearch -m avc -ts recent for SELinux, or check /var/log/audit/audit.log. For AppArmor, check sudo dmesg or /var/log/syslog.
   • Fix: This is highly environment-specific. For SELinux, you might need to restore context: sudo restorecon -Rv ~/.ssh. For AppArmor, you might need to adjust profiles. Consult your distribution’s documentation for specific SELinux/AppArmor troubleshooting.
   • Why it works: These security layers enforce strict rules on what processes can access. If sshd is denied access to user files due to policy, authentication will fail.

6. User’s Home Directory Permissions: If the user’s home directory on the server is writable by others (e.g., drwxrwxrwx), SSH will refuse to work for security reasons.

   • Diagnosis: On the server, run ls -ld ~ for the user you’re trying to log in as. It should not have the 'w' bit set for group or others.
   • Fix: Correct the permissions: chmod go-w ~.
   • Why it works: SSH daemon requires the user’s home directory to be secure and not world-writable to prevent potential tampering with SSH configuration files.

After fixing any of these issues, you’ll likely be presented with the next common problem: "Permissions 0644 for '/home/user/.ssh/authorized_keys' are too open."