A public-private key pair are used to perform "asymmetric cryptography." The "ssh" program can use asymmetric cryptography for authentication, where an entity has to answer a challenge to prove its identity. The challenge is created by encoding with the public-key, and answered by decoding with the private-key. (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.)

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 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.)

Note that ssh-rsa indicates that the protocal used for encoding is "rsa". Other valid protocals include "dsa" and "ecdsa". Therefore, a different token might take the place of ssh-rsa shown here.

A public-private key pair are used to perform "asymmetric cryptography." The "ssh" program can use asymmetric cryptography for authentication, where an entity has to answer a challenge to prove its identity. The challenge is created by encoding with one key, and answered by decoding with the other key. (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.)

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 write (nor read).

Once the server has authenticated, it gets a chance to challenge the client. The authentication will involve one of the public-keys found in the "authorized_keys". (When none of those keys works, the "sshd" process falls-back on password style authentication.)

Note that the token ssh-rsa indicates that the algorithm used for encoding is "rsa". Other valid algorithms include "dsa" and "ecdsa". Therefore, a different token might take the place of the ssh-rsa shown here.

Note that ssh-rsa indicates that the protocal used for encoding is "rsa". Other valid protocals include "dsa" and "ecdsa". Therefore, a different token might take the place of ssh-rsa shown here.

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.

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 the predecessor to "ssh," which was "telnet". With "telnet", the client was required to provide a password, but the server was not vetted. The lack of vetting allowed "man-in-the-middle" attacks to 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.

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 ...

Hopefully, what I wrote here gives you some context for practical decision making.

About Secure Files Containing Public Keys

To help you understand how "known_hosts" and "authorized_keys" are different, here is some context explaining how those files fit into "ssh". This is an over-simplification; there are lots more capabilities and complications to "ssh" than are mentioned here.

Associations are in Trusted Sources

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 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. The places entrusted to make this association include "known_hosts", "authorized_keys", and "Certificate Authority" listings.

The Trusted Sources Used by "ssh"

For a public-key to be relevant to "ssh," the key must be registered ahead of time, and stored in the appropriate 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.

The client's secure file is called "known_hosts", and the server's secure file is called "authorized_keys". These files are similar in that each has text with one public-key per line, but they have subtle differences in format and usage.

Key-pairs are Used for Authentication

A public-private key pair are used to perform "asymmetric cryptography." The "ssh" program can use asymmetric cryptography for authentication, where an entity has to answer a challenge to prove its identity. The challenge is created by encoding with the public-key, and answered by decoding with the private-key. (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.)

One Key-pair for Server, Another for Client

In "ssh", both sides (client and server) are suspicious of the other; this is an improvement over the predecessor to "ssh," which was "telnet". With "telnet", the client was required to provide a password, but the server was not vetted. The lack of vetting allowed "man-in-the-middle" attacks to occur, with catastrophic consequences to security. By contrast, in the "ssh" process, the client surrenders no information until the server first answers a challenge.

The Steps in "ssh" Authentication

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 write.

The File Formats

Although there are many capabilities that can be expressed in a configuration entry, the basic, most common usage has the following parameters. Note that parameters are separated by space characters.

For "known_hosts":

{server-id} ssh-rsa {public-key-string} {comment}

For "authorized_keys":

ssh-rsa {public-key-string} {comment}

Let "ssh" Auto-Configure the "known_hosts" Entry

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.)

The One-to-Many Relationships

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 client's "known_hosts" entry must have the matching public-key. Therefore, all clients that ever access a particular 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 key-pair 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".

Location of Private Keys

For the server side, a system process, or daemon, handles all incoming "ssh" login requests. The daemon is named "sshd". The location of the private key depends upon the SSL installation, for example Apple puts it at /System/Library/OpenSSL, but after installing your own version of OpenSSL, the location will be /opt/local/etc/openssl.

For the client side, you invoke "ssh" (or "scp") when you need it. Your command line will include various parameters, one of which may optionally specify which private key to use. By default, the client side key-pair are often called $HOME/.ssh/id_rsa and $HOME/.ssh/id_rsa.pub.

Summary

Bottom line is that both "known_hosts" and "authorized_keys" contain public keys, but ...