Key-based login to web01 fails and the server's log records: `Authentication refused: bad ownership or modes for directory /home/dev/.ssh`. Which fix is the right one?
LPIC-1 Exam 102-500, objective 110. Security hard
Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.
Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
The options
Not correct chmod 777 /home/dev/.ssh
Wrong, and it makes the failure permanent. sshd rejects the directory precisely because it is group- or world-writable; 777 is the most writable mode there is.
Correct chmod 700 /home/dev/.ssh and chmod 600 /home/dev/.ssh/authorized_keys, with both owned by dev.
Correct. sshd requires that ~/.ssh and authorized_keys be owned by the user (or root) and not writable by group or others. The home directory itself must also not be group- or world-writable.
Not correct chmod 644 ~/.ssh/id_ed25519 on the laptop.
Wrong twice over. The message concerns a directory on the server, not the client's key, and making a private key world-readable causes ssh to refuse to use it with 'UNPROTECTED PRIVATE KEY FILE'. Private keys belong at 600.
Not correct Set `StrictModes yes` in /etc/ssh/sshd_config and restart sshd.
Wrong. StrictModes yes is already the default and is the very check producing this message. Setting it to no would silence the complaint while leaving the insecure permissions in place.
Why
sshd's StrictModes check exists because a world-writable ~/.ssh lets any local user append their own key to authorized_keys and become you. The conventional layout is home directory 755 or stricter, ~/.ssh 700, authorized_keys 600, private keys 600 and public keys 644. This failure is silent on the client, which simply falls back to the next authentication method and asks for a password, so the server log is the only place the reason appears.
Where this comes from
- Cited
- manual page sshd(8)
- What it says
- StrictModes checks file modes and ownership of the user's files and home directory before accepting login.
Practise this
Reading one question is not practice. The trainer will draw a short set from objective 110 and space the ones you get wrong.
More questions on this objective
- During an audit you must list every file under /usr that has the set-user-ID bit set, regardless of what its other permission bits are. Which command does that? machine-checked
- You locked the password of the account `intern` and confirmed that its hash in /etc/shadow now begins with an exclamation mark. The intern nevertheless still reaches a shell on the host over SSH, without being prompted for anything. What is going on, and what actually stops it? machine-checked
- You have just been added to a sudo rule on a host and want sudo itself to report which commands you are allowed to run there, without running any of them. Type the complete command. machine-checked
- A daemon started from your bash session keeps hitting a 'too many open files' error. Which command raises the limit on open file descriptors for the current shell and the processes it starts to 4096? machine-checked
- You are about to take a server down for maintenance and want ordinary users refused at login for the next hour, with an explanatory message, while root can still get in. On a system using PAM's pam_nologin, creating which file achieves this? machine-checked
- Which two commands report the users who are logged in right now, rather than a history of past logins? (Choose two.) machine-checked