Generate SSH key in Windows with ssh-keygen -t ed25519 in PowerShell or CMD (most common path), PuTTYgen for .ppk output (for PuTTY/WinSCP), or wsl ssh-keygen from WSL. All four methods produce valid ed25519 keys - the difference is where the file lands and what client uses it. The team that uses the method matching their client has the right answer.
Table of contents
- Method 1: PowerShell ssh-keygen
- Method 2: CMD ssh-keygen
- Method 3: PuTTYgen for .ppk
- Method 4: WSL ssh-keygen
- Copy the public key to the server
- Verify the key works
- FAQ
Method 1: PowerShell ssh-keygen
The most common method on Windows 10 1809+ and Server 2019+:
ssh-keygen -t ed25519 -C "[email protected]"Key lands in $env:USERPROFILE\.ssh\id_ed25519. Add -f C:\path\to\key for a different location. The team that uses PowerShell as their primary shell uses this method.
Method 2: CMD ssh-keygen
Same binary, same arguments, slightly different home directory expansion:
ssh-keygen -t ed25519 -C "[email protected]"Key lands in %USERPROFILE%\.ssh\id_ed25519 (same as PowerShell, since both resolve to the same path). The team that uses CMD has this working.
Method 3: PuTTYgen for .ppk
When you need a PuTTY-format .ppk file:
- Launch PuTTYgen (in PuTTY install directory or
C:\Program Files\PuTTY\puttygen.exe). - Parameters: ed25519, 256 bits.
- Click Generate, move mouse to seed randomness.
- Save private key as
.ppk.
The team that uses PuTTY, WinSCP, or older SSH clients needs .ppk. The team that uses native OpenSSH doesn’t.
Method 4: WSL ssh-keygen
Inside WSL (Ubuntu, Debian, etc.):
ssh-keygen -t ed25519 -C "[email protected]"Key lands in WSL’s home (/home/<user>/.ssh/id_ed25519). Accessible from Windows at \\wsl$\Ubuntu\home\<user>\.ssh\id_ed25519.
The team that runs WSL as their primary dev environment has Linux-style SSH keys that work in WSL and (after copy) on Windows.
Copy the public key to the server
From PowerShell:
Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@server "Add-Content -Path ~/.ssh/authorized_keys -Value $(Get-Clipboard)"Or via clipboard:
Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | Set-Clipboard
# Then paste on the server's authorized_keysThe team that uses ssh-copy-id (after installing Git for Windows or in WSL) has the cleanest path: ssh-copy-id user@server.
Verify the key works
ssh user@server "echo connected as $(whoami)"If this returns without password prompt (and you have key-only auth), the key works. The team that has multiple keys uses ssh -i C:\path\to\specific\key user@server to test a specific key.
FAQ
Where does the key go on Windows?
C:\Users\<you>\.ssh\id_ed25519 (and .pub). Show hidden files in Explorer to see the .ssh folder.
Do I need different keys for PowerShell, CMD, and WSL?
Not really. PowerShell and CMD share %USERPROFILE% so the key is shared. WSL has its own ~/.ssh but you can copy Windows keys into it (or vice versa). The team that uses one primary method has one key location.
What if ssh-keygen is not recognized?
Install the OpenSSH client feature. Settings -> Apps -> Optional Features -> Add -> OpenSSH Client. The team that has Git for Windows already has it (where ssh-keygen shows which is found first).
Can I share keys between Windows and WSL?
Yes - copy id_ed25519 and id_ed25519.pub from Windows ~/.ssh to WSL’s ~/.ssh. Then chmod 600 on WSL side. The team that does this has shared keys between native SSH and WSL.
What about Bitbucket, GitLab, or other services?
Same as GitHub - paste the .pub content into the service’s SSH key form. The team that uses multiple git services has one key per service (better isolation) or one key for all.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: