DEV Community

Cover image for # Unlocking SSH Security: Private Keys vs. Public Keys – The Asymmetric Duo Every Dev Must Master
sudip khatiwada
sudip khatiwada

Posted on

# Unlocking SSH Security: Private Keys vs. Public Keys – The Asymmetric Duo Every Dev Must Master

#ssh #security #backend #node

Ever felt the frustration of password fatigue? SSH keys eliminate that pain by replacing passwords with cryptographic authentication. But here's the real question: What actually happens when you SSH without a password? The answer lies in understanding the partnership between two mathematically linked keys that work in perfect harmony—one hidden, one shared. Let's demystify this asymmetric duo that every developer must master.

The Asymmetric Dance: A Tale of Two Keys

Imagine a lockbox with a unique, unbreakable lock and only one key in the entire universe that opens it. That's asymmetric encryption. You can give the lock design to anyone (the public key), but the physical key (the private key) stays with you alone.

In SSH authentication, your private key is the key, and your public key is the lock design shared with servers. The math ensures that only the holder of the private key can prove they own the public key—no password needed.

The Private Key: Your Digital Secret Identity

Your private key is your most guarded secret. It lives on your machine at ~/.ssh/id_rsa (or wherever you generated it) and should never leave your device. This key performs two critical functions:

  • Decryption: It decrypts messages meant only for you
  • Signing: It signs data to prove you're the legitimate owner

Protect it with a strong passphrase, restrict file permissions (chmod 600), and never transmit it over networks. If compromised, an attacker gains full access to all servers where your corresponding public key is stored.

The Public Key: The Shareable Lock

Your public key is mathematically derived from your private key but cannot be reversed to recover it—that's the asymmetry. Place this key on any server you want to access, typically in ~/.ssh/authorized_keys. This key performs:

  • Encryption: It encrypts messages only your private key can decrypt
  • Verification: It verifies that a signature was created by your private key

Unlike the private key, the public key is designed for distribution. It's safe to share via email, GitHub, or anywhere because it cannot unlock anything by itself.

The Handshake in Action

When you initiate an SSH connection, this sequence unfolds:

  1. Your client sends the server your public key identifier
  2. The server generates a random challenge and encrypts it with your public key
  3. Your client decrypts the challenge using your private key
  4. Your client sends back the decrypted challenge as proof of ownership
  5. The server verifies it matches and grants access

No password transmission. No brute-force vulnerability. Just pure cryptography.

From Theory to Node.js Practice

Here's how to generate and work with SSH keys programmatically using Node.js:

import { generateKeyPairSync, publicEncrypt, privateDecrypt } from 'crypto';
import fs from 'fs';

// Generate a 2048-bit RSA key pair
const { publicKey, privateKey } = generateKeyPairSync('rsa', {
  modulusLength: 2048,
  publicKeyEncoding: {
    type: 'spki',
    format: 'pem'
  },
  privateKeyEncoding: {
    type: 'pkcs8',
    format: 'pem',
    cipher: 'aes-256-cbc',
    passphrase: 'your-passphrase'
  }
});

// Save keys to files
fs.writeFileSync('public.pem', publicKey);
fs.writeFileSync('private.pem', privateKey);

// Encrypt with public key
const message = 'Hello, SSH!';
const encrypted = publicEncrypt(publicKey, Buffer.from(message));
console.log('Encrypted:', encrypted.toString('base64'));

// Decrypt with private key
const decrypted = privateDecrypt(
  { key: privateKey, passphrase: 'your-passphrase' },
  encrypted
);
console.log('Decrypted:', decrypted.toString());
Enter fullscreen mode Exit fullscreen mode

This demonstrates the core concept: the public key encrypts, the private key decrypts.

Best Practices for Key Management

  • Use a strong passphrase: Protects your private key if compromised
  • Rotate keys regularly: Generate new pairs annually; revoke old public keys from servers
  • Never transmit private keys: Not via email, not via cloud, not ever
  • Restrict permissions: chmod 700 ~/.ssh and chmod 600 ~/.ssh/id_rsa
  • Use a key agent: SSH agents keep decrypted keys in memory for your session only

Conclusion

The private/public key duo is a symbiotic relationship built on mathematical certainty. Your private key proves your identity; your public key is your digital passport shared with the world. Together, they create a security model far superior to passwords—no interception, no guessing, no fatigue. Mastering this partnership is essential for any developer working with remote servers, and now you understand not just how to use SSH keys, but why they're unbreakable.

Top comments (0)