Developer Tools for Random Data Generation // v2.2.2
root@generate-random:~/ssh-keys$ _

SSH Key Generator (RSA & ED25519)

Generate SSH key pairs for secure server authentication and development testing

Our SSH Key Generator creates cryptographically secure SSH key pairs for server authentication and secure remote access. Generate RSA keys (2048/4096-bit) or modern Ed25519 keys for passwordless SSH login, Git authentication, and automated deployments. All keys use CSPRNG (Cryptographically Secure Pseudo-Random Number Generation) for maximum security. Perfect for DevOps engineers, system administrators, developers, and anyone managing remote servers. Generate public-private key pairs instantly with optional passphrases and comments. No signup required, completely free.

What is an SSH Key?

An SSH key is a cryptographic credential used for secure, passwordless authentication to remote servers. SSH keys consist of two parts: a public key (placed on servers you want to access) and a private key (kept secret on your local machine). When you connect to a server, SSH uses public-key cryptography to verify your identity without transmitting passwords over the network. This makes SSH keys more secure than password authentication and enables automated, scriptable server access.

RSA (Rivest-Shamir-Adleman) is the traditional SSH key algorithm, supporting 2048-bit and 4096-bit key sizes. RSA-2048 is widely compatible and adequate for most uses, while RSA-4096 provides maximum security for long-term keys. Ed25519 (Edwards-curve Digital Signature Algorithm) is a modern alternative offering equivalent security to RSA-4096 with much smaller key sizes (256-bit), faster performance, and resistance to side-channel attacks. Ed25519 is recommended for new installations and is supported by OpenSSH 6.5+ (2014).

SSH keys are essential for DevOps workflows, enabling automated deployments, CI/CD pipelines, Git operations, and server management. System administrators use SSH keys for managing multiple servers without password prompts. Developers use them for GitHub/GitLab authentication, remote development environments, and deploying to production servers. Organizations use SSH keys with certificate authorities for centralized access control and audit trails.

SSH Key Configuration Options

Key Type (RSA vs Ed25519)

Ed25519: Modern algorithm, small keys (256-bit), fast, secure, recommended for new installations. Requires OpenSSH 6.5+ (2014). RSA-2048: Traditional algorithm, widely compatible, adequate security for most uses. RSA-4096: Maximum security, larger keys, slightly slower but compatible with all SSH servers.

Key Size (RSA only)

2048-bit: Standard size, adequate security, faster operations, recommended for most users. 4096-bit: Maximum security, future-proof, slightly slower but provides additional security margin. Ed25519 uses fixed 256-bit keys (equivalent security to RSA-4096) and does not support size configuration.

Optional Passphrase

Add a passphrase to encrypt your private key for additional security. Even if someone steals your private key file, they cannot use it without the passphrase. Recommended for keys with production access or stored on laptops. Use a strong passphrase generator for maximum security.

Key Comment

Add an optional comment to identify the key's purpose (e.g., "john@laptop-2025" or "deploy@ci-server"). Comments appear in authorized_keys files and help administrators identify key owners and purposes. Useful for key management and audit trails in organizations with multiple keys.

Output Format

OpenSSH Format: Modern format used by OpenSSH 7.8+ (default). Compatible with all recent systems. PEM Format: Traditional format for RSA keys, compatible with older systems and tools. Both Formats: Generate keys in both formats for maximum compatibility.

How to Generate and Use SSH Keys

[STEP 1] Choose Key Type and Size

Select Ed25519 for new installations (modern, fast, secure). Use RSA-2048 for compatibility or RSA-4096 for maximum security. Consider your target servers' OpenSSH versions (Ed25519 requires 6.5+).

[STEP 1] Add Optional Passphrase

Add a passphrase to encrypt your private key (recommended for production keys and laptops). Leave empty for automated deployments. Use a strong passphrase or generate one with our passphrase generator.

[STEP 1] Generate and Save Keys

Click generate and save both public and private keys. Private key must be kept secret (chmod 600 on Unix systems). Public key can be shared freely and is what you place on servers.

[STEP 1] Install Public Key on Server

Copy your public key to server's ~/.ssh/authorized_keys file. Use ssh-copy-id command or manually append: cat your_key.pub >> ~/.ssh/authorized_keys. Ensure correct permissions (chmod 700 ~/.ssh, chmod 600 authorized_keys).

[STEP 1] Configure SSH Client

Save private key to ~/.ssh/ directory (e.g., ~/.ssh/id_ed25519 or ~/.ssh/id_rsa). Set correct permissions (chmod 600). Configure ~/.ssh/config for convenience: specify Host, HostName, User, and IdentityFile path.

SSH Key Security Best Practices

  • _ Use Ed25519 for new keys: Modern, secure, fast, and resistant to side-channel attacks
  • _ Protect private keys: Never share private keys, use chmod 600 on Unix, store in secure locations
  • _ Use passphrases for sensitive keys: Encrypt private keys with strong passphrases, especially for production access
  • _ Use separate keys per purpose: Different keys for GitHub, production servers, development, and CI/CD
  • _ Rotate keys regularly: Replace keys annually or after employee departures, remove old keys from authorized_keys
  • _ Add comments to keys: Include email or identifier in key comments for easy identification and key management
  • _ Disable password authentication: Once SSH keys are set up, disable password auth in sshd_config
  • _ Use SSH agent: Use ssh-agent for passphrase caching, avoid storing passphrases in scripts
  • _ Audit authorized_keys files: Regularly review and remove unused or unknown keys from servers
  • _ Consider SSH certificates: For large organizations, use SSH certificate authorities for centralized key management

Technical Details: SSH Key Generation

SSH key generation uses cryptographically secure random number generation (CSPRNG) to produce public-private key pairs. Our generator simulates the key generation process used by OpenSSH's ssh-keygen utility:

// SSH Key Generation Process
Input: key_type (RSA/Ed25519), key_size (2048/4096), passphrase, comment

For Ed25519:
  1. Generate 32 bytes of random seed using CSPRNG
  2. Derive Ed25519 private key from seed
  3. Compute Ed25519 public key from private key
  4. Format keys in OpenSSH format
  5. If passphrase provided, encrypt private key

For RSA:
  1. Generate two large random prime numbers (p, q) using CSPRNG
  2. Compute modulus n = p × q
  3. Compute public exponent e = 65537 (standard)
  4. Compute private exponent d = e^-1 mod φ(n)
  5. Format keys in OpenSSH or PEM format
  6. If passphrase provided, encrypt private key

Key Formats:
- OpenSSH: -----BEGIN OPENSSH PRIVATE KEY-----
- PEM: -----BEGIN RSA PRIVATE KEY-----
- Public: ssh-rsa AAAA... or ssh-ed25519 AAAA...

Security Properties:
- Ed25519: 128-bit security level (2^128 operations to break)
- RSA-2048: ~112-bit security level
- RSA-4096: ~128-bit security level
- All use CSPRNG for maximum randomness

Note: This is a simulated generator for development/testing.
For production servers, generate keys locally with ssh-keygen.

API Access for Developers

GET https://generate-random.org/api/v1/generate/ssh-keys
VIEW FULL API DOCUMENTATION

Frequently Asked Questions

Should I use RSA or Ed25519 for SSH keys?
For new installations, use Ed25519. It offers equivalent security to RSA-4096 with much smaller keys (256-bit vs 4096-bit), faster performance, and resistance to side-channel attacks. Ed25519 requires OpenSSH 6.5+ (2014), so it's compatible with all modern systems. Use RSA only if you need compatibility with very old servers or legacy systems that don't support Ed25519.
Should I use a passphrase for my SSH key?
Yes, for keys that provide access to production servers or are stored on laptops/portable devices. Passphrases encrypt your private key, so even if someone steals the file, they cannot use it without the passphrase. For automated deployments and CI/CD systems, you may skip the passphrase for convenience, but ensure the private key is stored securely with appropriate file permissions (chmod 600).
What's the difference between public and private keys?
The private key must be kept secret on your local machine (like a password). The public key can be freely shared and is placed on servers you want to access. When you connect, the server uses your public key to verify that you possess the corresponding private key, without ever transmitting the private key itself. Think of the public key as a lock (placed on servers) and the private key as the only key that can open it.
How do I install my SSH public key on a server?
The easiest method is using ssh-copy-id: ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server. Manually, you can append your public key to the server's ~/.ssh/authorized_keys file: cat your_key.pub | ssh user@server 'cat >> ~/.ssh/authorized_keys'. Ensure correct permissions on the server: chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys.
Can I use the same SSH key for multiple servers?
Yes, you can use the same public key on multiple servers. However, for better security and access management, consider using separate keys for different purposes (e.g., one key for GitHub, another for production servers, another for development). This limits damage if a key is compromised and makes it easier to revoke access to specific systems.
Are these keys safe for production use?
Our generator creates cryptographically secure keys suitable for development and testing. However, for production servers, we recommend generating keys locally using the ssh-keygen command on your own machine. This ensures your private key is never transmitted or generated on a third-party server. For production, use: ssh-keygen -t ed25519 -C "your_email@example.com" or ssh-keygen -t rsa -b 4096 -C "your_email@example.com".
How often should I rotate SSH keys?
Rotate SSH keys annually as a baseline, or immediately after: employee departures with key access, suspected key compromise, security incidents, or laptop loss. Use separate keys per purpose to simplify rotation. When rotating, generate new keys, install them on target servers, verify access with new keys, then remove old keys from authorized_keys files. Keep audit logs of key rotation activities.