Konfiguracja SSH dla GitHub i GitLab – od ssh-keygen do git clone

Za każdym razem, gdy przygotowuję nowy komputer do pracy, jedną z pierwszych rzeczy jest klucz SSH. To on pozwala mi klonować repozytoria, robić git pull i git push na GitHubie czy GitLabie bez wpisywania loginu i tokena przy każdej operacji.

Cała konfiguracja zajmuje kilka minut. Generujesz parę kluczy, przekazujesz klucz prywatny agentowi SSH, a publiczny wklejasz w ustawieniach konta. Na koniec ustawiasz w Gicie, kto podpisuje commity – i komputer jest gotowy.

Poniżej opisuję to tak, jak robię to sam na Windowsie w Git Bash, z dopiskami dla macOS i Linuxa.

Wersja dla niecierpliwych

Jeśli wiesz, co robisz, i potrzebujesz tylko listy komend – oto ona (Git Bash na Windowsie):

ssh-keygen -t rsa -b 4096 -C "twoj@mail.com"
eval $(ssh-agent -s)
ssh-add ~/.ssh/id_rsa
clip < ~/.ssh/id_rsa.pub

Co robi każda linijka:

• ssh-keygen – generuje nową parę kluczy,
• eval $(ssh-agent -s) – startuje agenta SSH w bieżącej sesji,
• ssh-add ~/.ssh/id_rsa – przekazuje agentowi klucz prywatny,
• clip < ~/.ssh/id_rsa.pub – wrzuca klucz publiczny do schowka.

Potem jeszcze dane autora commitów:

git config --global user.email "twoj@mail.com"
git config --global user.name "Imię i nazwisko"

Pamiętaj, że to dwie niezależne sprawy. Klucz SSH decyduje o tym, czy masz dostęp do zdalnego repozytorium. user.name i user.email mówią Gitowi, kogo zapisać jako autora zmian.

1. Otwórz Git Bash

Na Windowsie pracuję w Git Bash – terminalu, który instaluje się razem z Git for Windows. Daje dostęp do tych samych poleceń, których używa się na Linuxie i macOS, więc komendy z tego poradnika działają bez przeróbek.

Wpisz w menu Start:

Git Bash

i otwórz aplikację. Uprawnienia administratora nie są potrzebne – zwykłe uruchomienie w zupełności wystarczy.

Git Bash w wynikach wyszukiwania menu Start.

2. Wygeneruj parę kluczy

W terminalu wpisz:

ssh-keygen -t rsa -b 4096 -C "twoj@mail.com"

W miejsce twoj@mail.com wstaw swój adres. Ja podaję ten, którego używam na GitHubie lub GitLabie – choć tutaj jest to tylko etykieta, która pomaga później rozpoznać klucz na liście.

Rozbiór komendy

• ssh-keygen – narzędzie do tworzenia kluczy,
• -t rsa – typ klucza (algorytm RSA),
• -b 4096 – długość klucza w bitach,
• -C – komentarz dopisany do klucza, zwykle adres e-mail.

Gdzie zapisać klucz?

Terminal najpierw zapyta o lokalizację pliku:

Enter file in which to save the key

Enter oznacza zgodę na domyślną ścieżkę. W Windowsie klucze trafią do folderu:

C:\Users\NazwaUżytkownika\.ssh\

który Git Bash pokazuje w uniksowym zapisie:

/c/Users/NazwaUżytkownika/.ssh/

Powstaną dwa pliki:

id_rsa
id_rsa.pub

id_rsa to klucz prywatny – zostaje tylko na Twoim komputerze. Nigdy go nie wysyłaj, nie wrzucaj do repozytorium i nie wklejaj do żadnego formularza.

id_rsa.pub to klucz publiczny. Właśnie jego treść trafi za chwilę do ustawień GitHub lub GitLab.

Passphrase – ustawiać czy nie?

Następne pytanie dotyczy hasła do klucza:

Enter passphrase

Passphrase szyfruje klucz prywatny na dysku. Jeśli ktoś skopiuje plik id_rsa, bez hasła nic z nim nie zrobi. Na laptopie, który nosisz ze sobą, albo na sprzęcie służbowym zdecydowanie warto je ustawić.

Możesz też dwa razy wcisnąć Enter i zostawić klucz bez hasła. Jest wygodniej, ale mniej bezpiecznie. Dobra wiadomość: agent SSH zapamiętuje odblokowany klucz na czas sesji, więc hasło z passphrase wpisujesz raz, a nie przy każdym git push.

Gdy wszystko pójdzie dobrze, zobaczysz mniej więcej taki komunikat:

Your identification has been saved in /c/Users/uzytkownik/.ssh/id_rsa
Your public key has been saved in /c/Users/uzytkownik/.ssh/id_rsa.pub

Tworzenie pary kluczy RSA 4096 w Git Bash.

RSA czy Ed25519?

W tym poradniku używam RSA 4096, bo działa praktycznie wszędzie i zgadza się z tym, co widać na zrzutach ekranu.

Jeśli konfigurujesz coś od zera, możesz wybrać nowszy Ed25519:

ssh-keygen -t ed25519 -C "twoj@mail.com"

Klucz Ed25519 jest krótszy i dziś to częsty wybór w nowych konfiguracjach. RSA przydaje się tam, gdzie liczy się zgodność ze starszymi serwerami albo firmową infrastrukturą.

Mechanizm jest w obu przypadkach identyczny: prywatna część zostaje u Ciebie, publiczną wklejasz do serwisu. Jeśli wybierzesz Ed25519, w dalszych komendach zamiast id_rsa używaj id_ed25519.

3. Wystartuj agenta SSH

Kolejny krok to uruchomienie ssh-agent:

eval $(ssh-agent -s)

Agent to mały proces działający w tle, który trzyma klucze w pamięci. Kiedy Git łączy się z serwerem, pyta agenta o klucz – i nie musisz niczego wskazywać ręcznie.

W odpowiedzi terminal wypisze numer procesu:

Agent pid 1188

To znak, że agent działa w tej sesji terminala. Samo wygenerowanie klucza nie dodaje go do agenta – dlatego najpierw uruchamiam agenta, a dopiero potem wykonuję ssh-add.

4. Przekaż agentowi klucz prywatny

Teraz wskazujesz agentowi, którego klucza ma używać:

ssh-add ~/.ssh/id_rsa

Tylda ~ to skrót do katalogu domowego, więc ścieżka:

~/.ssh/id_rsa

prowadzi do prywatnego klucza, który przed chwilą wygenerowałeś.

Jeśli ustawiłeś passphrase, terminal poprosi teraz o nie. Po sukcesie zobaczysz:

Identity added

Listę kluczy załadowanych do agenta pokazuje:

ssh-add -l

Klucz RSA dodany do agenta SSH.

Jeśli na liście widnieje odcisk (fingerprint) Twojego klucza – wszystko jest na swoim miejscu.

5. Skopiuj klucz publiczny

Teraz potrzebujesz zawartości pliku id_rsa.pub. Sposób zależy od systemu.

Windows (Git Bash)

clip < ~/.ssh/id_rsa.pub

Komenda nic nie wypisze – i tak ma być. Klucz jest już w schowku, gotowy do wklejenia przez Ctrl + V.

Zwróć uwagę na końcówkę .pub. Kopiujesz:

id_rsa.pub

a nie plik id_rsa bez rozszerzenia.

macOS

Na Macu odpowiednikiem clip jest pbcopy:

pbcopy < ~/.ssh/id_rsa.pub

Linux

Na Linuxie użyj xclip (X11) albo wl-copy (Wayland), jeśli masz je zainstalowane:

xclip -selection clipboard < ~/.ssh/id_rsa.pub

Najprostsza metoda, działająca wszędzie, to wypisanie klucza na ekran:

cat ~/.ssh/id_rsa.pub

i ręczne skopiowanie całej linii zaczynającej się od ssh-rsa (lub ssh-ed25519).

6. Wklej klucz na GitLabie

Zaloguj się do GitLaba, otwórz ustawienia swojego profilu i przejdź do sekcji:

Access → SSH keys

Zobaczysz tam listę dodanych już kluczy i przycisk:

Add new key

Po kliknięciu otworzy się formularz z kilkoma polami.

Key

Tu wklejasz skopiowany klucz publiczny. Powinien zaczynać się od:

ssh-rsa

lub:

ssh-ed25519

Wklejasz treść klucza, a nie nazwę pliku czy ścieżkę do niego – to częsty błąd przy pierwszej konfiguracji.

Title

Nazwa, po której rozpoznasz urządzenie. Ja wpisuję nazwę laptopa:

Omnibook5

Dobrze sprawdzają się też opisowe nazwy:

Laptop prywatny
Komputer służbowy
Windows PC

Kiedy za rok będziesz chciał odebrać dostęp staremu komputerowi, od razu będziesz wiedział, który klucz usunąć.

Usage type

Do codziennej pracy z repozytoriami zostawiam domyślne:

Authentication & Signing

Expiration date

Pole opcjonalne. W firmach polityka bezpieczeństwa często wymusza datę wygaśnięcia. Puste pole oznacza, że klucz działa, dopóki sam go nie usuniesz.

Na koniec klikasz:

Add key

Formularz dodawania nowego klucza SSH w GitLab.

7. Wklej klucz na GitHubie

Na GitHubie wejdź w ustawienia konta i w lewym menu wybierz:

SSH and GPG keys

Kliknij przycisk dodania nowego klucza SSH. Formularz ma trzy pola:

Title

Nazwa urządzenia, np.:

Omnibook5

Key type

Do zwykłego dostępu do repozytoriów:

Authentication Key

Key

Cała zawartość pliku id_rsa.pub.

Zatwierdzasz przyciskiem:

Add SSH key

GitHub może jeszcze poprosić o hasło do konta albo dodatkowe potwierdzenie tożsamości.

Dodawanie klucza SSH w ustawieniach konta GitHub.

8. Przetestuj połączenie

Zanim sklonuję cokolwiek, zawsze sprawdzam, czy serwer mnie „widzi”.

GitHub

ssh -T git@github.com

GitLab

ssh -T git@gitlab.com

Przy pierwszym połączeniu z danym serwerem pojawi się pytanie:

Are you sure you want to continue connecting?

Jeśli adres się zgadza, odpowiedz:

yes

Odcisk serwera zostanie zapisany w pliku known_hosts i przy kolejnych połączeniach pytanie już się nie pojawi.

Poprawna konfiguracja kończy się powitaniem z Twoją nazwą użytkownika. GitHub doda przy tym, że nie udostępnia dostępu do powłoki – to normalne, bo ta komenda służy tylko do sprawdzenia uwierzytelnienia.

Gdy coś nie działa, uruchom test w trybie szczegółowym:

ssh -vT git@github.com

albo:

ssh -vT git@gitlab.com

Flaga -v pokazuje przebieg połączenia krok po kroku, w tym to, które klucze klient SSH próbuje przedstawić serwerowi. Zwykle już z tego widać, gdzie leży problem.

9. Ustaw autora commitów

Połączenie działa, więc przechodzę do drugiej części – danych autora:

git config --global user.email "twoj@mail.com"
git config --global user.name "Imię i nazwisko"

Na przykład:

git config --global user.email "jan.kowalski@example.com"
git config --global user.name "Jan Kowalski"

Te wartości nie mają nic wspólnego z logowaniem do GitHuba czy GitLaba. Git po prostu wpisuje je do każdego commita jako autora.

Najprościej zapamiętać to tak:

Klucz SSH → czy ten komputer ma dostęp do repozytorium?
Konfiguracja Gita → kto jest autorem tej zmiany?

Robię oba kroki jeden po drugim, żeby przy pierwszym commicie nie zobaczyć komunikatu:

Author identity unknown

Flaga --global zapisuje ustawienia dla wszystkich repozytoriów Twojego użytkownika na tym komputerze.

Ustawianie globalnej nazwy i adresu e-mail autora w Git.

Podgląd konfiguracji Gita

Aktualną nazwę autora wyświetlisz przez:

git config --global user.name

adres e-mail przez:

git config --global user.email

a wszystkie globalne ustawienia naraz przez:

git config --global --list

Kiedy wartości się „gryzą”, przydaje się podgląd z informacją, z którego pliku pochodzi każde ustawienie:

git config --list --show-origin

Konto prywatne i służbowe na jednym komputerze

Jeśli na jednym laptopie pracujesz i prywatnie, i dla firmy, jedna globalna konfiguracja nie wystarczy. W takim przypadku w katalogu konkretnego projektu ustaw dane lokalnie – bez --global:

git config user.name "Imię i nazwisko"
git config user.email "firmowy@mail.com"

Ustawienia lokalne wygrywają z globalnymi. Dzięki temu commity w projektach firmowych idą z adresu służbowego, a wszystkie pozostałe – z prywatnego.

10. Sklonuj repozytorium przez SSH

Teraz można już pobrać projekt. Na stronie repozytorium na GitHubie kliknij:

Code

i przełącz się na zakładkę:

SSH

Adres będzie wyglądał tak:

git@github.com:nazwa-uzytkownika/nazwa-repozytorium.git

Adres SSH repozytorium w menu Code na GitHub.

W Git Bash wpisz:

git clone git@github.com:nazwa-uzytkownika/nazwa-repozytorium.git

Na GitLabie adres ma analogiczną postać:

git clone git@gitlab.com:nazwa-uzytkownika/nazwa-repozytorium.git

Projekt pobierze się do folderu, w którym aktualnie jesteś.

Czy moje repozytorium korzysta z SSH?

W katalogu projektu wpisz:

git remote -v

Adres zaczynający się od:

git@github.com:

albo:

git@gitlab.com:

oznacza połączenie przez SSH.

Jeśli widzisz na początku:

https://

to repozytorium łączy się przez HTTPS i Twój klucz SSH nie będzie w ogóle używany.

Przełączysz je na SSH jedną komendą:

git remote set-url origin git@github.com:nazwa-uzytkownika/nazwa-repozytorium.git

lub w przypadku GitLaba:

git remote set-url origin git@gitlab.com:nazwa-uzytkownika/nazwa-repozytorium.git

Kolejność, która oszczędza nerwów

Kiedy konfiguruję nowy komputer, trzymam się tej sekwencji:

1. Otwieram Git Bash.
2. Generuję parę kluczy.
3. Uruchamiam agenta SSH.
4. Dodaję do niego klucz prywatny.
5. Kopiuję klucz publiczny.
6. Wklejam go na GitHubie lub GitLabie.
7. Testuję połączenie.
8. Ustawiam nazwę i e-mail autora.
9. Kopiuję adres SSH repozytorium.
10. Klonuję projekt.

Część kroków po prostu wynika z poprzednich: nie dodasz do agenta klucza, którego jeszcze nie ma, i nie przetestujesz połączenia, zanim klucz publiczny nie trafi na konto.

Dane autora teoretycznie można ustawić w dowolnym momencie. Ja robię to zaraz po teście połączenia, żeby przygotować komputer za jednym podejściem.

Najczęstsze problemy i jak je rozwiązać

Wklejony został klucz prywatny

Na GitHub i GitLab trafia wyłącznie plik z rozszerzeniem .pub.

Ten wklejasz:

id_rsa.pub

Tego nie pokazujesz nikomu:

id_rsa

Jeśli klucz prywatny wyciekł – został wklejony w złe miejsce, wysłany komuś albo trafił do repozytorium – traktuj go jako skompromitowany. Usuń powiązany klucz publiczny z konta, wygeneruj nową parę i zapomnij o starej.

„Could not open a connection to your authentication agent”

Ten komunikat oznacza, że agent nie działa w bieżącej sesji. Uruchom go ponownie:

eval $(ssh-agent -s)

i dodaj klucz jeszcze raz:

ssh-add ~/.ssh/id_rsa

Agent jest pusty

Sprawdź, co agent ma w pamięci:

ssh-add -l

Jeśli odpowiada, że nie ma żadnych tożsamości, wykonaj ponownie ssh-add.

Klucz dodany, a Git dalej pyta o hasło

Najczęściej repozytorium jest podpięte przez HTTPS. Zweryfikuj adres:

git remote -v

Przy adresie https:// polecenia git pull i git push omijają klucz SSH – zmień adres poleceniem git remote set-url, jak opisałem wyżej.

Commity nie przypisują się do mojego profilu

Sprawdź, jaki adres wpisuje Git:

git config user.email

Ten sam adres musi być dodany i zweryfikowany na Twoim koncie GitHub lub GitLab – inaczej serwis nie połączy commitów z profilem.

Bezpieczeństwo klucza prywatnego

Klucz prywatny jest jak hasło do wszystkich repozytoriów, do których masz dostęp. Dlatego nigdy:

• nie wysyłam go mailem ani przez komunikator,
• nie commituję go do repozytorium,
• nie trzymam go w folderze projektu,
• nie kopiuję go na przypadkowe komputery,
• nie wklejam jego treści w internecie.

Na Linuxie i macOS warto dodatkowo zawęzić uprawnienia do plików:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa

Zgubiony laptop albo podejrzenie wycieku? Od razu usuń klucz z konta GitHub lub GitLab i wygeneruj nową parę.

Pytania, które słyszę najczęściej

Czy każde repozytorium potrzebuje własnego klucza?

Nie. Jeden klucz przypisany do konta obsłuży wszystkie repozytoria, do których masz dostęp. Osobne klucze mają sens dla różnych urządzeń, kont albo firmowych środowisk.

Mogę użyć jednego klucza na GitHubie i GitLabie?

Technicznie tak – ten sam klucz publiczny da się dodać do obu serwisów. W poważniejszych zastosowaniach wolę jednak osobne klucze, bo łatwiej nimi zarządzać i w razie potrzeby unieważnić tylko jeden.

Czy klucz SSH zastępuje user.name i user.email?

Nie. Klucz służy do uwierzytelnienia połączenia z serwerem, a user.name i user.email określają autora commita. Potrzebujesz obu.

Dlaczego clip nie działa na Macu ani Linuxie?

Bo clip to narzędzie Windowsa. Na macOS użyj pbcopy, na Linuxie xclip lub wl-copy – albo po prostu wyświetl klucz przez cat i skopiuj go ręcznie.

Czy mogę nie ustawiać passphrase?

Możesz, ale klucz z hasłem jest znacznie lepiej chroniony. Agent SSH sprawia, że hasło wpisujesz raz na sesję, więc w praktyce to niewielka niedogodność.

Po zamknięciu Git Bash agent przestaje działać. Dlaczego?

Agent uruchomiony przez eval $(ssh-agent -s) żyje tylko w danej sesji terminala. Nowe okno nie zna jego zmiennych, więc trzeba go uruchomić ponownie. Można to zautomatyzować, ale sposób zależy od systemu i powłoki, z której korzystasz.

Podsumowanie

Konfiguracja SSH dla GitHub i GitLab sprowadza się do czterech ruchów: generujesz parę kluczy, dodajesz prywatny do agenta, wklejasz publiczny na konto i sprawdzasz połączenie.

Do tego dochodzą dwie linijki git config z Twoim imieniem, nazwiskiem i adresem e-mail – żeby commity miały poprawnego autora.

Na koniec kopiujesz adres SSH projektu i robisz git clone. Od tej chwili praca z repozytoriami idzie szybciej, bez wpisywania haseł i bez tokenów wklejanych przy każdym push.