TortoiseGit least-privilege auth on shared Windows: GCM HTTPS tokens or Pageant SSH keys?

Answer first

For a shared Windows workstation with multiple developers, per-user GCM HTTPS tokens give stronger least-privilege guarantees than per-session Pageant SSH keys, provided each developer uses a separate Windows user profile. GCM stores credentials in Windows Credential Manager which is encrypted per Windows user profile and can be scoped to fine-grained, short-lived PATs. Pageant holds a decrypted private key in memory for the whole login session and typically grants account-wide access unless server-side restrictions are applied.

Expired-credential recovery differs: GCM will re-prompt for a token and can be cleared from Credential Manager; Pageant with a revoked or expired key returns "permission denied (publickey)" with no interactive recovery prompt, requiring the user to reload or replace the key in the agent.

TortoiseGitPlink vs OpenSSH materially changes isolation. TortoiseGitPlink uses PuTTY Pageant and PuTTY .ppk keys. TortoiseGit OpenSSH uses the Windows OpenSSH ssh-agent. Both keep keys decrypted in memory, but OpenSSH integrates with the native Windows user session and standard OpenSSH key formats, making key management and per-user agent separation more predictable than Pageant.

Confirmed facts

• Windows Credential Manager stores credentials per Windows user profile and is not accessible to other local Windows users.
• Git Credential Manager for Windows can store HTTPS tokens and supports interactive re-prompt on auth failure.
• TortoiseGit SSH client setting selects between TortoiseGitPlink and OpenSSH, which changes the agent and key format used.
• Pageant holds decrypted private keys in memory for the duration of the user session.

Likely explanation

Least-privilege is limited by the OS isolation boundary. If developers share a single Windows user profile, both Credential Manager and Pageant are shared, and neither approach provides isolation. With separate Windows profiles, GCM tokens can be scoped to repo or action and rotated per developer without affecting others. SSH deploy keys per repository are possible, but Pageant is usually loaded with a user’s personal key, giving broader access than a scoped token, and revocation is silent.

Steps needed for this case

1. Confirm OS isolation: verify each developer logs in with a distinct Windows user account. If not, neither option provides least-privilege.
2. Verify GCM is active: run git config --global credential.helper and expect manager or manager-core.
3. Use HTTPS remotes with scoped PATs per developer, short lifetime where supported.
4. Clear stale entries on shared machines: Credential Manager > Windows Credentials > remove git:https:// entries for the host.
5. Set TortoiseGit to use OpenSSH rather than TortoiseGitPlink to avoid Pageant and use the native Windows ssh-agent if SSH must be used.
6. For SSH, load keys with a passphrase and unload from agent on logout; do not leave Pageant running across user switches.

One missing diagnostic detail that changes the recommendation: are developers using separate Windows user profiles or the same Windows user account on the shared workstation? If the same OS user is shared, credential isolation cannot be achieved with either GCM or Pageant without additional controls.