How to Create an SSH Key in 2026

You can create an SSH key in one command:

ssh-keygen -t ed25519

That command has not meaningfully changed since your 2014 self typed it, and this guide would have looked almost identical back then. What changed by 2026 is not the how, it is the which: which key type to pick (Ed25519, not RSA), whether to bother with a passphrase, and where the two files have to live so SSH actually trusts them. Here is the whole thing, on Linux, macOS, and Windows.

The one command

This is the whole job. It is identical on Linux, macOS, and Windows because ssh-keygen ships with OpenSSH everywhere:

ssh-keygen -t ed25519 -C "you@example.com"

The -C comment is just a label that ends up at the end of the public key, so future-you can tell keys apart. Press Enter at every prompt to accept the default path (~/.ssh/id_ed25519) and an empty passphrase, or fill them in. That is what a real run looks like:

You now have two files in ~/.ssh: the private key (id_ed25519, keep it secret, never copy it anywhere) and the public key (id_ed25519.pub, safe to hand out). That is the entire mental model: the public half goes on servers and into GitHub; the private half stays on your machine and never moves.

If you picked RSA or ECDSA in the box above, your files are named id_rsa / id_ecdsa instead of id_ed25519. Swap the name in the commands below to match.

Do I need sudo? (No, and please don't)

Creating a key is a per-user action. It writes to your home directory, so it needs no root and no sudo. This trips people up because so many Linux tutorials reflexively prepend sudo to everything.

sudo ssh-keygen is actively wrong: it creates a key owned by root, sitting in your ~/.ssh, that you then cannot read. SSH refuses keys it cannot open as you:

The rule that actually matters: run a command with the privilege the task needs, not out of habit. Creating your own key is a you-level task. Adding that key to another user's account on a server, or editing system config, is a root-level task where sudo (or logging in as that user) is correct. Reach for elevation deliberately, not by reflex.

Which key type should I pick in 2026?

Ed25519, in almost every case. Pass -t ed25519 and stop thinking about it. (A 2026 footnote on that opening joke: since OpenSSH 9.5, released 2023, bare ssh-keygen with no flags already creates an Ed25519 key. I still pass -t ed25519 explicitly so the command does the right thing on older machines that still default to RSA.)

DSA is gone: it was capped at 1024 bits, disabled by default for years, and OpenSSH removed it outright in version 10.0 (2025). If something still asks for a DSA key in 2026, that system is the problem, not your tooling.

Ed25519 works out of the box on current Linux, macOS, and Windows, since all three ship a modern OpenSSH. The only place you will hit trouble is a server or appliance that has not been updated in a decade, which is the one scenario where RSA 4096 earns its place.

Should I add a passphrase?

Honest answer: on machines I physically control and keep disk-encrypted, I often don't. But I am going to tell you to anyway, and it would be remiss of me as a security person to say otherwise.

The moment the key lives on a laptop that can be lost, or a box other people can touch, the passphrase is the only thing standing between a stolen private key and every server that trusts it. And ssh-agent means you type it once per session, so the day-to-day cost is essentially nothing. So: set a passphrase. Do as I say, not as I sometimes do.

You do not have to decide at creation time. Add or change one on an existing key whenever you like:

ssh-keygen -p -f ~/.ssh/id_ed25519

Load the key into the agent once so the passphrase prompt stops following you around:

eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519

On macOS, --apple-use-keychain stores the passphrase in the Keychain so it survives reboots. On Windows, the ssh-agent service is disabled by default; the Start-Service line wakes it up (run it once as administrator to set it to start automatically).

Where the keys live, and the permissions that matter

Your keys sit in ~/.ssh on Linux and macOS, and %USERPROFILE%\.ssh on Windows. The permissions are not cosmetic: SSH flat-out refuses to use a private key that other users can read.

chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_ed25519 && chmod 644 ~/.ssh/id_ed25519.pub

ssh-keygen already creates the files with the right modes, which you can see straight after generating:

So you usually only need the chmod above when you copied keys over from another machine and the permissions came along too loose. Here is the error that produces, and the fix:

If 600 and 700 look cryptic, they are octal file modes: 600 is read and write for you and nobody else, 700 adds execute (the bit that lets you enter a directory), again for you only. Anything that grants group or other a bit on the private key is what trips the warning. Staring at that error on a key you copied from another machine? Here is the full fix for SSH "permissions are too open".

Put the key to work

The public key is the half you share. Print it and copy it:

cat ~/.ssh/id_ed25519.pub          # then: xclip -sel clip < ~/.ssh/id_ed25519.pub

To log into a server without a password, install the public key on it. On Linux and macOS that is one command; on Windows you append it by hand:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

Then confirm it worked: ssh user@server should log you straight in with no password prompt. For a web service the test is the same idea, for example ssh -T git@github.com answers with your username once GitHub recognizes the key.

For GitHub, GitLab, or any web service, paste the contents of id_ed25519.pub into their SSH keys settings page. The full reference for connecting, tunneling, and copying over SSH is in the SSH cheat sheet.

One thing not to do: online SSH key generators

Do not generate SSH keys on a website. A private key is a secret that should be born and die on your own machine. If a site generates the keypair for you, the private half existed on someone else's server first, which means you have to trust that they did not log it, and you can never prove they didn't. Key generation is the one step that must stay local. ssh-keygen is right there, it is offline, and it takes one line.

FAQ

See also

• SSH Cheat Sheet: once the key exists, this is the reference for connecting, port forwarding, ProxyJump, scp, and rsync.
• Linux file permissions and ownership with find: the read/write/execute and ownership model behind the chmod 600 your key needs.
• How to SSH into an EC2 instance: putting the key you just made to work against an AWS box.
• How to SSH into a GCP VM without gcloud: the same, for Google Cloud, using your own key instead of the gcloud helper.