Problem: "UNPROTECTED PRIVATE KEY FILE" / "Permissions 0644 are too open" — ssh login refused —— Trove problem library

What you will run into

Logging in with ssh -i private-key prints a screenful of WARNING: UNPROTECTED PRIVATE KEY FILE!, Permissions 0644 for '/path/id_rsa' are too open, ending in Permission denied (publickey).

The key file itself is fine and you changed nothing — it's just that the file permissions are too open and OpenSSH refuses it.

Common when the key came from an archive/cloud drive, was generated by a Windows tool (0644), or lives on a WSL-mounted Windows drive (chmod looks effective but isn't).

Why this happens

OpenSSH's client enforces when loading a private key: the key must not be readable by other users/groups (600/700 level).

If group/other has read permission (644/640/664 etc.), it ignores the key and refuses to authenticate with it — a security design against key leakage, not a fault.

• Note the check triggers at the authentication stage (a TCP connection must be established first), so you won't see this warning when you can't reach the server.
• Keys on /mnt/c in WSL: the drvfs filesystem doesn't support chmod; chmod 600 looks effective but isn't — copy the key into WSL first, or fix it with icacls on the Windows side.

During authentication, the OpenSSH client enforces private-key file permissions: if group/other can read the key (644/640/664 etc.) it silently ignores that key (Load key ... bad permissions) — a security design to prevent key leakage, not a fault:

a private key is a password, and a password readable by everyone is no password.

The check happens at the authentication stage (after TCP is established), so you will not see the warning when the server is unreachable.

On WSL mount drives (/mnt/c), drvfs does not support chmod: chmod 600 looks successful but does nothing (the file stays exposed per mount defaults).

Deterministic takeaway: Load key ... bad permissions = wrong mode — chmod 600 ~/.ssh/id_xxx fixes it (the directory should be 700 too); in WSL, keep keys under ~/.ssh/ (the WSL filesystem), not /mnt/c; ssh -v shows the detailed loading process to pinpoint "ignored" causes;

fixed diagnostic: the warning appears at the authentication stage = permission problem, not network/server.

Step by step

1. Confirm it's a permission issue — Required

ls -l ~/.ssh/id_ed25519

Permissions -rw-r--r-- (644) or -rw-r----- (640) → that's the problem (measured: both 644 and 640 trigger the warning, exit 255).

2. Fix the private key permissions — Required

chmod 600 ~/.ssh/id_ed25519

Public keys can stay 644; ~/.ssh itself shouldn't be 777 (chmod 700 ~/.ssh).

3. Keys from Windows tools / WSL mounted drives — Required

• WSL accessing a key on /mnt/c: cp it into WSL first (e.g. ~/.ssh/) then chmod 600;
• Native Windows OpenSSH: icacls "<key path>" /inheritance:r /grant:r "%USERNAME%:R";
• Tool-generated temp keys (az bastion ssh etc. /tmp keys): chmod 600 before use.

4. Batch-fix caution — Required

chmod 600 ~/.ssh/* would also hit public keys (600 on a public key is fine, just unnecessary); be precise and only change files without .pub.

How to confirm it works

ssh -i ~/.ssh/id_ed25519 user@host

No more UNPROTECTED PRIVATE KEY FILE warning and a successful key login means it's fixed. Measured: private key 600 → login success (exit 0); 644/640 → warning + Permission denied (exit 255); back to 600 → restored.

Other environments

Symptom

Full-screen warning when using ssh -i private-key:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/path/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/path/id_rsa": bad permissions
root@host: Permission denied (publickey,keyboard-interactive).

Key traits: the key itself is fine — ssh rejects the file permissions (group/other readable); common with keys copied from archives/cloud drives, keys generated by Windows tools (azure-cli-extensions#6408: a tool generating 0644 keys), or keys on Windows drives mounted in WSL (where chmod does not work).

Cause

The OpenSSH client enforces: private keys must not be readable by group/other users (600/700 level). If group/other have read bits (644/640/664 etc.), the key is ignored and authentication fails — this is a security design, not a bug. Note: the check only runs at the authentication stage (after the TCP connection), so you will not see it when the server is unreachable.

Solution

1. Fix permissions (Linux/macOS/WSL): chmod 600 ~/.ssh/id_ed25519 (private), chmod 644 public key, chmod 700 ~/.ssh;
2. Windows native OpenSSH: chmod is not applicable — use icacls "key-path" /inheritance:r /grant:r "%USERNAME%:R";
3. Keys on /mnt/c in WSL: drvfs ignores chmod (it looks effective but is not) —

copy the key into WSL (cp + chmod 600) or fix it Windows-side with icacls;

1. Tool-generated temp keys (az bastion ssh / CLI /tmp keys): chmod 600 before use, or report the tool bug (#6408 scenario);
2. Check parent directories: ~/.ssh itself must not be 777 (chmod 700 ~/.ssh);
3. Batch fix: chmod 600 ~/.ssh/* also hits public keys (644 is fine for them; 600 harmless) — to be precise, only change files without .pub.