Zmiana polityki autoryzacji GitHub w sierpniu 2021 roku była podyktowana względami bezpieczeństwa. Hasła są podatne na phishing, wycieki i ponowne użycie. Tokeny i klucze SSH są kryptograficznie bezpieczniejsze, można im nadawać ograniczone uprawnienia oraz łatwo je unieważnić bez zmiany hasła do konta. Dla programisty oznacza to konieczność poznania nowych narzędzi, które jednak w dłuższej perspektywie znacząco usprawniają codzienną pracę. W środowisku akademickim szczególnie polecana jest metoda SSH, ponieważ raz skonfigurowana działa bezobsługowo przez cały okres studiów.
remote: Support for password authentication was removed on August 13, 2021.
Decyzja GitHub o wycofaniu uwierzytelniania hasłem nie była odosobniona – podobne kroki podjęły inne platformy, takie jak GitLab czy Bitbucket. Powód jest prosty: statystycznie ponad 80% naruszeń bezpieczeństwa wiąże się ze słabymi lub skradzionymi hasłami. Tokeny PAT mogą być wydawane z ograniczonym zakresem (np. tylko do odczytu repozytoriów), z określonym czasem ważności i mogą być natychmiast unieważnione w przypadku wycieku. SSH używa kryptografii klucza publicznego, co eliminuje konieczność przesyłania jakiegokolwiek sekretu przez sieć podczas uwierzytelniania.
| Metoda | Zalety | Wady |
|---|---|---|
| 1. GitHub CLI (gh) | Najprostsza konfiguracja, kreator, automatyczne uwierzytelnienie Git | Wymaga dodatkowego narzędzia, zależność od zewn. pakietu |
| 2. Klucze SSH | Bezhasłowe, najwygodniejsze na co dzień, działa bez dodatkowych narzędzi | Początkowo wymaga więcej kroków, trzeba chronić klucz prywatny |
| 3. Personal Access Token (PAT) | Działa przez HTTPS, klasyczny workflow, łatwy do skryptowania | Token trzeba odświeżać, ryzyko zapisania go w repozytorium |
Wybór metody zależy od scenariusza użycia. Na komputerach współdzielonych (laboratoria uczelniane) lepiej sprawdzi się GitHub CLI lub token PAT, ponieważ nie pozostawiamy trwałego klucza prywatnego. Na własnym laptopie SSH jest najwygodniejsze – po dodaniu klucza publicznego do GitHub nie musimy już wpisywać żadnych danych uwierzytelniających. W skryptach CI/CD (Continuous Integration/Continuous Deployment) standardem są tokeny PAT lub dedykowane tokeny deploy keys. Warto znać wszystkie trzy metody, aby móc dostosować się do wymagań każdego środowiska pracy.
gh) to oficjalne narzędzie wiersza poleceń wydane przez GitHub.gh automatycznie konfiguruje Git do używania Twoich poświadczeń.GitHub CLI powstał w 2019 roku i szybko stał się standardowym narzędziem dla programistów, którzy cenią pracę w terminalu. Oprócz uwierzytelniania, gh oferuje pełną integrację z API GitHub – można przeglądać issue, zatwierdzać pull requesty, zarządzać release'ami i wiele więcej bez opuszczania konsoli. W kontekście logowania kluczową zaletą jest to, że gh przechowuje token odświeżalny (refresh token) i automatycznie odnawia sesję, co eliminuje problem wygasających tokenów PAT. Narzędzie jest aktywnie rozwijane i dokumentowane na stronie cli.github.com.
sudo apt install ghsudo apt install gh. Możesz też pobrać .deb z github.com/cli/cli/releases.
gh auth login zaloguj się do swojego GitHub na innej maszynie w przeglądarce na adres: https://github.com/login/device. Wybierz swój profil i kliknij w 'Continue'. Następnie w oknie jakie się pojawi wpisz kod (ten pokazany na konsoli), przejdź dalsze kroki jakie pokaże Ci panel GitHub i po chwili na konsoli zobaczysz 'Authentication complete' czyli Twoja maszyna Linux widzi GitHub. Poniżej opisano wszystko w szczegółach.
W zależności od wersji Debiana (Debian 11 "Bullseye", Debian 12 "Bookworm") pakiet gh może być dostępny w różnych wersjach. Debian 12 Bookworm zawiera gh w wersji ~2.32, która jest w pełni funkcjonalna. Jeśli zależy Ci na najnowszej wersji, dodaj oficjalne repozytorium GitHub: type -p curl >/dev/null || sudo apt install curl -y && curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg && sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg && echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null && sudo apt update && sudo apt install gh -y
WD31-A12BPrzebieg kreatora gh auth login jest taki sam niezależnie od systemu operacyjnego. Po wybraniu opcji "Login with a web browser" narzędzie wyświetli kod urządzenia (device code) i otworzy domyślną przeglądarkę. Jeśli pracujesz na serwerze bez interfejsu graficznego, przeglądarka się nie otworzy – wtedy musisz ręcznie wejść na adres https://github.com/login/device i wpisać wyświetlony kod. Po potwierdzeniu w przeglądarce terminal automatycznie zakończy proces logowania i poinformuje o sukcesie. Wszystkie dane uwierzytelniające są przechowywane w systemowym keychainie (jeśli jest dostępny) lub w pliku konfiguracyjnym ~/.config/gh/hosts.yml.
gh auth login w przeglądarce pojawi się strona GitHub z polem na kod.https://github.com/login/deviceMechanizm uwierzytelniania urządzenia (OAuth Device Authorization Grant) jest standardem protokołu OAuth 2.0 i jest używany przez wiele serwisów. Jest to szczególnie przydatne na serwerach bez przeglądarki – kod urządzenia jest krótki (8 znaków) i ważny przez ograniczony czas (standardowo 15 minut). GitHub CLI po pomyślnym uwierzytelnieniu zapisuje token odświeżalny (refresh token) w pliku konfiguracyjnym, co pozwala na automatyczne odświeżanie sesji bez ponownego logowania. Aby sprawdzić status logowania w dowolnym momencie, użyj komendy gh auth status.
credential.helper na swój własny helper. Git będzie używał tokena zarządzanego przez gh. Nie musisz wpisywać loginu ani hasła.
GitHub CLI integruje się z systemowym credential helperem Gita. Po zalogowaniu przez gh auth login w pliku ~/.gitconfig pojawia się wpis: [credential] helper = C:/Program Files/Git/mingw64/bin/git-credential-manager.exe (Windows) lub odpowiednio dla systemów Unix. Dzięki temu wszystkie operacje Git przez HTTPS będą automatycznie używać tokena wygenerowanego przez gh, bez potrzeby ręcznego wpisywania jakichkolwiek danych. Możesz również używać gh pr create, gh issue list i wielu innych komend do zarządzania projektem bez opuszczania terminala.
Protokół SSH został opracowany w 1995 roku jako następca Telnetu i od tego czasu stał się standardem bezpiecznego zdalnego dostępu do systemów Unix. W kontekście Gita SSH jest używany jako transparentna warstwa transportowa – Git po prostu uruchamia klienta SSH, który nawiązuje zaszyfrowane połączenie z serwerem GitHub. Klucze kryptograficzne używane w SSH są praktycznie niemożliwe do złamania przy obecnej mocy obliczeniowej (klucz Ed25519 oferuje około 128 bitów bezpieczeństwa, co odpowiada kluczowi RSA 3072). Zaleca się używanie algorytmu Ed25519 zamiast starszego RSA, ponieważ jest szybszy i bezpieczniejszy.
Polecenie ssh-keygen -t ed25519 -C "twoj_email@example.com" generuje parę kluczy z użyciem algorytmu krzywej eliptycznej Ed25519, który jest obecnie rekomendowany przez wszystkich głównych dostawców (GitHub, GitLab, AWS). Flaga -C dodaje komentarz do klucza (zazwyczaj adres e-mail), co ułatwia identyfikację klucza na liście w ustawieniach GitHub. Jeśli Twój system nie wspiera Ed25519 (bardzo stare dystrybucje), możesz użyć RSA: ssh-keygen -t rsa -b 4096 -C "twoj_email@example.com". Pliki kluczy są domyślnie zapisywane w katalogu ~/.ssh/ z uprawnieniami 600 dla klucza prywatnego i 644 dla publicznego.
echo $SSH_AUTH_SOCKAgent SSH to demon działający w tle, który przechowuje odszyfrowane klucze prywatne w pamięci operacyjnej. Gdy Git próbuje nawiązać połączenie SSH z GitHub, agent automatycznie podpisuje żądanie odpowiednim kluczem bez interakcji z użytkownikiem. Na systemach z sesją graficzną (GNOME, KDE, XFCE) agent SSH jest uruchamiany automatycznie przez menedżera logowania. W czystej konsoli (np. po ssh na serwer) trzeba go uruchomić ręcznie. Komenda ssh-add -l wyświetla listę kluczy aktualnie załadowanych do agenta. Aby trwale dodać klucz do agenta przy każdym logowaniu, dodaj ssh-add ~/.ssh/id_ed25519 do pliku ~/.bash_profile lub ~/.profile.
ssh-ed25519 do końca (łącznie z e-mailem) i skopiuj.Klucz publiczny SSH to plik tekstowy, który można bezpiecznie udostępniać. Jego zawartość składa się z trzech elementów: typu klucza (ssh-ed25519), zakodowanego base64 klucza publicznego oraz komentarza (adres e-mail). GitHub używa tego klucza do weryfikacji Twojej tożsamości – gdy łączysz się przez SSH, GitHub szyfruje wiadomość Twoim kluczem publicznym, a Twój klient SSH musi ją odszyfrować kluczem prywatnym. Jeśli odszyfrowanie się powiedzie, GitHub wie, że masz dostęp do klucza prywatnego i autoryzuje połączenie. Nigdy nie dodawaj klucza prywatnego do GitHub ani nie przesyłaj go przez niezaszyfrowane kanały.
Po dodaniu klucza SSH do GitHub warto od razu go przetestować. GitHub pozwala na dodanie wielu kluczy – każde urządzenie powinno mieć własny, osobny klucz. Jeśli zmieniasz komputer lub formatujesz dysk, wygeneruj nowy klucz i dodaj go, a stary usuń z poziomu GitHub Settings. Dzięki temu w przypadku kradzieży lub zgubienia komputera możesz natychmiast unieważnić dostęp, usuwając odpowiedni klucz z GitHub. W ustawieniach SSH Keys zobaczysz listę wszystkich dodanych kluczy z datą dodania i informacją, kiedy były ostatnio używane.
Komenda ssh -T git@github.com próbuje nawiązać połączenie SSH z GitHub przy użyciu uwierzytelniania kluczem publicznym. Flaga -T wyłącza przydzielanie pseudoterminala (TTY), ponieważ nie będziemy wykonywać komend na serwerze – chcemy tylko sprawdzić autoryzację. Przy pierwszym połączeniu z GitHub z danego komputera SSH poprosi o potwierdzenie odcisku klucza hosta (host key fingerprint). Jest to mechanizm bezpieczeństwa chroniący przed atakami man-in-the-middle. Odciski palców GitHub są publicznie dostępne w dokumentacji: SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU (dla klucza ED25519 hosta). Po potwierdzeniu host jest zapisywany w pliku ~/.ssh/known_hosts.
git@github.com:), a nie HTTPS.Adres SSH do repozytorium ma format git@github.com:użytkownik/nazwa_repo.git. Jeśli sklonowałeś repozytorium przez HTTPS, a chcesz przejść na SSH, możesz zmienić remote: git remote set-url origin git@github.com:twoj_login/nazwa_repo.git. Komenda git remote -v pokaże aktualne adresy remote'ów. Po przejściu na SSH push i pull działają bez pytania o login i hasło – GitHub weryfikuje Cię na podstawie klucza SSH. W przypadku problemów z autoryzacją SSH warto sprawdzić: czy agent SSH działa (ssh-add -l), czy klucz jest załadowany oraz czy plik ~/.ssh/config nie blokuje połączenia.
Personal Access Token to podstawowa metoda autoryzacji API GitHub, ale może być również używana jako alternatywa dla hasła w operacjach Git przez HTTPS. Tokeny PAT dzielą się na dwa typy: fine-grained tokens (dokładniejsze, nowsze, dostępne od 2022) oraz classic tokens (starsze, prostsze). Tokeny fine-grained pozwalają na precyzyjne określenie dostępu do konkretnych repozytoriów i zasobów, podczas gdy tokeny classic działają na poziomie konta. W obu przypadkach token jest 40-znakowym ciągiem zaczynającym się od ghp_ (dla classic) lub github_pat_ (dla fine-grained). Token nigdy nie jest przechowywany na serwerze GitHub po wygenerowaniu – jeśli go zgubisz, musisz utworzyć nowy.
Podczas generowania tokena PAT masz do wyboru wiele zakresów uprawnień (scopes): repo – pełny dostęp do repozytoriów (prywatnych i publicznych), workflow – dostęp do GitHub Actions, admin:repo_hook – zarządzanie webhookami, delete_repo – usuwanie repozytoriów, i wiele innych. Dla podstawowych operacji Git (clone, push, pull) wystarczy zakres repo. Jeśli zamierzasz używać tokena również do zarządzania GitHub Actions, dodaj workflow. Zasada najmniejszych uprawnień (principle of least privilege) mówi, aby nadawać tokenowi tylko te uprawnienia, które są niezbędne. Nie używaj tokena z pełnymi uprawnieniami do prostego klonowania publicznego repozytorium.
ghp_ (classic) lub github_pat_ (fine-grained).repo ma dostęp do wszystkich Twoich repozytoriów.
Podczas wklejania tokena w terminalu systemy Unix/Linux domyślnie nie wyświetlają żadnych znaków (echo jest wyłączone dla pól hasła). Jest to celowe zachowanie bezpieczeństwa – nikt patrzący na ekran nie zobaczy długości ani fragmentu tokena. Po pomyślnym uwierzytelnieniu Git zapamiętuje token w pamięci (jeśli używasz credential helpera) lub prosi o niego przy każdej operacji. Token PAT jest przetwarzany jak zwykłe hasło, ale ma tę przewagę, że możesz go unieważnić w każdej chwili bez zmiany hasła do konta GitHub. Warto przechowywać token w menedżerze haseł (np. Bitwarden, KeePass) – nigdy nie zapisuj go w plikach tekstowych w repozytorium.
libsecret – wymaga instalacji pakietów (sudo apt install libsecret-1-0 libsecret-1-dev), a następnie skompilowania pomocnika z katalogu /usr/share/doc/git/contrib/credential/libsecret/ (sudo make) i skonfigurowania go jako credential.helper. Dzięki temu token będzie przechowywany w systemowym magazynie haseł (GNOME Keyring/KDE Wallet).
git push → wpisz token → cache 3600sgit push (za 5 min) → cache działa → brak pytaniagit push (za 2 godz.) → cache wygasł → wpisz token ponownie
Credential helper to mechanizm Gita umożliwiający przechowywanie i automatyczne dostarczanie poświadczeń (login + hasło/token) bez konieczności ręcznego wpisywania ich przy każdej operacji sieciowej. Git obsługuje kilka rodzajów credential helperów: cache – przechowuje poświadczenia w pamięci RAM (bezpieczne, ale ulotne), store – zapisuje poświadczenia w pliku tekstowym na dysku (wygodne, ale mniej bezpieczne), oraz zewnętrzne helpery systemowe, takie jak libsecret (GNOME Keyring), wincred (Windows Credential Manager) czy osxkeychain (macOS Keychain). W Debianie z sesją graficzną GNOME zalecany jest libsecret, który przechowuje token w zaszyfrowanym magazynie haseł.
Po wykonaniu git push -u origin main z tokenem i skonfigurowanym credential helperem, Git zapisuje token w pamięci RAM. Flaga -u (lub --set-upstream) ustawia gałąź główną (upstream) dla bieżącej gałęzi, co pozwala od tego momentu wykonywać po prostu git push bez podawania nazwy remote'a i gałęzi. Pamiętaj, że cache credential helper jest ulotny – po wylogowaniu z sesji lub restarcie komputera token jest tracony i trzeba go wpisać ponownie. Jeśli chcesz trwale zapamiętać token, możesz użyć git config --global credential.helper store, ale jest to mniej bezpieczne, ponieważ token jest zapisywany w czystym tekście w pliku ~/.git-credentials.
| Kryterium | GitHub CLI (gh) | SSH | PAT (HTTPS) |
|---|---|---|---|
| Łatwość konfiguracji | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| Bezpieczeństwo | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Wymagane narzędzia | gh (dodatkowy pkg) | wbudowane w Git | wbudowane w Git |
| Automatyzacja (CI/CD) | ❌ (interaktywny) | ✅ (deploy keys) | ✅ (secrets) |
| Działa bez internetu (przygotowanie) | ❌ | ✅ | ❌ |
| Trwałość poświadczeń | odświeżalny token | bezterminowo | wymaga odświeżania |
| Dodatkowe funkcje | issue, PR, Actions | tylko Git | tylko Git |
Wybór odpowiedniej metody autoryzacji zależy od konkretnego scenariusza użycia. W laboratorium uczelnianym, gdzie studenci logują się na współdzielonych komputerach, najlepszym wyborem jest GitHub CLI – wystarczy gh auth login na początku zajęć, a token jest ważny przez całą sesję. W przypadku pracy na własnym laptopie SSH jest wygodniejsze, ponieważ klucze nie wygasają i nie wymagają ponownej konfiguracji przez lata. W środowiskach CI/CD (GitHub Actions, Jenkins) standardem są tokeny PAT przechowywane jako secrets w repozytorium. Niezależnie od metody, wszystkie trzy są bezpieczne i oficjalnie wspierane przez GitHub. Warto znać każdą z nich, aby móc elastycznie dostosować się do wymagań projektu.
sudo apt install gh → gh auth login – najprostsza metoda.ssh-keygen -t ed25519 → dodaj klucz do GitHub → git clone git@github.com:...credential.helper, aby nie wpisywać tokena przy każdej operacji.Znajomość metod autoryzacji do GitHub z poziomu konsoli jest kluczowa dla każdego studenta informatyki i programisty. W trakcie tego wykładu poznałeś trzy niezależne metody, z których każda ma swoje zalety i zastosowania. Ćwicz je wszystkie na swoim koncie GitHub – utwórz testowe repozytorium i wypróbuj każdą metodę od początku do końca. Pamiętaj, że w przypadku problemów GitHub oferuje doskonałą dokumentację, a społeczność programistów na Stack Overflow i forach dyskusyjnych zawsze chętnie pomaga. Powodzenia w dalszej pracy z Gitem i GitHub!