What's the fundamental principle regarding who should hold which key (public vs. private)?

Question

In a SSH logging scenario, the client keeps the private key while the server stores the public key under its ./ssh directory.

In a different scenario, such as SSL, it's the server that keeps the private key and give away its corresponding public keys to the end users.

I read a lot about the two keys online, they are either off the topic or too deep for a beginner. Could someone explain using plain language about what is the governing rule here determining who should hold what key? Thanks very much.

Answer 1

In all cases, the party which is being authenticated holds the private key (actually both keys, the whole set). The party which is verifying authentication only needs to know the public key.

Both SSH and TLS/SSL actually support authenticating both the client and the server, so each connection may use two different keypairs – one to verify the server's identity (server holds the private key) and one to verify the client's identity (client holds the private key).

For example, in SSH, the server's authorized_keys file holds client public keys, but the client's known_hosts file holds server public keys.

When you're being asked to verify the "hostkey fingerprint" when making an SSH connection, you're seeing the server's public key, and the server stores its private key in /etc/ssh. Once that step is done, the client presents its own public key to the server.

(The same thing exists in TLS as "client certificate authentication", but it is somewhat rare in comparison – but even though it's very rare on the web, many browsers support it anyway.)