Standardize TortoiseGit SSH on OpenSSH ssh-agent While Keeping Pageant for Legacy Windows

The decision Windows teams face with TortoiseGit SSH

Windows developers using TortoiseGit often end up with two SSH stacks: PuTTY Pageant for existing .ppk keys and Windows OpenSSH ssh-agent for new machines. The practical decision is to standardize new Windows 10/11 workstations on OpenSSH ssh-agent, and keep Pageant support only for legacy machines. This reduces tool sprawl and aligns key formats with Linux/macOS, without breaking existing repos.

The decision is constrained by how TortoiseGit invokes Git. TortoiseGit Settings > Network > SSH client controls which binary Git uses for SSH URLs. The client must be on PATH or explicitly pointed to, private keys must be in a format the chosen client understands, and the team needs a GUI-friendly way to unlock keys at login.

Options and constraints

Version sensitivity matters. Reliable OpenSSH support in the TortoiseGit SSH client dropdown stabilized around TortoiseGit 2.13+ with Git for Windows 2.38+. Older installs can silently fall back to plink.

Trade-offs

PuTTY offers familiar GUI key conversion via PuTTYgen and a visible Pageant unlock prompt. It works today for teams already invested in .ppk files. The cost is extra tools, .ppk lock-in, and a separate agent that does not share keys with WSL or native OpenSSH.

OpenSSH reduces tool sprawl, supports ed25519 and ssh-agent key lifetime policies, and matches workflows used on Linux/macOS. It requires converting .ppk to OpenSSH format and ensuring the Windows OpenSSH Authentication Agent starts on login. Private key file ACLs must be restricted to the user, otherwise ssh-agent refuses to load the key and TortoiseGit will prompt for a password.

For mixed teams, keep both paths documented. Changing the SSH client in TortoiseGit Settings > Network affects all repositories for that user profile.

Concrete implementation for new workstations

Assumptions: Windows 10/11, TortoiseGit 2.13+ installed, Git for Windows 2.38+ installed, existing .ppk key at %USERPROFILE%\.ssh\.ppk.

1. Convert .ppk to OpenSSH

Run PuTTYgen on the workstation. Load the .ppk, then export OpenSSH private key. Save to %USERPROFILE%\.ssh\. Save the public key to %USERPROFILE%\.ssh\.pub. Risk: the exported private key is unencrypted unless a passphrase is set. Protect the file with NTFS permissions.

2. Ensure ssh-agent is available at login

Open services.msc as administrator. Locate OpenSSH Authentication Agent. Set Startup type to Automatic. This ensures ssh-agent is running when TortoiseGit starts. On first use, the agent may prompt for the key passphrase.

3. Load the key into the agent

Open PowerShell as the user. Run:

ssh-add $env:USERPROFILE\.ssh\

Expected check: the command returns without error and the key is listed by ssh-add -l. If the key file ACL is too permissive, ssh-agent refuses to load it.

4. Point TortoiseGit to OpenSSH

Open TortoiseGit Settings > Network. Set SSH client to C:\Windows\System32\OpenSSH\ssh.exe. This path is the Windows built-in OpenSSH client. Changing this setting affects all repos for the user.

Rollback: revert the SSH client path to the previous plink.exe path in the same dialog if authentication fails.

Validation without assuming success

Open TortoiseGit Settings > Git > Test to confirm Git is reachable. Then from a repository context menu run Fetch. Check TortoiseGitProc log for the SSH client used. The log should reference ssh.exe rather than plink.exe.

Run in PowerShell:

ssh-add -l

Confirm the fingerprint of the loaded key matches the key you expect to use for the remote.

Test a fresh clone via TortoiseGit Clone dialog with an SSH URL. With the key loaded, no password prompt should appear for the key passphrase. If a prompt appears, verify the SSH client path, key permissions, and that the key is loaded in ssh-agent.

Limitations

OpenSSH ssh-agent does not import .ppk directly. Conversion is required and is one-way for passphrase handling. Teams with automated Pageant startup scripts need a parallel document for legacy machines. Key permissions on Windows are strict; shared folders or overly permissive ACLs will block ssh-agent loading.