How to Generate SSH Key Pairs for Secure Server Access

SSH keys are the standard way to authenticate with remote servers. They are more secure than passwords — a 2048-bit RSA key is practically unbreakable by brute force — and more convenient because you do not type a password every time you connect. Generating keys is the first step to setting up any server.

RSA vs. ECDSA

The ToolStand SSH Key Generator supports two key types: RSA (2048 or 4096 bit) — the most widely compatible key type, supported by every SSH server. ECDSA (256 or 384 bit) — newer elliptic curve keys that are smaller and faster while providing equivalent security. Use RSA for maximum compatibility, ECDSA for modern systems where supported.

Generating and using keys

Click Generate to create a key pair. The generator produces a public key (safe to share, goes on servers) and a private key (keep secret, stays on your machine) in PEM format. Copy the public key to your server authorized_keys file. Keep the private key in ~/.ssh/ with permissions set to 600 (read/write for owner only). Never share your private key — anyone with it can access your servers.

Security best practices

Generate keys in your browser using crypto.subtle.generateKey() — the private key material is handled securely and never transmitted. Use a passphrase to protect your private key. Rotate keys periodically (every 6-12 months). Use different keys for different servers or environments. Revoke keys immediately if a device is lost or compromised.

Ed25519 — the modern SSH key that replaces RSA

While the SSH Key Generator supports RSA and ECDSA, Ed25519 has become the recommended default for new deployments. Ed25519 keys are smaller (256-bit public key vs. 2048+ for RSA), faster (significantly lower CPU cost per authentication), and more secure (Ed25519 is not vulnerable to the side-channel and timing attacks that have affected some RSA implementations). OpenSSH has supported Ed25519 since version 6.5 (2014). To generate one: ssh-keygen -t ed25519 -C "your@email.com". The only reason to choose RSA in 2026 is compatibility with legacy systems that predate Ed25519 support — particularly older embedded devices and mainframes. For everything else, prefer Ed25519 or ECDSA.

Private key permissions — the 600 rule and why it matters

SSH refuses to use private keys with overly permissive file permissions. The rule: chmod 600 ~/.ssh/id_rsa (read/write for owner only; no access for group or others). If permissions are 644 (world-readable) or 664 (group-readable), SSH will output "Permissions are too open" and reject the key. This is a security feature — a world-readable private key is a compromised key. The same applies to the ~/.ssh/ directory itself: chmod 700 ~/.ssh/. After downloading the generated key, check permissions before use. On Windows (WSL), Linux permissions apply; on native Windows, use icacls to restrict the key file to your user account only.

Passphrase protection — when and how to use it

An SSH private key without a passphrase is a plaintext file that grants server access to anyone who obtains it. Adding a passphrase encrypts the private key with a symmetric cipher (AES-256 in modern OpenSSH), requiring the passphrase to decrypt and use it. Tools like ssh-agent cache the decrypted key in memory so you only type the passphrase once per session. When to use a passphrase: for any key that accesses production servers, customer data, or financial systems. When you might skip it: automated CI/CD pipelines where keys are stored in a secrets vault and rotated frequently. The trade-off is convenience vs. security: a passphrase-protected key cannot be used if stolen, but adds a step to every new SSH session. Use ssh-keygen -p to add or change a passphrase on an existing key without regenerating it.

Key rotation and revocation — the lifecycle of an SSH key

SSH keys should be rotated periodically, not kept forever. Rotation schedule: every 6-12 months for production access; every 3-6 months for keys with elevated privileges (root, database admin). Rotation process: (1) generate a new key pair, (2) add the new public key to server authorized_keys alongside the old one, (3) test authentication with the new key, (4) remove the old public key from authorized_keys, (5) securely delete the old private key. Emergency revocation: if a device is lost or an employee leaves, immediately remove their public key from ALL servers — sed -i '/old-key-fingerprint/d' ~/.ssh/authorized_keys — do not wait for the next rotation cycle. The generator makes step 1 instant; combine it with configuration management tools (Ansible, Puppet) for steps 2-5 across many servers.

SSH key types comparison — a decision matrix

| Key Type | Security Level | Speed | Compatibility | Recommendation | |----------|---------------|-------|---------------|----------------| | RSA 2048 | Good (~112-bit) | Medium | Universal | Legacy compatibility | | RSA 4096 | Strong (~140-bit) | Slow | Universal | High-security RSA | | ECDSA 256 | Strong (~128-bit) | Fast | Most systems (2015+) | Good balance | | ECDSA 384 | Very Strong (~192-bit) | Fast | Most systems (2015+) | Government/military | | Ed25519 | Strong (~128-bit) | Fastest | Modern systems (2014+) | Best default choice | RSA 4096 is secure but slow — each authentication requires more CPU. Ed25519 achieves comparable security with a fraction of the computational cost. The generator produces RSA (2048, 4096) and ECDSA (256, 384); for Ed25519, use ssh-keygen or the equivalent in your cloud provider console.

Frequently Asked Questions

Explore all 109 free tools at toolstand.io. Free, forever. No sign-up. No download. Just tools that work.