See the docs on:

• Connecting to GitHub with SSH
• All SSH manuals
• SSH client conf
• SSH's "include" directive
• Using ssh with vs code devcontainers

# Set YOUR_WINDOWS_USERNAME to whatever it is.
YOUR_WINDOWS_USERNAME=example
mkdir -p /mnt/c/Users/$YOUR_WINDOWS_USERNAME/.ssh
ln -s /mnt/c/Users/$YOUR_WINDOWS_USERNAME/.ssh ~/.ssh

# LOCAL_WINDOWS_USERNAME set in some bashrc before these aliases are used
alias tracking="git ls-tree --full-tree --name-only -r HEAD"
alias wsl_resym_ssh="( shopt -s dotglob; WINDOWS_PATH=\"/mnt/c/Users/\$LOCAL_WINDOWS_USERNAME/\"; for f in \$WINDOWS_PATH.ssh/*; do  grep -qx \"\$(tracking)\" <<< \"\${f/\$WINDOWS_PATH/}\" && echo \"TRACKED FILE NOT SYM'd \$f\" || (echo \"UNTRACKED WILL BE LINKED \$f\" && ln -sf \"\$f\" ~/\${f/\$WINDOWS_PATH/}); done )"

In bash

# Make the key
EMAIL=your_email@example.com
KEYNAME=GH_Username
ssh-keygen -t ed25519 -C "$EMAIL" -f ~/.ssh/$KEYNAME

In pwsh

# Make the key
$EMAIL = "your_email@example.com"
$KEYNAME = "GH_Username"
ssh-keygen -t ed25519 -C "$EMAIL" -f "$HOME/.ssh/$KEYNAME"

In cmd

set EMAIL=your_email@example.com
set KEYNAME=GH_Username
ssh-keygen -t ed25519 -C "%EMAIL%" -f "%userprofile%\.ssh\%KEYNAME%"

Upload the public key to https://github.com/settings/ssh/new as an "Authentication Key" with some name.

In bash or pwsh (assuming you still have KEYNAME set from creating above)

cat ~/.ssh/$KEYNAME.pub

In cmd (assuming you still have KEYNAME set from creating above)

type "%userprofile%\.ssh\%KEYNAME%.pub"

If you're going to chmod you might need to add the following to sudo vi /etc/wsl.conf from WSL

[automount]
options = "metadata"

and then close all sessions and wsl --shutdown from cmd/pwsh, and apply the user read only permissions to the key, which is required by *nix's openssh but appears to have no affect on windows' ssh-agent.

chmod 400 ~/.ssh/$KEYNAME # Variable name is example only, and won't always work here, favour not using variable.

Get-Service -Name ssh-agent | Start-Service
# Or to make it automatic, from an admin pwsh
Get-Service -Name ssh-agent | Set-Service -StartupType Automatic

Add the following to ~/.bashrc to allow ssh-agent to start automatically.

if [ -z "$SSH_AUTH_SOCK" ] ; then
    eval `ssh-agent -s` > /dev/null
    # ssh-add
fi

Without this, it can be started manually each time with eval "$(ssh-agent -s)"

ssh-add ~/.ssh/$KEYNAME

This should show you which keys the agent is aware of, and which one is being used by ssh. You should treat the agent as ephemeral. It's best to only have whatever key you need to use loaded one at a time. You can run ssh-add -D to remove all currently added keys if necessary, then manually add back ssh-add path/to/file. That's best to do, but if you need to test what it's doing, here's how.

ssh-add -l
ssh -vT git@github.com

By using the ssh -v setting in the environment variable GIT_SSH_COMMAND (which supersedes GIT_SSH), and trying to git pull / clone for an account that has its key in the agent, we can see an issue. It appears git uses the ssh-agent on *nix by default but not on windows? To add ssh-agent to the keys tried by git on windows, open powershell and;

[Environment]::SetEnvironmentVariable("GIT_SSH", "$((Get-Command ssh).Source)", [System.EnvironmentVariableTarget]::User)

Which should be a persistent fix!

However, the ssh reference in pwsh is slightly more cumbersome. For some reason, although backslashes cause no issue in GIT_SSH, as set by the above, Write-Host $env:GIT_SSH_COMMAND yielding the same output as Write-Host $env:GIT_SSH results in git trying to use the path for Get-Command ssh without backslashes. So to add verbose temporarily to GIT_SSH_COMMAND in pwsh, we need the following.

[Environment]::SetEnvironmentVariable("GIT_SSH_COMMAND", "$(((Get-Command ssh).Source).replace('\','/')) -v", [System.EnvironmentVariableTarget]::Process)

Git's SSH doesn't retry when a key is accepted but not valid. That is to say, when multiple keys are added to the agent, it appears the first key that could be accepted by the site, will be. In other words, if multiple keys will be accepted by a server, because they are all valid for something, the first key to be accepted, might not be valid for the account you're trying to access!! For example, ssh-add A followed by ssh-add B will make git attempt to use key B first. If the account for the repo you're working with has key A attached to it, and B is attached to some other account, then key B will be "accepted", and then subsequently denied as not being for that account.

The agent, besides however it interacts with keychain on mac, is totally ephemeral on wsl. So it would not be unreasonable to assume if you want to work with the ssh-agent to handle keys, that you'd be familiar with ssh-add -l to list the keys in the agent, and ssh-add -D to remove all active one. While The agent is ephemeral on WSL, and will need specific keys added on each start up, without a default one being loaded in an rc, Windows appears to store the keys in the agent permanently, so would need to have the previous entry deleted before adding another (it will use whatever the most recent unique addition was that was not already present).

If you've been using some https method, you'll need to update, or add a remote that uses ssh instead.

# HTTPS format is https://github.com/USERNAME/REPOSITORY.git
git remote get-url --all origin
git remote set-url origin git@github.com:USERNAME/REPOSITORY.git

To set up an ssh+git config to automate swapping ssh identities used in repos according to containing directory, see this stack question.