SSH key-based authentication: known_hosts vs authorized_keys

Question

I read about setting up ssh keys in Linux and have some questions. Correct me if I'm wrong…

Let's say host tr-lgto wants to connect to host tr-mdm using ssh. If we want to be sure that it's the real tr-mdm, we generate a pair of keys on tr-mdm and we add the public key to known_hosts on tr-lgto. If tr-mdm wants to check that it's the real tr-lgto, then tr-lgto has to generate a keypair and add the public key to authorized_keys on tr-mdm.

Question 1: There is no user field in file known_hosts, just IP addresses and hostnames. tr-mdm might have a lot of users, each with their own .ssh folder. Should we add the public key to each of the known_hosts files?

Question 2: I found that ssh-keyscan -t rsa tr-mdm will return the public key of tr-mdm. How do I know what user this key belongs to? Moreover, the public key in /root/.ssh/ is different from what that command returns. How can this be?

Solution 1

You're mixing up the authentication of the server machine to the client machine, and the authentication of the user to the server machine.

Server authentication

One of the first things that happens when the SSH connection is being established is that the server sends its public key to the client, and proves (thanks to public-key cryptography) to the client that it knows the associated private key. This authenticates the server: if this part of the protocol is successful, the client knows that the server is who it pretends it is.

The client may check that the server is a known one, and not some rogue server trying to pass off as the right one. SSH provides only a simple mechanism to verify the server's legitimacy: it remembers servers you've already connected to, in the ~/.ssh/known_hosts file on the client machine (there's also a system-wide file /etc/ssh/known_hosts). The first time you connect to a server, you need to check by some other means that the public key presented by the server is really the public key of the server you wanted to connect to. If you have the public key of the server you're about to connect to, you can add it to ~/.ssh/known_hosts on the client manually.

Authenticating the server has to be done before you send any confidential data to it. In particular, if the user authentication involves a password, the password must not be sent to an unauthenticated server.

User authentication

The server only lets a remote user log in if that user can prove that they have the right to access that account. Depending on the server's configuration and the user's choice, the user may present one of several forms of credentials (the list below is not exhaustive).

• The user may present the password for the account that he is trying to log into; the server then verifies that the password is correct.
• The user may present a public key and prove that he possesses the private key associated with that public key. This is exactly the same method that is used to authenticate the server, but now the user is trying to prove their identity and the server is verifying them. The login attempt is accepted if the user proves that he knows the private key and the public key is in the account's authorization list (~/.ssh/authorized_keys on the server).
• Another type of method involves delegating part of the work of authenticating the user to the client machine. This happens in controlled environments such as enterprises, when many machines share the same accounts. The server authenticates the client machine by the same mechanism that is used the other way round, then relies on the client to authenticate the user.

Solution 2

My friends gave me the answer. By default, key identifies a machine and not a user. So the keys are stored in /etc/ssh/. That's why I got a different key from the one stored in /root/.ssh

Comments

[Gilles 'SO- stop being evil']

Similar question on Information Security: What is the difference between authorized_key and known_host file for SSH?

[IAM_AL_X]

I added some background context for 'ssh' in an answer "About Secure Files Containing Public Keys" at the question mentioned by @Gilles: <security.stackexchange.com/questions/20706/…>

[Alex]

Nice answer Gilles, but my question is any server can send a random public key and prove that it has the associated public key. How does that prove the server is authentic?

[Gilles 'SO- stop being evil']

@spartacus I think you meant “and prove that it has the associated private key”, right? The idea is that the client sends a randomly-generated value (a challenge) to the server, and the server makes some calculation based on the private key that depends on the challenge (so the server can't make the computation until it receives this challenge) and that can only be done with the knowledge of the private key.

[synack]

I think Alex refers to the first time the client connects to the server. I think the client will trust the server that first time. Then the server will send its public key and the client will be able to authenticate the server for the following connections.

[Gilles 'SO- stop being evil']

@synack Ah, the first time? Rather, the client les the user make the decision (“Are you sure you want to continue connecting (yes/no)?”). The server doesn't prove anything at that point.

[synack]

you're right, it's the user who takes the decision.

[clay]

@Gilles And how user decide a yes and a no?

[Gilles 'SO- stop being evil']

@NamGVU Generally, you should say no, unless you have a good reason to think that the change is legitimate (e.g. the server was just reinstalled) and you have a good reason to think that you aren't under attack at the moment.