Jitsumi

Set Up an SSH Key for GitHub on Windows with Git Bash

Create an Ed25519 key in Git Bash, add only its public half to GitHub, test SSH, and check whether an existing Git remote still uses HTTPS.

Conceptual illustration of a protected private key beside a Windows PC and a separate public key near a remote server.

Choosing SSH when you clone a GitHub repository changes how Git authenticates. Your PC keeps a private key; GitHub stores the matching public key. When the two match, GitHub can identify your account, while repository permissions still decide what you may do.

This guide uses Git Bash from Git for Windows for the key, agent and connection test, so the SSH commands and Git work in the same shell. You do not need to make your PC an SSH server. If you want other devices on your home network to connect to Windows, see our OpenSSH Server guide for local access. This guide follows GitHub and Microsoft documentation available by 6 December 2025; it is not a report of a machine-specific test. GitHub’s SSH guide explains the account flow.

Use an SSH client, not an SSH server

The ssh command starts an outbound connection from your computer. sshd is a different program that waits for incoming connections. Connecting from Windows to GitHub needs the client; it does not require enabling Windows OpenSSH Server or opening a port on your router. Microsoft’s OpenSSH overview for Windows describes the client and server roles.

Open Git Bash. Before generating anything, check the usual SSH folder:

ls -al ~/.ssh

Look for a private key and its matching .pub file, such as id_ed25519 and id_ed25519.pub. If you already have a key you control, you can use it. Do not overwrite a key that another service or computer still needs. GitHub’s existing-key check lists the common filenames.

Create a key only if you need one

In Git Bash, run:

ssh-keygen -t ed25519 -C "windows-gitbash"

The -C value is a comment that helps identify the key; it is not used to sign you in. When asked where to save it, press Enter for the default ~/.ssh/id_ed25519 only if that file does not already exist. Otherwise enter a different name, such as ~/.ssh/id_ed25519_github, and use that same name in the commands below.

Choose a passphrase when prompted. The private key is the file without .pub; keep it on your PC and never paste or upload it. The .pub file is the public half that you can add to your GitHub account. GitHub recommends Ed25519 for a new key and documents key generation and passphrases.

Load the key into Git Bash’s agent

An SSH agent can hold the unlocked key for your Git Bash session, so you do not have to type the passphrase for every connection. Start the agent and add the private key:

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

Enter the passphrase when asked. The final command should list the key now loaded in the agent. If you chose a custom filename, replace id_ed25519 with it. This agent belongs to the current Git Bash environment; if a later shell cannot see the key, start an agent there and add it again. A default-named key can also be used without the agent, with a passphrase prompt when needed. A custom-named key is not discovered just from its filename: if you skip the agent, configure SSH to select that key explicitly. GitHub documents passphrase handling for Git for Windows.

Add only the public key to GitHub

Copy the public key—not the private one—to the Windows clipboard:

clip < ~/.ssh/id_ed25519.pub

In GitHub, open Settings → SSH and GPG keys → New SSH key. Give it a label that identifies this PC, choose Authentication as the key type, paste the public key and save it. If you created a custom-named key, copy its .pub file instead. GitHub’s account-key instructions distinguish authentication keys from keys used for commit signing.

Verify the connection before changing a repository

In the same Git Bash window, run:

On a first connection, SSH may ask whether to trust GitHub’s server key. Compare the displayed fingerprint with GitHub’s published SSH key fingerprints before accepting it. This is a check of GitHub’s identity; it is separate from the user key you just added.

A successful test greets your GitHub username and says that GitHub does not provide shell access. That message means authentication worked: GitHub accepts SSH for Git operations, not an interactive shell. GitHub’s connection test instructions also note that this command can exit with status 1 even when the greeting confirms success.

Make sure the repository uses SSH

Adding a key does not change the URL saved in an existing local repository. Check it with:

git remote -v

If the URL starts with https://, Git is still using HTTPS. Copy the repository’s SSH URL from GitHub and set it for the correct remote name; for the common name origin, the command looks like this:

git remote set-url origin [email protected]:OWNER/REPOSITORY.git
git remote -v

Replace OWNER/REPOSITORY with the actual path, then check that both fetch and push show the SSH URL. GitHub’s remote repository guide documents this command. A working ssh -T confirms the account-level connection; the account must still have access to the repository, and its rules still apply to pushes.

If ssh -T reports Permission denied (publickey), check that the public key was added to the account you expect and that ssh-add -l lists the matching private key. If the test succeeds but Git still asks for HTTPS credentials, inspect git remote -v again. Keep the private key private; only the .pub file belongs in GitHub.

Subscribe

Get new articles by email. Unsubscribe with one click.

Share this post

Newsletter

New posts from Jitsumi, by email

One email when a new post goes up. Nothing else, and you can leave with one click.