SSH connection fails with 'Permission denied (publickey,keyboard-interactive)' when the server rejects both public key and keyboard-interactive authentication methods. This typically indicates missing keys, incorrect permissions, or server configuration issues.
This error occurs when SSH attempts to authenticate using public key cryptography (the most secure method) and falls back to keyboard-interactive authentication (prompting for a password or challenge), but both methods fail. The error message tells you which authentication methods were tried and rejected. Public key authentication is the primary method, while keyboard-interactive is a secondary fallback. If both fail, your connection is rejected entirely.
First, check that you have SSH keys generated on your local machine:
ls -la ~/.ssh/You should see files like id_rsa (private key) and id_rsa.pub (public key). If these files don't exist, generate a new SSH key:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N ""This creates a 4096-bit RSA key pair without a passphrase (use a passphrase for security).
Incorrect permissions on your private key will cause SSH to refuse it. Set the correct permissions:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pubVerify the permissions:
ls -la ~/.ssh/You should see:
- drwx------ (700) for the ~/.ssh directory
- -rw------- (600) for id_rsa
- -rw-r--r-- (644) for id_rsa.pub
Your public key must be on the server in the authorized_keys file. The easiest way is using ssh-copy-id:
ssh-copy-id -i ~/.ssh/id_rsa.pub username@remote-hostIf ssh-copy-id is not available, manually copy the key:
cat ~/.ssh/id_rsa.pub | ssh username@remote-host 'cat >> ~/.ssh/authorized_keys'Replace username with your actual username and remote-host with the server address.
Log into the server (if possible with a different method) and check permissions:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys.d/*Verify:
ls -la ~/.ssh/The ~/.ssh directory should be 700, and authorized_keys should be 600. Incorrect permissions are a common cause of this error.
On the server, check that your public key is in the authorized_keys file:
cat ~/.ssh/authorized_keysYou should see your public key content (starts with 'ssh-rsa' or 'ssh-ed25519'). If it's not there, add it:
echo 'your-public-key-content' >> ~/.ssh/authorized_keysYou can also verify by comparing fingerprints. On your client:
ssh-keygen -lf ~/.ssh/id_rsa.pubOn the server:
ssh-keygen -lf ~/.ssh/authorized_keysThe fingerprints should match.
Log into the server and check /etc/ssh/sshd_config:
sudo nano /etc/ssh/sshd_configEnsure these settings are present and uncommented (no # at the start):
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
KbdInteractiveAuthentication yesFor older SSH versions, use ChallengeResponseAuthentication yes instead of KbdInteractiveAuthentication. After making changes, reload SSH:
sudo systemctl restart sshdOr:
sudo service ssh restartRun SSH with verbose mode to see exactly where authentication fails:
ssh -vvv username@remote-hostLook for lines like:
- Trying private key - shows which keys are being tried
- Authentications that can continue - lists methods the server accepted
- Permission denied - where the failure occurs
Verbose output will tell you whether the issue is with key matching, permissions, or server configuration.
Verify your SSH agent is running and has the key loaded:
eval "$(ssh-agent -s)"
ssh-add -lThis should list your key with its fingerprint. If nothing is listed, add your key:
ssh-add ~/.ssh/id_rsaFor macOS, use:
ssh-add --apple-use-keychain ~/.ssh/id_rsaIf your key has a passphrase, you'll be prompted to enter it.
If you're still unable to connect after checking permissions and configuration, consider these advanced issues:
SELinux/AppArmor: On systems with SELinux or AppArmor enabled, these security modules may block SSH authentication. Check logs with sudo tail -f /var/log/auth.log (Ubuntu/Debian) or /var/log/secure (RHEL/CentOS).
SSH Key Format: Older OpenSSH versions may not support newer key formats. If generating keys, use ssh-keygen -t rsa for maximum compatibility, or use ED25519 (ssh-keygen -t ed25519) for newer systems.
SSH Subsystem Configuration: Some servers use restricted shells or SFTP-only accounts. Check sshd_config for Subsystem settings that might prevent interactive login.
PAM Configuration: If using keyboard-interactive authentication, PAM (Pluggable Authentication Modules) must be properly configured. This is typically handled automatically but may need adjustment on custom systems.
SSH Port: Verify you're connecting to the correct SSH port (default 22). If the server uses a different port, use ssh -p PORT username@host.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH