Understanding private and public keys in SSH, and other technologies
When you use SSH to log into another remote computer, the private and public key system is fundamental for authentication. Here's a quick breakdown of how it works.
Public key authentication involves proving to a server that a trusted party's key matches your private key. These keys, created through complex mathematical processes, are linked uniquely—one private key corresponds to one public key.
The public key, shareable openly, encrypts messages but can't decrypt them. It's a one-way street for encryption. On the other hand, the private key, kept as securely as, or even more than, personal private information, is used to decrypt messages that the corresponding public key encrypted.
This concept spans various secure systems:
- In HTTPS, during the SSL handshake, you receive the public key of a website, encrypt a random password with it, and send it back. Subsequent communication uses this shared password for encryption.
- In PGP, recipient public keys encrypt emails, ensuring only they can open them. It's a simple yet underused method, unfortunately overshadowed by less secure practices.
For SSH or GIT, setting up authentication involves specifying which public key gains access. When connecting, OpenSSH or similar software attempts to send your public key to the server. If matched with known public keys, authentication proceeds via a handshake involving generating a password, encrypting it with the public key, and sending it back. Successful decryption with the corresponding private key validates your identity.
Moreover, if your private key is password-encrypted (which is advisable for security), you'll need to enter that password to decrypt it before use. This multilayered encryption helps protect against potential theft or unauthorized access.
Various algorithms handle this private/public key pairing. RSA, though older and slower due to larger key sizes, remains common. ECDSA, newer, faster, and requiring smaller keys, offers enhanced security but isn't universally supported.
This is also why it's important to only use SSH via private-public key pairs. They are immensely hard to crack, while passwords can and will be brute forced. Using the right SSH config, it also not only makes your server secure, but also makes remoting into your server easier as well.
In essence, SSH relies on this asymmetric encryption system, ensuring secure communication by verifying identities through paired keys. I hope this post helped you understand some of the fundamentals of this technology, or at least gave you a quick refresher.