SSH keys are one of those DevOps basics that make everything smoother: Git over SSH, server access, automation, and fewer password prompts.

Padlock and key over schematic network grid

This guide walks you through generating a key on Windows, loading it into ssh-agent, and using it safely with Git and remote servers.

Before you start, it helps to know what you’re aiming for: a private key that stays on your PC, and a public key you paste into Git hosting or a server.

1) Check what SSH you already have on Windows

Windows 10/11 typically includes OpenSSH, but it’s worth confirming so you don’t fight the wrong toolchain.

Open PowerShell and run:

ssh -V

If you get a version back, you’re good. If not, install the Windows feature “OpenSSH Client” (Settings → Apps → Optional features).

Folder and key file icons on blueprint grid

2) Generate a new SSH key (recommended defaults)

Create a modern key using Ed25519 (good security and small size). In PowerShell:

ssh-keygen -t ed25519 -C "your-email@example.com"

When prompted for a file path, the default is usually right:

C:\Users\YOU\.ssh\id_ed25519

Set a passphrase unless you have a strong reason not to. It protects your key if your machine or backups are ever exposed.

3) Add the key to ssh-agent (so you don’t retype the passphrase)

On Windows, ssh-agent can run as a service. In PowerShell:

  • Start the agent: Start-Service ssh-agent
  • Optional: set it to start automatically: Set-Service -Name ssh-agent -StartupType Automatic
  • Add your key: ssh-add $env:USERPROFILE\.ssh\id_ed25519

If it asks for your passphrase, enter it once per session (or once after reboot, depending on setup).

Agent node managing connected key signals

4) Add your public key to Git hosting (GitHub/GitLab/etc.)

You never upload your private key. You only paste the public key contents.

Show the public key in PowerShell:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub

Copy the full line (starts with ssh-ed25519) and add it in your Git hosting account under SSH keys.

Then test with something like:

ssh -T git@github.com

The exact host varies by provider, but the pattern is the same.

5) Use SSH for Git remotes (and verify you’re actually using it)

Your repo remote should look like an SSH URL, not HTTPS.

  • SSH form: git@github.com:org/repo.git
  • HTTPS form: https://github.com/org/repo.git

To check:

git remote -v

To change an existing remote to SSH:

git remote set-url origin git@github.com:ORG/REPO.git

6) Connect to servers cleanly with a simple SSH config

If you manage multiple servers or multiple keys, an SSH config file prevents mistakes and saves time.

Create or edit:

C:\Users\YOU\.ssh\config

Example:

Host prod-web HostName 203.0.113.10 User deploy IdentityFile C:\Users\YOU\.ssh\id_ed25519

Then connect with:

ssh prod-web

Shield check beside abstract terminal block

7) Common SSH problems on Windows (fast fixes)

Most SSH issues come down to one of a few predictable causes. Here’s a quick checklist.

  • Permission denied (publickey): the public key isn’t installed on the server/provider, or you’re using the wrong key file.
  • Passphrase keeps prompting: ssh-agent isn’t running, or the key wasn’t added with ssh-add.
  • Host key verification failed: the server host key changed; confirm it’s expected, then remove the old entry from ~\.ssh\known_hosts.
  • Wrong account used: your SSH config needs a User line, or Git hosting needs a different key mapped to the correct account.
  • Stuck behind a proxy/firewall: try port 443 SSH options from your provider (many support this) or confirm outbound 22 is allowed.

If you need deeper visibility, run a verbose test:

ssh -vvv user@host

Takeaway: keep one good key workflow and document it

Generate an Ed25519 key, protect it with a passphrase, load it into ssh-agent, and use an SSH config to avoid accidental key/account mix-ups. Once it’s set up, Git and server access become boring—in a good way.