To help you understand how "known_hosts" and "authorized_keys" are different, here is some context explaining how they fit into "ssh".
While it has been said that public-key values "can be safely strewn about like seeds in the wind," keep in mind that it's the gardner, not the seed-pod, who decides which seeds are allowed to get established in the garden. Altough a public-key is not secret, fierce protection is required to preserve the trusted association of the key with the thing that the key is authenticating. Therefore, only selected keys get into places like "known_hosts", "authorized_keys", and "Certificate Authority" listings.
For a public-key to be relevant to "ssh," the key must be registered ahead of time, and stored in a secure file. (This general truth has one important exception, which will be discussed later.) The server and client each have their own securely stored list of public-keys; a login will succeed only if each side is registered with the other.
- "known_hosts" resides on the client
- "authorized_keys" resides on the server
The server's secure file is called "authorized_keys", and the client's secure file is called "known_hosts". These files are similar in that each has text with one public-key per line, but they have subtle differences in format and usage.
In "ssh", both sides (client and server) are suspicious of the other; this is an improvement over "telnet". With "telnet", the client provides a password to the server, but the server does nothing for the client. Because the server is not asked to prove its identity, a "man-in-the- middle" attack can occur, with catastrophic consequences to security. By contrast, in the "ssh" process, the client surrenders no information until the server first answers a challenge.
Given a public-private key pair, "ssh" can do "asymmetric cryptography." It uses asymmetric cryptography to pose the challenge "Are you really who I think you are?" i.e., authentication. (Note that asymmetric cryptogrophy is used only during the login phase; then "ssh" (TSL/SSL) switches to another form of encryption to handle the data stream.)
For "ssh", the public-key is used by the side making a challenge, and the private key is used by the side answering the challenge.
Before sharing any login information, the "ssh" client first eliminates the opportunity for a man-in-the-middle attack by challenging the server to prove "Are you really who I think you are?" To make this challenge, the client needs to know the public-key that is associated with the target server. The client must find the server's name in the "known_hosts" file; the associated public-key is on the same line, after the server name. The association between server-name and public-key must be kept inviolate; therefore permissions on the "known_hosts" file must be 600 -- nobody else can read or write.
Once the server has authenticated, it gets a chance to challenge the
client. The server asks "what public key do you propose should be used
to prove your identity?" Of course, the client could send any public-key;
this is where the secure "authorized_keys" file comes into play.
The server compares the proposed public-key to the values in the
"authorized_keys" list and proceeds with asymmetric cryptography
only if the key is found. (When not found, the "sshd" process
falls-back on password style authentication.)
So for "ssh", as with any login process, there are lists of "friends", and only those on the list are allowed to attempt to pass a challenge. For the client, the "known_hosts" file is a list of friends who can act as servers (hosts); these are listed by name. For the server, the equivalent list of friends is the "authorized_keys" file; but there are no names in that file, since the public-keys themselves act like identifiers. (The server doesn't care where the login is coming from, but only where it's going. The client is attempting to access a particular account, the account name was specified as a parameter when "ssh" was invoked. Remember that the "authorized_keys" file is specific to that account, since the file is under that account's home directory.)
In both cases, if the public key is not found within a secure file, then assymetric encryption does not happen. As mentioned earlier, there is one exception to this rule. A user is allowed to knowingly choose to risk the possibility of a man-in-the-middle attack by logging into a server that is not listed in the user's "known_hosts" file. The "ssh" program warns the user, but if the user chooses to go forward, the "ssh" client allows it "just this once." To assure it happens just once, the "ssh" process automatically configures the "known_hosts" file with the required information by asking the server for the public-key, and then writing that into the "known_hosts" file. This exception totally subverts security by allowing the adversary to provide the association of a server-name with a public-key. This security risk is allowed because it makes things so much easier for so many people. Of course, the correct and secure method would have been for the user to manually insert a line with server-name and public-key into the "known_hosts" file before ever attempting to login to the server. (But for low-risk situations, the extra work might be pointless.)
An entry in the client's "known_hosts" file has the name of a server and a public-key that is applicable to the server machine. The server has a single private-key that is used to answer all challenges, and the "known_hosts" entry has the matching public-key. Therefore, all clients that ever access that server will have the identical public-key entry in their "known_hosts" file. The 1:N relation is that a server's public-key can appear in many client's "known_hosts" files.
An entry in the "authorized_keys" file identifies that a friendly client is allowed to access the account. The friend might use the same public-private key pair to access multiple different servers. This allows a single pair (often called ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub) to authenticate to all servers ever contacted. Each of the targeted server accounts would have the identical public-key entry in their "authorized_keys" files. The 1:N relation is that one client's public-key can appear in the "authorized_keys" files for multiple accounts on multiple servers.
Sometimes, users who work from multiple client machines will replicate the same key pair; typically this is done when a user works on a desk-top and a lap-top. Because the client machines authenticate with identical keys, they will match the same entry in the server's "authorized_keys".
Bottom line is that both "known_hosts" and "authorized_keys" contain public keys, but ...
- known_hosts -- the client checks if host is genuine
- authorized_keys -- the host checks whether client login is allowed
Hopefully, what I wrote here gives you some context for practical decision making.