Dwa konta GitHub, jeden komputer · krok 3 z 6

Windows: klucze SSH i agent

PowerShell, OpenSSH, Credential Manager i pułapka 32-bit vs 64-bit.

1. Wygeneruj dwa klucze SSH

W PowerShell lub Git Bash:

ssh-keygen -t ed25519 -f C:/Users/TWOJANAZWA/.ssh/id_ed25519_user1 -C "user1@example.com"
ssh-keygen -t ed25519 -f C:/Users/TWOJANAZWA/.ssh/id_ed25519_user2 -C "user2@example.com"

Podczas generowania możesz ustawić passphrase (zalecane) — obsługę tego, żeby nie trzeba było wpisywać go za każdym razem, opisuje sekcja niżej.

2. Dodaj klucze publiczne na GitHubie

Zawartość plików id_ed25519_user1.pub i id_ed25519_user2.pub dodaj w Settings → SSH and GPG keys na odpowiednich kontach GitHub — każdy klucz do innego konta.

3. Podepnij klucze w `.gitconfig-userX`

Zgodnie z krokiem 1 tutoriala, w core.sshCommand podaj pełną ścieżkę Windows ze slashami /:

[core]
    sshCommand = "ssh -i C:/Users/TWOJANAZWA/.ssh/id_ed25519_user1 -o IdentitiesOnly=yes"

4. Zmień remote repozytorium na SSH

git remote set-url origin git@github.com:user1/nazwa-repo.git
git remote -v

Jeśli remote nadal zaczyna się od https:// — właśnie to jest zwykle przyczyną, dla której push idzie na konto, przez które jesteś zalogowany w przeglądarce/VS Code, a nie na to wskazane przez klucz SSH.

5. Test połączenia

ssh -T -i C:/Users/TWOJANAZWA/.ssh/id_ed25519_user1 -o IdentitiesOnly=yes git@github.com

Powinieneś zobaczyć Hi user1! You've successfully authenticated.... Powtórz dla user2.

6. Żeby nie wpisywać passphrase przy każdym pushu

Windows ma wbudowaną usługę OpenSSH Authentication Agent, ale domyślnie jest wyłączona.

a) Włącz usługę i ustaw autostart (PowerShell jako Administrator):

Set-Service -Name ssh-agent -StartupType Automatic
Start-Service ssh-agent
Get-Service ssh-agent

Status powinien pokazać Running.

b) Dodaj oba klucze do agenta:

ssh-add C:/Users/TWOJANAZWA/.ssh/id_ed25519_user1
ssh-add C:/Users/TWOJANAZWA/.ssh/id_ed25519_user2

Przy każdym poda Cię o passphrase — wpisujesz raz, potem klucz siedzi w pamięci agenta do końca sesji Windows.

Sprawdź:

ssh-add -l

Pułapka 32-bit vs 64-bit: jeśli ssh-add zgłasza The term 'ssh-add' is not recognized, mimo że plik C:\Windows\System32\OpenSSH\ssh-add.exe fizycznie istnieje — najpewniej działasz w 32-bitowej wersji PowerShell (x86). WOW64 przekierowuje wtedy System32 na SysWOW64, gdzie tego folderu nie ma. Sprawdź: [Environment]::Is64BitProcess (powinno być True). Otwórz zwykły, 64-bitowy PowerShell (bez dopisku (x86) w nazwie na liście Start) i spróbuj ponownie.

c) Pamiętaj: klucze dodane przez ssh-add znikają po restarcie komputera — trzeba je dodać ponownie (raz, jednym poleceniem na klucz).

Alternatywy, jeśli nie chcesz agenta

Usunąć passphrase z klucza (ssh-keygen -p -f ścieżka_do_klucza, puste nowe hasło) — wygodne, ale plik klucza staje się w pełni użyteczny dla każdego, kto uzyska do niego dostęp. Sensowne tylko na w pełni zaszyfrowanym dysku (BitLocker), na komputerze, do którego nikt inny nie ma dostępu.
Pageant (z pakietu PuTTY) — osobny agent z możliwością automatycznego ładowania kluczy przy starcie systemu.

Wyczyszczenie starych danych logowania HTTPS

Jeśli wcześniej logowałeś się przez HTTPS, Windows mógł zapisać dane w Credential Managerze i mieszać je z nowym setupem SSH:

cmdkey /list | findstr github
cmdkey /delete:NAZWA_WPISU

(nazwę wpisu odczytaj z wyniku /list — zwykle coś w stylu git:https://github.com)