What is the difference between /etc/ssh/ and ~/.ssh?

Question

I’m having fun with OpenSSH, and I know the /etc/ssh directory is for the ssh daemon and the ~/.ssh directory is for a particular user.

Both directories contain private and public keys:

But what is the difference between those keys? I’m confused because the ones I use as a user is in my home directory, and what are the roles of the keys found in /etc/ssh?

Solution 1

/etc/ssh provides configuration for the system: default configuration for users (/etc/ssh/ssh_config), and configuration for the daemon (/etc/ssh/sshd_config). The various host files in /etc/ssh are used by the daemon: they contain the host keys, which are used to identify the server — in the same way that users are identified by key pairs (stored in their home directory), servers are also identified by key pairs. Multiple key pairs are used because servers typically offer multiple types of keys: RSA, ECDSA, and Ed25519 in your case. (Users can also have multiple keys.)

The various key files are used as follows:

• your private key, if any, is used to identify you to any server you’re connecting to (it must then match the public key stored in the server’s authorized keys for the account you’re trying to connect to);
• the server’s private key is used by the client to identify the server; such identities are stored in ~/.ssh/known_hosts, and if a server’s key changes, SSH will complain about it and disable certain features to mitigate man-in-the-middle attacks;
• your public key file stores the string you need to copy to remote servers (in ~/.ssh/authorized_keys); it isn’t used directly;
• the server’s public key files store strings you can copy to your known hosts list to pre-populate it; it also isn’t used directly.

The last part isn’t used all that often; the default SSH model is known as “TOFU” (trust on first use): a connection is trusted by default the first time it’s used, and SSH only cares about unexpected changes. In some cases though it’s useful to be able to trust the first connection too: a server’s operator can communicate the server’s public keys, and users can add these to their known hosts before the first connection.

See the ssh_config and sshd_config manpages for details (man ssh_config and man sshd_config on your system). The format used for known hosts is described in the sshd manpage.

Solution 2

/etc/ssh holds the private and public key pairs for the host (the computer/operating system)

~/.ssh holds the key pairs for its owner user

Research a little on how symmetric keys and PKI work. You'll find out that, in most situations, both the sender and the receiver need their own pair of private/public keys.

Comments

[Kavish Gour]

Let's say a user is trying to establish a connection with my public key, this is just between me and the user (i assume) so, why do the daemon has to identify itself ? How do the daemon host files comes in play ?

[Stephen Kitt]

When you connect to an SSH server, you identify yourself to the server (using either your login and password, or a key), and the server identifies itself to you, using its host key. This is typically transparent, but it is important: it avoids man-in-the-middle attacks after the first connection. Known host keys are stored in ~/.ssh/known_hosts, and SSH verifies server host keys against those to check that it’s connecting to the right server.

[Kavish Gour]

I did some research based on your answer: /etc/ssh/ssh_host_key.pub /etc/ssh/ssh_host_dsa_key.pub /etc/ssh/ssh_host_rsa_key.pub These three files contain the public parts of the host keys. These files should be world-readable but writable only by root. Their contents should match the respective private parts. "These files are not really used for anything; they are provided for the convenience of the user so their contents can be copied to known hosts files. " I don't understand the last sentence inside the quotes. Can you please elaborate it for me (my english is not that good).

[Stephen Kitt]

See my updated answer.

[Gilles 'SO- stop being evil']

@dr01 Are you suggesting to remove it in favor of “always” or “sometimes”? It's true that in most scenarios, each side has its own private key. But there's a very widespread scenario where only one side has a private key, and you used it to post your comment: web browsing over HTTPS, and more generally TLS without TLS client authentication (on the web, user authentication is usually done with a password, not with a private key).