Security

SSH and RSA Keys Explained: Generate, Use, and Secure Your Key Pairs

A practical guide to SSH and RSA key pairs — how they work, how to generate them in your browser, and how to use them for secure server access and encryption.

7 min read

Security keys concept

Public key cryptography is the foundation of secure internet communication — SSH connections, HTTPS, JWT signing, and encrypted email all rely on it. Understanding how key pairs work makes you a more effective developer and a more security-conscious user.

The core concept: public and private keys

A key pair consists of two mathematically linked keys:

  • Private key — Stays on your machine. Never share it. Think of it as your identity.
  • Public key — Share freely. You put this on servers, in GitHub, in JWT configurations.

The mathematics works in one direction: data encrypted with a public key can only be decrypted with the corresponding private key. And data signed with a private key can be verified with the public key — without revealing the private key.

SSH keys: password-free server access

SSH (Secure Shell) is the standard for remote server access. Password authentication works but has weaknesses — passwords can be guessed, phished, or leaked. SSH key authentication is fundamentally stronger:

  1. Your client presents a cryptographic proof using your private key
  2. The server verifies the proof against the public key you installed
  3. No password travels over the network — there is nothing to intercept

Setting up SSH key authentication:

# Generate a key pair (Ed25519 is the modern standard)
ssh-keygen -t ed25519 -C "your-email@example.com"

# Copy public key to a server
ssh-copy-id user@yourserver.com

# Connect — no password needed
ssh user@yourserver.com

The public key goes into ~/.ssh/authorized_keys on the server. The private key never leaves your machine.

Ed25519 vs RSA for SSH

Ed25519 is the current recommendation:

  • Smaller keys (256-bit) with equivalent or better security than RSA-4096
  • Faster signature generation and verification
  • Supported by all modern SSH servers

RSA is still widely used, especially in enterprise environments with older systems:

  • 2048-bit is the minimum acceptable size today
  • 4096-bit provides extra margin for long-lived keys
  • Larger key sizes mean slightly slower authentication

Generate SSH keys in your browser with our SSH Key Generator — Ed25519 and ECDSA, using the Web Crypto API. No key material leaves your browser.

RSA keys: encryption and signing

RSA keys are used beyond SSH — for TLS certificates, JWT signing, encrypted email (PGP), and API authentication.

Common RSA use cases:

JWT (JSON Web Tokens) with RS256:

  • Sign tokens with your RSA private key
  • Clients verify with the public key
  • Unlike HS256 (symmetric), the verifier never needs the signing secret

Code signing:

  • Sign a release artifact with your private key
  • Users verify the signature with your published public key
  • Proves the artifact came from you and wasn't tampered with

TLS/SSL certificates:

  • Certificate authorities sign your public key with their private key
  • Browsers verify using the CA's public key (built into the browser)

Generate RSA key pairs in PEM format with our RSA Key Generator — 2048-bit or 4096-bit, entirely in your browser.

PEM format explained

RSA and SSH keys are commonly distributed in PEM (Privacy Enhanced Mail) format:

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC7o4qne60...
-----END PRIVATE KEY-----

The header and footer identify the key type. The middle is the base64-encoded key data. Different headers indicate different key types:

  • BEGIN RSA PRIVATE KEY — Traditional PKCS#1 format
  • BEGIN PRIVATE KEY — PKCS#8 format (more common in modern tools)
  • BEGIN PUBLIC KEY — Public key in PKCS#8 format
  • BEGIN OPENSSH PRIVATE KEY — OpenSSH's own format for SSH keys

Protecting your private key

Private key security is critical:

  1. Never commit to git — Add *.pem, id_rsa, and id_ed25519 to .gitignore
  2. Use a passphrase — Encrypts the key at rest. Even if someone gets the file, they cannot use it without the passphrase.
  3. Restrict permissions — SSH requires chmod 600 on private key files; it refuses to use keys readable by others
  4. Rotate if compromised — Generate a new pair and remove the old public key from all servers
# Set correct permissions on your private key
chmod 600 ~/.ssh/id_ed25519

Key fingerprints

A fingerprint is a short hash of a public key used to verify identity without comparing the full key:

ssh-keygen -lf ~/.ssh/id_ed25519.pub
# Output: 256 SHA256:abc123... your-email@example.com (ED25519)

When connecting to a server for the first time, SSH shows you the host's fingerprint and asks you to confirm. Verify this fingerprint through a separate channel (the server provider's documentation) before accepting.

Summary

SSH and RSA key pairs provide authentication and encryption that is fundamentally stronger than passwords. Use Ed25519 for SSH, RSA-4096 for signing and encryption, always protect private keys with a passphrase, and generate keys locally — never let a third-party service generate your private key for you.