ssh clarification of /etc/ssh/ directory - SOLVED

[jankom]

I have multiple working Gentoo installations. Everything works fine thanks to Gentoo documentations and help from this forum I just would like to confirm my understanding of open ssh, and specifically the role of /etc/ssh/ directory.
There are many private and public key-pairs in the /etc/ssh/ directory. Those are generated during OS installation. Correct?
The key-pairs in ~/.ssh/ (or for that matter in /root/.ssh/) directory are generated by the user as needed.
The /etc/ssh/ directory also has verious system-wide configurations.

jankom

[eccerr0r]

The host key in /etc/ssh/ is generated when sshd is first run and it notices it doesn't have a key there...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[jankom]

OK, thanks. What confused me is that later sometimes I did create a root@foo key-pair so that I can connect remotely to the foo machine remotely with ssh encryption. Now I have two root@foo key pairs. Should I replace the /etc/ssh/roo@foo key pair with the one I generated later?
Why ssh software insists on having key pairs in the /etc/ssh/ directory?
Did ssh installation put those keys there just for convenience?
What is the passphrase for the keys ssh put there during installation?

The obvious answer to these would be "yes", i.e. it is just for convenience. there is no passphrase for those keys, and in fact I could copy the root@foo key pairs into /root/.ssh/ directory and add my unbreakable passphrase to the moved key pair. Correct?

Sorry for all these questions, it is my curiosity, trying to understand the logic and the root cause.

jankom

[Ralphred]

[jankom]

@Ralphred: what is?

[Hu]

man ssh tells me:

[eccerr0r]

The keys in /etc/ssh identifies the host. The keys in ~root/.ssh identifies the user 'root'. They're two different entities.

As said, the host key mainly is used to ensure that when you connect to a machine, you connected to the machine you think you connected to, so the machine authenticates to the user that they are the real machine. Then after that, the user key authenticates that you are who you are.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[jankom]

Thank you both, @eccerr0r and @Ralphred. This is how I think the process works:

ssh is a method to securely open a terminal in a remote machine (computer, box. sever).
The ssh package installation creates /etc/ssh/ and ~/.ssh/ directories and at least one pair of /etc/ssh/ssh_host_xxx_key and /etc/ssh/ssh_host_xxx_key.pub files (here xxx designates the type of encryption, dsa, etc.) in /etc/ssh/ directory.
The ~/.ssh/ directory provides additional security by using an ssh key for login. This is accomplished with private and public keys (id_xxx and id_xxx.pub). User generates these keys with ssh-keygen command. The id_xxx.pub key needs to be transferred to the remote machine prior to a session of opening remote terminal. ssh-copy-id command can do this or any other file transfer method.

The ssh remote connection process:

There are two servers: A and B. Person P has account on both servers: user name "a" on server "A" and user name "ab" on server "B". P wants to open a terminal on server "B" while using server "A".
(I) Authenticate servers:
1) User "a" issues command ssh ab@1.2.3.4 - where "1.2.3.4" is the IP of "B" ("1.2.3.4" may also be "B.fqdn" or "B.local").
2) The sshd service of "A" sends its ssh_host_xxx_key.pub file to "B".
3) sshd service of "B" checks the home directory of its user "ab" for known_hosts in the ~/.ssh/ directory. If user "a" of "A" has a past successful connection, then the home directory of "ab" in "B" will have an entry in the known_hosts file and sshd service jumps to part (II).
The known_hosts file is a list of server public keys in the format of <IP or fqdn> <key encryption method> <ASCII characters of public key>.
4) Server "B" sends its public key to server "A". This completes the public key exchange part of the process. Both servers have now the public key of each other.
5) Server "A" using the just received public key of "B" announces itself that yes, I am "A".
6) Server "B" understands the announcement because "B" already has the public key of "A" and responds back to "A" that OK, I am "B" indeed. This completes the server verification process.
(II) Authorize connecting user:
1) A terminal with dialogue screen opens on server "A".
2) If there is an authorized_keys file in the ~/.ssh/ directory of user "ab" in server "B" and if that file contains the public key entry of user "a", then sshd service jumps to step 5).
The authorized_keys file is a list of remote user public keys in the format of <key encryption method> <ASCII characters of public key> <user@server>.
3) The dialogue screen asks user "a" "Do you want to accept remote connection...?". User "a" answers "Yes" because this is an authenticated connection between the two servers. Then server "B" adds server "A" to the list of known_hosts file in its ~/.ssh/ directory.
4) If user "a" did not create an id_xxx.pub file or has not transferred it yet to "B" then the process jumps to step 6).
5) Server "B" asks for passphrase for the public key of user "a" and jumps to step 7).
6) User "a" did not create id_ssh key pairs therefore the dialogue screen turns into a traditional login screen, asking for the password of user "ab".
7) User "a" now has a secure, authenticated terminal of remote server "B" while on server "A" as user "ab".

I'll close this topic as SOLVED in a few days as long as there are no further comments, corrections posted.

jankom

[eccerr0r]

when doing server authentication it's only one way by default, the client machine isn't involved other than later passing the user authentication.

I believe the client machine sends the server something to sign. The server will sign/hash it and give the result back which will server as the public key. Ideally if you give a server something to sign, every time you ask it to sign it will sign it the same way and if not, it probably got compromised or the host key changed for whatever reason. The client machine checks this result with what it had on file locally.

The user authentication is more important once you ascertain you're connecting to the right machine. Likewise the server will give the client something to sign and the client machine using the user private key, sign it, and then send it back to the server. Server only gives access if the string it got back matches the preshared public key.

Yes it seems a bit insecure that the host does not (normally) check the client machine, you probably can, but theoretically the user key will tell the client machine is valid or not, hopefully the user private key is not copied onto an untrusted machine.

Note that client machines do not have to have sshd running to ssh out. Without sshd running, there's no access to the client host private key, so that's the indication that it's not used.

As always, the weakest point is how well the keys are handled by the users...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[jankom]

Understand. So it is better to call server "A" in my example as client (the one contacts the remote machine), and machine "B" as server. Also, "sign" is what I described in layman's term as "responds OK, etc.".
? jankom

[pingtoo]

Conceptually your description are correct.

But if you take this concept and try to debug a fail connection the description will likely lead to unable address real problem.

Also you need to understand and distinguish authentication vs authorization in the concept of access control. For access control one must first be authenticated then authorized then access can be granted.

In your description,

• Authenticate servers: only /etc/ssh/ssh_host_*_key.pub is send to connection requester that is true. however ~/.ssh/known_hosts is not used at this stage because this stage is getting connection server identify. (some key exchange to verify that public key really belong to connection server therefor confirm the connection server identity). As well the connection client also send /etc/ssh/ssh_host_*_key.pub to connecting server to confirm client's identity. It is possible at this stage server can deny certain public keys by setup sshd_config option RevokedKeys (It is also possible use TCP Wrappers do the same. (see /etc/hosts.deny))
  
• Only after both party were identified than authorization process can begin. And it is now close to your 2 points about Authentication and Authorization. However I will call it Authorization because sshd server now use user's authorized_keys to grant access (or not). In the autorized_keys is combined with client's machine identify as well as user's username identify

-- EDIT --
Correction, In the point 1, I mistakenly say sending client machine identity, This is wrong. It is sending user's public key.

[jankom]

Yes. I'll edit and change authentication to authorization.
A machine is authenticated, and a user is authorized to use.

[pingtoo]

[jankom]

Yes. I slightly modified part (II) title specifying that the connecting user is authorized by the connected machine.

jankom (Janos)

[szatox]