What are SSH keys and how do they work?
SSH keys are an asymmetric key pair: the private key stays on your machine, and the public key is placed in ~/.ssh/authorized_keys on the server. During login the server issues a challenge that only the matching private key can answer, so no secret ever crosses the wire. Key-based authentication resists brute-force and phishing in ways passwords cannot, and it is the standard for cloud servers, Git hosting, and CI/CD pipelines.
How does this tool work?
Pick your OS (macOS, Ubuntu, RHEL, Arch, PowerShell, WSL, or Git Bash), choose an algorithm, and set options like a custom filename, comment, or remote host. The tool assembles the exact ssh-keygen command plus follow-up steps — permissions, agent setup, ssh-copy-id deployment, a connection test, and an optional ~/.ssh/config block. It only generates script text in your browser; the keys themselves are created on your machine when you run it, so no key material ever exists here.
Should I use ed25519 or RSA?
Use ssh-keygen -t ed25519 unless something stops you. Ed25519 keys are tiny (68-character public keys), fast, and immune to the nonce-reuse weaknesses that plague ECDSA; OpenSSH has supported them since 2014, and GitHub, GitLab, and modern distros all accept them. Choose RSA 4096 only for legacy systems or appliances that predate Ed25519 support — some older network gear and AWS EC2 key-pair imports historically required RSA. Avoid DSA entirely; it is disabled in modern OpenSSH.
How do I copy my public key to a server?
The one-liner is ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host — it appends the key to the remote authorized_keys and fixes permissions. Without it (PowerShell, or minimal servers), pipe it manually: cat the .pub file into ssh user@host with a command that mkdir -p ~/.ssh and appends to ~/.ssh/authorized_keys. Always copy the .pub file, never the private key — the private key should never leave your machine.
Why does SSH still ask for a password after adding my key?
Nine times out of ten it is permissions: sshd silently ignores authorized_keys if it or its parents are too open. The fix is chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, and a home directory not writable by group or others. Other causes: the key was added for the wrong user, PubkeyAuthentication is off in sshd_config, or the client offered a different key — debug with ssh -v and check the server side in /var/log/auth.log or journalctl -u sshd.
Should I set a passphrase on my SSH key?
Yes for interactive use — a passphrase encrypts the private key on disk, so a stolen laptop or leaked backup does not equal instant server access. The ssh-agent removes the daily friction by caching the decrypted key per session; on macOS, ssh-add --apple-use-keychain plus UseKeychain yes in ~/.ssh/config makes it survive reboots. Skip the passphrase only for unattended automation (CI runners, cron jobs), and compensate with restricted, single-purpose keys.
Can I use one SSH key for multiple servers?
Technically yes — the public key can live in any number of authorized_keys files — but per-service keys are better practice: revoking access to one service then never disturbs the others. Manage multiple keys cleanly with Host blocks in ~/.ssh/config that set HostName, User, and IdentityFile, plus IdentitiesOnly yes so the client offers exactly the right key instead of cycling through all of them and tripping server auth-attempt limits. This tool can generate that config block for you.