known_hosts vs authorized_keys: 34 Probes on a Spare sshd

At 21:10 KST on September 17, one of my probe commands on this Mac mini failed to log in and still changed a file in ~/.ssh. The command was ssh -o BatchMode=yes -o StrictHostKeyChecking=no localhost 'echo ok'. It printed two lines: Warning: Permanently added 'localhost' (ED25519) to the list of known hosts. and then Permission denied (publickey,password,keyboard-interactive). The login failed and the host key was saved anyway. My ops log for that run blamed BatchMode for the write, which was also wrong. Five days earlier a similar command without StrictHostKeyChecking=no had stopped at Host key verification failed. and written nothing.

Those two outputs are the whole known_hosts vs authorized_keys question in small. One file is checked on the client before any login happens. The other is checked on the server during login. I wanted to know exactly what writes each file, what gets checked, and what each failure looks like. So I started a spare sshd on a loopback port and ran 34 probes against it without touching my real ~/.ssh.

The difference in one table

known_hosts lives on the machine you connect from. It holds the server's host public keys, and ssh uses it to decide whether the server is the same one you talked to last time. authorized_keys lives on the machine you connect to. It holds the users' public keys, and sshd uses it to decide whether you may log in. The sshd(8) manual documents both file formats on one page.

	known_hosts	authorized_keys
Machine	Client	Server
Contains	Server host public keys	Users' public keys, optionally with options
Read by	ssh	sshd
Written by	ssh, automatically, depending on StrictHostKeyChecking	Nothing automatic. You, ssh-copy-id, or config management
Checked when	Key exchange, before login	User authentication
Failure message	Host key verification failed.	Permission denied (publickey), with the reason only in the server log
Mode 0666 in my probes	Accepted	0664 refused

The lab

The machine is macOS 26.4.1 with Apple's OpenSSH 10.2p1 for both ssh and /usr/sbin/sshd. A non-root sshd can serve logins for the user who started it, so I ran one on 127.0.0.1:2222 with throwaway host keys and its own AuthorizedKeysFile. Every client call used -F /dev/null and a scratch known_hosts file:

/usr/sbin/sshd -D -e -f sshd_a.conf     # Port 2222, ListenAddress 127.0.0.1,
                                        # HostKey hk_a, AuthorizedKeysFile ak,
                                        # PasswordAuthentication no, StrictModes yes
ssh -F /dev/null -o UserKnownHostsFile=kh2 -o GlobalKnownHostsFile=/dev/null \
    -o IdentitiesOnly=yes -i id_lab -o BatchMode=yes \
    -o StrictHostKeyChecking=accept-new -p 2222 127.0.0.1 'echo LOGIN_OK'

My first attempt failed on every login, and the reason was the lab itself. I had put it under /tmp, and the server log said Authentication refused: bad ownership or modes for directory /private/tmp. That directory is mode 1777, and StrictModes checked the directories above authorized_keys as well as the file. After a few failures, later connections died with Connection closed by 127.0.0.1 port 2222 before authentication. That was a second server feature, covered further down. I moved the lab to ~/work/sshlab and turned penalties off for the main runs.

known_hosts: what the probes showed

Situation	ask (default)	accept-new	no
New host, BatchMode	Refused, nothing written	Written, login proceeds	Written, login proceeds
New host, login then fails	n/a	Written anyway	Written anyway
Host key changed	Refused, exit 255	Refused, exit 255	Logged in with the key; password auth disabled

The last cell is the one that matters for scripts. With the server restarted on a different host key, StrictHostKeyChecking=no printed the full REMOTE HOST IDENTIFICATION HAS CHANGED! banner, then Password authentication is disabled to avoid man-in-the-middle attacks., then ran my command and exited 0. Key-based login went ahead against a host that had just failed verification. It didn't update the stored key, so every later run would print the same banner and carry on. The ssh_config manual says this plainly: with no, connections to hosts with changed keys "proceed, subject to some restrictions." The OpenSSH 7.6 release notes from 2017 added accept-new and said "A future release will change the meaning of StrictHostKeyChecking=no to the behaviour of accept-new." On 10.2p1 that change still hasn't happened.

The other known_hosts results, briefly:

• Non-standard ports are stored as [127.0.0.1]:2222. ssh-keygen -R 127.0.0.1 answered Host 127.0.0.1 not found. ssh-keygen -R "[127.0.0.1]:2222" removed the line and kept a .old copy.
• UserKnownHostsFile=/dev/null only works with a policy that accepts new keys. With the default ask and BatchMode it failed on every connect. With accept-new it printed "Permanently added" each time and saved nothing.
• known_hosts2 is still read. On this Mac, ssh -G shows ~/.ssh/known_hosts ~/.ssh/known_hosts2. A key present only in the second file was accepted, and nothing was copied to the first.
• Hashed entries hide from grep. With HashKnownHosts=yes the line began |1|, grep -c 127.0.0.1 returned 0, and ssh-keygen -F "[127.0.0.1]:2222" found it. macOS defaults to hashknownhosts no.
• A second host key arrives on the second connection. The server had ed25519 and RSA keys. The first connect saved one line. The second, with UpdateHostKeys=yes, printed Learned new hostkey: RSA. That setting is on by default only while UserKnownHostsFile is left at its default, and it never ran after a failed login.

authorized_keys: what the probes showed

Every failure below looked the same from the client: Permission denied (publickey). The server log was the only place with a reason, and for three of them it gave none.

Change to authorized_keys	Login	sshd log (LogLevel VERBOSE)
File mode 0664	Refused	bad ownership or modes for file
File mode 0644	OK
Parent directory 0775	Refused	bad ownership or modes for directory
File under /tmp	Refused	... for directory /private/tmp
Windows CRLF line ending	OK
Previous key had no trailing newline, new key appended	Refused	Failed publickey only
Host name in front of the key, known_hosts style	Refused	Failed publickey only
Server's host key pasted in by mistake	Refused	Failed publickey only
from="10.9.9.9"	Refused	Refused by key options at ak:1
command="echo RESTRICTED"	Runs that command instead	forced-command (key-option)

The missing-newline case is the one I would have missed. The file had two keys but one line, so wc -l said 1 and the good key was glued to the end of the bad one. StrictModes is on by default per the sshd_config manual, and on my Mac the stock /etc/ssh/sshd_config leaves it commented at its default.

The retry trap: PerSourcePenalties

OpenSSH 9.8 made the server block addresses that fail authentication repeatedly, on by default. Defaults are 5 seconds per failed-auth disconnect, nothing enforced until 15 seconds accrue, and a 10-minute cap. With penalties back on, three wrong-key attempts followed by the right key logged in. Four wrong attempts took the total to 20 seconds, and the right key then failed for about 20 seconds: first exit 255 with no message, then kex_exchange_identification: read: Connection reset by peer three times, then success at +21 seconds. If you fix authorized_keys and retry within seconds, that reset looks like the fix broke something.

What 600 Stack Exchange questions ask

I pulled every question with known_hosts or authorized_keys in the title from Stack Overflow, Server Fault, Super User, Unix & Linux and Ask Ubuntu through the Stack Exchange API: 260 known_hosts titles and 347 authorized_keys titles, 600 unique questions. A keyword pass on titles, so the counts are lower bounds, put 70 of the known_hosts questions under adding a host or skipping the prompt and 32 under changed keys and removing entries. For authorized_keys, 88 were a key that is ignored or a password prompt that won't go away. The most-viewed of those, "Adding a public key to ~/.ssh/authorized_keys does not log me in automatically", has 752,448 views. The direct comparison, "known_hosts vs authorized_keys" on Unix & Linux, has 140,601. Only 7 of the 600 titles name both files.

What I use now

This machine runs headless and I reach it over Tailscale SSH, so a broken authorized_keys means a trip to the hardware. The FileVault lockout showed that authorized_keys isn't even readable until the data volume unlocks. For unattended scripts I now use StrictHostKeyChecking=accept-new: it answers the first-connect prompt that BatchMode can't, and it still refuses a changed key. I no longer use no. When a key login fails, I read the server log before changing modes, and I wait out any penalty before retrying. The stray localhost line from September 17 is still in my known_hosts; it's the key my own sshd presents, so it's correct. Agents that edit files under ~/.ssh are their own risk, which the GhostApproval write-up covers.

FAQ

What is the difference between known_hosts and authorized_keys?

known_hosts is on the client and lists servers' host public keys, so ssh can detect a server whose key has changed, while authorized_keys is on the server and lists users' public keys that may log in to that account. ssh writes known_hosts itself on first connect; nothing writes authorized_keys automatically.

How do I fix "REMOTE HOST IDENTIFICATION HAS CHANGED"?

First confirm the server's key really changed, for example after a reinstall. Then run ssh-keygen -R hostname, or ssh-keygen -R "[hostname]:port" for a non-22 port, and reconnect to accept the new key. Don't switch to StrictHostKeyChecking=no: in my test it logged in with a key despite the changed host key.

Why is my key in authorized_keys ignored?

Check the server log, not the client output. In my probes the causes were a group-writable file or parent directory, a file under /tmp, two keys joined on one line because of a missing newline, a host name in front of the key, and a from= option that didn't match. After four failed attempts, OpenSSH 9.8 and later also block your address for about 20 seconds.

Update 2026-09-18: I measured the penalty separately in kex_exchange_identification: Connection reset by peer. Twelve failures at once blocked my address for 55.7 seconds, and 18 bare port checks in a row were enough to trigger it.

Sources and method: the two incidents come from this Mac mini's Claude Code session transcripts for September 12 and 17, 2026. The probes ran on September 18 between 12:02 and 12:16 KST on macOS 26.4.1 (25E253) with OpenSSH_10.2p1: a non-root sshd on 127.0.0.1:2222, throwaway host and client keys, scratch known_hosts files, and -F /dev/null on the client. Counting cases across four runs gives 34. My real ~/.ssh files were not modified. Password and PAM logins, Linux builds, root-owned sshd and ssh-agent weren't tested. Option behavior is quoted from the OpenBSD manual pages and the 7.6 and 9.8 release notes. The Stack Exchange counts come from the API's title search on five sites, fetched September 18. The buckets use keyword matching on titles, so they undercount. There are no affiliate links in this post.