The server web01 was rebuilt from scratch and keeps its old address. Your next ssh web01 aborts with a warning that the remote host identification has changed and refuses to continue. Which command removes just the stale entry from your ~/.ssh/known_hosts?
LPIC-1 Exam 102-500, objective 110. Security medium
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
Correct ssh-keygen -R web01
Correct. -R removes every key belonging to the named host from known_hosts, keeping a backup as known_hosts.old. It works even when the file has hashed host names, which plain editing makes hard.
Not correct ssh-keygen -F web01
Wrong. -F searches known_hosts and prints the matching line, which is useful for confirming what is stored, but it deletes nothing.
Not correct ssh-keygen -l -f ~/.ssh/known_hosts
Wrong. -l -f prints the fingerprints of the keys in the file so you can compare them with the fingerprint the server shows. The file is left unchanged.
Not correct rm /etc/ssh/ssh_host_ecdsa_key*
Wrong, and aimed at the wrong machine. Those are a server's own host keys. Deleting them on your workstation touches its identity as a server, and on web01 it would only give the clients a third key to argue about.
Why
The client stores each server's public host key in ~/.ssh/known_hosts, or system-wide in /etc/ssh/ssh_known_hosts, and refuses to connect when the presented key differs, since that is what a man-in-the-middle attack looks like. After a legitimate rebuild the fix is to delete the recorded key with ssh-keygen -R and then verify the new fingerprint out of band on first connection. Suppressing the check with StrictHostKeyChecking no discards the protection instead of resolving it.
Where this comes from
- Cited
- manual page ssh-keygen(1)
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