SSH key

Para kluczy publiczny/prywatny używana do uwierzytelniania w SSH zamiast hasła. Klucz prywatny zostaje u użytkownika, publiczny trafia na serwer.

Klucz SSH to para kryptograficznych kluczy — publicznego i prywatnego — która pozwala zalogować się na zdalny serwer przez SSH bez wpisywania hasła. Działa to na zasadzie kryptografii asymetrycznej: klucz prywatny zostaje wyłącznie u Ciebie (na Twoim komputerze), a klucz publiczny kopiujesz na serwer. To, co zaszyfrujesz jednym, da się zweryfikować tylko drugim — i dlatego serwer może sprawdzić, że to naprawdę Ty, nie wysyłając Twojego sekretu przez sieć.

Jak to działa

Podczas logowania serwer wysyła Ci losowe wyzwanie. Twój klient SSH podpisuje je kluczem prywatnym, a serwer weryfikuje podpis przy użyciu zapisanego klucza publicznego. Jeśli się zgadza — wpuszcza Cię. Klucz prywatny nigdy nie opuszcza Twojej maszyny, więc nie ma czego podsłuchać ani wyłudzić. To podstawowy powód, dla którego klucze są bezpieczniejsze niż hasła: hasło można zgadnąć, podejrzeć albo złamać brute-force’em, klucza o długości 4096 bitów (RSA) czy nowoczesnego Ed25519 — w praktyce nie.

Klucz publiczny ląduje na serwerze w pliku ~/.ssh/authorized_keys. Możesz wrzucić tam wiele kluczy — z laptopa, ze stacjonarki, z serwera CI — i każdy z nich da dostęp na to samo konto.

Przykład z praktyki

Parę kluczy generujesz jednym poleceniem (dziś standardem jest Ed25519, nie stary RSA):

ssh-keygen -t ed25519 -C "[email protected]"

Powstają dwa pliki: id_ed25519 (prywatny, pilnuj go jak hasła do banku) i id_ed25519.pub (publiczny, ten możesz rozdawać). Klucz publiczny wgrywasz na serwer najprościej tak:

ssh-copy-id user@serwer

Od tej chwili ssh user@serwer wpuszcza Cię bez hasła. Dokładnie tego samego mechanizmu używasz, dodając klucz na GitHubie czy GitLabie, żeby robić git push przez SSH bez logowania za każdym razem.

Na co uważać

Najczęstszy błąd początkujących: wysłanie komuś klucza prywatnego zamiast publicznego. Regułka jest prosta — udostępniasz tylko plik z rozszerzeniem .pub, reszta zostaje u Ciebie. Drugi klasyk to zbyt luźne uprawnienia: SSH odmówi działania, jeśli katalog ~/.ssh i klucz prywatny są dostępne dla innych użytkowników (ustaw chmod 600 na kluczu). I jeszcze jedno: przy generowaniu warto ustawić passphrase — jeśli ktoś ukradnie Ci laptopa, sam plik klucza bez hasła jest dla niego bezużyteczny. Żeby nie wpisywać go bez przerwy, użyj ssh-agent.

Pojęcia powiązane

SSH, kryptografia asymetryczna (klucz publiczny/prywatny), Ed25519 i RSA, ssh-agent, plik known_hosts, passphrase, uwierzytelnianie dwuskładnikowe.