Why ssh keeps asking for a password after adding a key and how to correct the PubkeyAuthentication setting -

Why SSH Still Asks for a Password After Adding a Key

Adding a public key to ~/.ssh/authorized_keys is the first step toward password‑less login, but the SSH daemon can still fall back to password authentication for a handful of reasons. The most common culprit is a mis‑configured PubkeyAuthentication setting in /etc/ssh/sshd_config or a permissions problem that causes the server to ignore the key file.

1. Verify the Key Is Accepted by the Server

# On the client
ssh -vvv user@host

The -vvv flag prints the entire authentication dance. Look for lines like:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Authentication succeeded (publickey).

If you see Authentication succeeded (publickey) the key is fine; the problem lies elsewhere. If the client immediately falls back to password, the server is rejecting the key.

2. Common Causes of Rejection

Cause	Why it happens	Fix
`PubkeyAuthentication no` in `sshd_config`	The daemon is explicitly told to ignore public keys.	Set to `yes`.
`AuthorizedKeysFile` points to a non‑existent file	The daemon looks in the wrong place.	Correct the path or use the default `~/.ssh/authorized_keys`.
File or directory permissions are too open	SSH refuses keys if the key files can be read by others.	`chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys`.
`PasswordAuthentication yes` and `ChallengeResponseAuthentication yes`	The server offers password auth first, and the client may try it before keys.	Disable password auth if you only want key‑based login: `PasswordAuthentication no`.
SELinux or AppArmor blocks access	Security modules can prevent SSH from reading the key.	Adjust the policy or temporarily disable the module to test.

3. Correcting `PubkeyAuthentication`

Open the configuration file with a text editor you trust:
```
sudo nano /etc/ssh/sshd_config
```
Search for PubkeyAuthentication. If the line is commented out (#PubkeyAuthentication yes) or set to no, change it to:
```
PubkeyAuthentication yes
```
If the line is missing, add it under the # Authentication: section.
Save the file and reload the daemon:
```
sudo systemctl reload sshd
```
On systems that use sshd directly:
```
sudo service ssh reload
```
Test again with ssh -vvv. The key should now be accepted.

4. Double‑Check Permissions

# On the server
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

If the home directory is group‑writeable or world‑readable, SSH will reject the key. The same applies to the parent directories up to the root of the filesystem.

5. Security Considerations

Disable password authentication once key‑based login works. It removes the risk of brute‑force password attacks.
```
PasswordAuthentication no
```
Use a strong key type. Ed25519 is recommended for its speed and security.
```
ssh-keygen -t ed25519 -C "user@host"
```
Enable PermitRootLogin no unless you have a specific need for root SSH access.
Consider AllowUsers or AllowGroups to restrict who can log in.

6. Quick Checklist

PubkeyAuthentication yes in /etc/ssh/sshd_config
Correct AuthorizedKeysFile path
chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys
PasswordAuthentication no (if desired)
Reload sshd after changes
Verify with ssh -vvv

7. Useful References

Arch Linux wiki on SSH public‑key authentication: https://wiki.archlinux.org/title/SSH#Public_key_authentication
Debian manual on SSH configuration: https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#sshd
systemd’s SSH service documentation: https://systemd.io/SSH