SSH keys let you connect to Git hosting services without entering your account password every time. They’re also useful for secure connections to remote servers. To set up SSH keys on Windows, create a key pair, add the public key to the service you use, and make sure your Git client can find the private key.
The process works in PowerShell on Windows 10 and 11 when the OpenSSH client is installed. You’ll keep the private key on your computer and share only the matching public key. The steps below use GitHub as an example, but the same basic process applies to other services that support SSH authentication.
Check that OpenSSH is available
Open PowerShell and run: ssh -V. If Windows returns a version number, the SSH client is ready. If PowerShell says the command isn’t recognized, install the OpenSSH Client feature.
- Open Settings and go to System, then Optional features.
- Look through the installed features for OpenSSH Client.
- If it isn’t listed, select View features, find OpenSSH Client, and install it.
Close and reopen PowerShell after installation, then run ssh -V again. The OpenSSH Client is what creates keys and connects to remote services. You usually don’t need the OpenSSH Server feature for Git authentication.
Set up SSH keys on Windows with PowerShell
In PowerShell, create an Ed25519 key pair with this command, replacing the sample email address with one associated with your Git account:
ssh-keygen -t ed25519 -C “your_email@example.com”
When prompted for a location, press Enter to use the default path, typically C:UsersYourName.sshid_ed25519. If a key already exists at that location, don’t overwrite it until you know what it’s used for. You can create a separate key with a different filename instead.
Next, enter a passphrase when prompted. A passphrase adds protection if someone gains access to the key file. You can leave it blank, but doing so removes that extra layer of protection. If you choose a passphrase, the SSH agent can save it for your Windows session so you don’t have to type it every time.
Key generation creates two files:
- id_ed25519 is the private key. Keep it on your device and never share or upload it.
- id_ed25519.pub is the public key. This is the file you add to your Git hosting account.
The public key’s filename ends in .pub, but check the full filename before copying or sharing anything. Never paste the contents of the private key into a website, chat, or support request.
Add the public key to your Git hosting account
Copy the public key to your clipboard from PowerShell:
Get-Content “$env:USERPROFILE.sshid_ed25519.pub” | Set-Clipboard
Open your Git hosting account’s settings and find its SSH key section. Add a new authentication key, give it a recognizable name such as “Home PC,” and paste the clipboard contents into the public key field. Save the key. The menu names differ between providers, so make sure you’re adding an SSH authentication key rather than another type of key, such as a signing key.
If you’d rather inspect the public key before copying it, run Get-Content “$env:USERPROFILE.sshid_ed25519.pub”. The output should be a single long line that begins with the key type. Copy that entire line, not the private key file without the .pub extension.
Load the key with the Windows SSH agent
The SSH agent can keep your unlocked key available to programs during your session. This is especially helpful when you set a passphrase. In PowerShell, check the agent with Get-Service ssh-agent.
If the service is stopped or disabled, open PowerShell as an administrator and run:
- Set-Service -Name ssh-agent -StartupType Automatic
- Start-Service ssh-agent
Close the administrator window and return to your regular PowerShell session. Add the private key to the agent with ssh-add “$env:USERPROFILE.sshid_ed25519”. Enter the passphrase if prompted. You can check which keys the agent has loaded by running ssh-add -l.
Using the agent doesn’t make the private key safe to share. It simply helps SSH-based programs use your key without asking for its passphrase on every connection. If you prefer not to start the agent automatically, you can start it when needed and add the key for that session.
Test SSH authentication and Git access
For a GitHub account, test the connection with ssh -T git@github.com. On the first connection, SSH may ask whether to trust the server’s host key. Verify the fingerprint using the service’s official guidance before accepting it. This check helps confirm you’re connecting to the expected server.
If authentication succeeds, the service should identify the account associated with your key. It may also explain that shell access isn’t available. That message is normal for a Git hosting service: the test checks authentication, not whether you can open a command-line session on the provider’s server.
To use SSH with a repository, its remote address needs to use SSH rather than HTTPS. Check the current address from inside the repository folder with git remote -v. An SSH address typically starts with git@ and includes the provider and repository name. If the remote uses HTTPS, update it with the SSH address provided by your hosting service. For example, GitHub’s format is git@github.com:OWNER/REPOSITORY.git; replace the placeholders with the repository’s actual owner and name.
Try a Git operation such as git fetch to confirm the repository can authenticate. If you’re still setting up your command-line workflow, keep the repository’s remote address consistent across your local projects so Git doesn’t switch between HTTPS and SSH unexpectedly.
Fix common SSH key problems
Permission denied (publickey)
This error usually means the server didn’t accept a key offered by your computer. Confirm that the matching public key is saved in the correct account, then check that the private key is loaded with ssh-add -l. Also verify the username and host in the SSH address. For GitHub, the SSH username is git, not your personal account name.
Git works in one terminal but not another
Windows can have more than one SSH program installed. PowerShell, Windows Terminal, and Git Bash may resolve different executables or use different agents. In PowerShell, run Get-Command ssh to see which SSH program is being used. If Git Bash behaves differently, check its SSH path with which ssh and make sure the program Git uses can access the key or agent you configured.
You can tell Git to use Windows’ built-in OpenSSH client by running git config –global core.sshCommand “C:/Windows/System32/OpenSSH/ssh.exe”. Use this only if that file exists on your system and you want Git to use that client consistently.
The key file is missing or has a different name
List the files in your SSH folder with Get-ChildItem “$env:USERPROFILE.ssh”. If you created a key under a custom filename, add that exact private key path to the agent. When a computer has several keys, SSH may need a configuration entry to select the right one for a particular host. Start by testing one key at a time so you can identify which file the service expects.
Keep your SSH keys secure
Treat the private key like a password that grants access to the accounts where its public key is registered. Don’t email it, commit it to a repository, or place it in a shared folder. A passphrase provides additional protection, and using a separate key for each device makes it easier to revoke access when a device is lost or replaced.
If you think a private key has been exposed, remove its public key from the accounts that trust it and create a replacement pair. Adding the new public key alone doesn’t invalidate the old one. Remove the compromised key from the services where it was registered.
Once the key is installed, the agent is running, and the SSH test succeeds, Git can authenticate through SSH without repeatedly requesting your hosting account password. Keep the private key local, verify that your repository uses an SSH remote, and you’ll have a setup that’s straightforward to troubleshoot later.