SSH has two separate concerns: authentication (proving who you are) and encryption (keeping the session private).
1. Server identity verification
On first connection, the server sends its public key fingerprint. The client checks it against ~/.ssh/known_hosts. If absent, you get the “are you sure?” prompt — you’re manually trusting the server’s identity. The fingerprint is saved and verified automatically on all future connections.
2. Key-based authentication
Instead of a password, identity is proven with an asymmetric keypair:
- Private key — stays on your machine, never transmitted
- Public key — placed on the server in
~/.ssh/authorized_keys
The server sends a random challenge and signs it. The client signs the response with the private key. The server verifies the signature using the stored public key. This proves the client holds the private key without ever transmitting it.
What signing means: the private key is run over a piece of data to produce a unique fingerprint (the signature). Anyone with the public key can verify the fingerprint is genuine — but only the holder of the private key could have produced it. It proves identity, not secrecy.
Note
Signing and encryption go in opposite directions. Signing: private key produces, public key verifies. Encryption: public key locks, private key unlocks.
3. Encrypted session
Once authenticated, both sides negotiate a shared symmetric key via Diffie-Hellman. All session traffic is encrypted with this key. Asymmetric keys are only used for authentication — symmetric encryption is used for the actual data because it’s faster.
Key lookup
The SSH client looks for the private key in the home directory of the user running it. If SSH runs as node inside a Docker container, it looks in /home/node/.ssh/ — not on the host’s filesystem. A key placed at /home/ec2-user/.ssh/ on the host is invisible to it.
See also
- n8n-tng-sftp — example where key location inside a Docker container was the root cause of auth failure