How to fix Permission denied (publickey,keyboard-interactive). in SSH

Before changing anything, run SSH in verbose mode to see exactly which keys are offered and where the server rejects them:

ssh -vvv username@remote-host

Key lines to look for:
- Offering public key: / Will attempt key: — which keys the client is trying
- Authentications that can continue: publickey,keyboard-interactive — the methods the server still accepts
- Permission denied (publickey,keyboard-interactive). — the final rejection

If your key is never offered, the problem is client-side (missing key, agent, or IdentitiesOnly). If it is offered but rejected, the problem is server-side (authorized_keys content or permissions). This tells you which of the steps below to focus on.

Check that you have an SSH key pair on your local machine:

ls -la ~/.ssh/

You should see a private key and matching public key, e.g. id_ed25519 / id_ed25519.pub or id_rsa / id_rsa.pub. If you have none, generate a key (Ed25519 is preferred on modern systems):

ssh-keygen -t ed25519 -C "[email protected]"

For maximum compatibility with very old servers, use RSA with a strong size:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Use a passphrase when prompted; it protects the key at rest and can be cached by your agent so you are not prompted every time.

OpenSSH refuses to use a private key whose permissions are too open. Tighten them:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

(Use the actual key filenames you found above.) Verify:

ls -la ~/.ssh/

Expected:
- drwx------ (700) for the ~/.ssh directory
- -rw------- (600) for the private key
- -rw-r--r-- (644) for the .pub file

Your public key must be listed in ~/.ssh/authorized_keys on the server for the account you are logging into. The simplest way (when you can still authenticate by another method, e.g. password) is:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@remote-host

If ssh-copy-id is unavailable, append the key manually. Note that ssh-copy-id and this command also create ~/.ssh and authorized_keys with correct permissions if missing:

ssh username@remote-host "umask 077; mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" < ~/.ssh/id_ed25519.pub

Replace username and remote-host accordingly.

Log into the server (using any method that works) and ensure the SSH directory and authorized_keys are not too open. sshd's StrictModes will silently ignore authorized_keys if these are group- or world-writable:

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

The home directory itself must also not be group- or world-writable. Check it and tighten only if needed:

ls -ld ~
# if it is group/other writable, remove that write bit:
chmod go-w ~

Verify the results:

ls -la ~/.ssh/

The ~/.ssh directory should be 700 and authorized_keys should be 600, owned by your user. Incorrect permissions here are one of the most common causes of this error.

On the server, confirm the exact key you are using is present:

cat ~/.ssh/authorized_keys

Each entry is a single long line starting with the key type (ssh-ed25519, ssh-rsa, ecdsa-sha2-...). A frequent mistake is a public key split across multiple lines by a copy/paste — each key must be exactly one line.

To confirm the key on the server matches your local key, compare fingerprints. On your client:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

On the server, run ssh-keygen -lf against the authorized_keys file; it prints one fingerprint per line, one for each authorized key:

ssh-keygen -lf ~/.ssh/authorized_keys

Your client's fingerprint should appear in that list.

If you have many keys, SSH may exhaust the server's MaxAuthTries by offering the wrong keys before reaching the correct one, producing this error even though a valid key exists. Force SSH to use only the key you specify:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 username@remote-host

Make it permanent in ~/.ssh/config:

Host myserver
    HostName remote-host
    User username
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Then connect with ssh myserver. IdentitiesOnly yes stops the client and agent from blindly offering every key.

If your key is never offered in the -vvv output, your agent may not have it loaded. Start the agent and list loaded keys:

eval "$(ssh-agent -s)"
ssh-add -l

If the key is missing, add it (you will be prompted for the passphrase if it has one):

ssh-add ~/.ssh/id_ed25519

On macOS, store the passphrase in the keychain so it loads automatically:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

If permissions and authorized_keys are correct but key auth is still rejected for everyone, inspect the server's sshd config. Edit /etc/ssh/sshd_config (and any drop-ins under /etc/ssh/sshd_config.d/):

sudo nano /etc/ssh/sshd_config

Ensure these are present and not commented out:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
KbdInteractiveAuthentication yes

On older OpenSSH releases the keyboard-interactive directive is named ChallengeResponseAuthentication yes. Validate the config before applying it so a typo cannot lock you out:

sudo sshd -t

If it reports no errors, reload sshd (keep your current session open until you confirm a new login works):

sudo systemctl reload sshd

On systems without systemd:

sudo service ssh reload