Tworzenie i używanie kluczy SSH

Moduł 2: SSH i klucze · Czas czytania: 10 min

Cel lekcji: Po tej lekcji potrafią Państwo utworzyć parę kluczy, umieścić klucz publiczny na serwerze, logować się bez hasła i przechowywać klucz prywatny tak, aby zgubiony laptop nie oznaczał katastrofy.

Kluczowe pojęcia: para kluczy, klucz publiczny, klucz prywatny, ed25519, RSA, passphrase (hasło klucza), ssh-agent, ssh-copy-id, authorized_keys, uprawnienia 700 i 600, osobny klucz na każde urządzenie, klucz FIDO2

Dlaczego klucze są lepsze od haseł

W lekcji 1.3 logowali się Państwo hasłem. To działa, ale serwer w internecie już od pierwszej minuty odwiedzają programy, które próbują odgadnąć hasła. Wystarczy zajrzeć do logu świeżo uruchomionego serwera:

root@web1:~# journalctl -u ssh --since "1 hour ago" | grep -c "Failed password"
214

Setki prób na godzinę to norma. Silne hasło je zatrzyma, ale tworzą Państwo w ten sposób słaby punkt, który nie jest potrzebny. Przy użyciu klucza SSH zgadywanie nie ma sensu: nie ma niczego, co dałoby się znaleźć w słowniku.

Klucz składa się z dwóch powiązanych ze sobą części, czyli pary kluczy:

• Klucz prywatny pozostaje na Państwa własnym komputerze. Kto ma ten plik (i zna passphrase), może się zalogować. Prosimy nie udostępniać go nikomu, także dostawcy ani pomocy technicznej.
• Klucz publiczny przekazują Państwo serwerowi. Może go zobaczyć każdy: nie da się nim zalogować, służy wyłącznie do weryfikacji.

Podczas logowania przez łącze nie jest przesyłane żadne hasło. Państwa komputer udowadnia podpisem, że posiada klucz prywatny, a serwer sprawdza ten podpis za pomocą klucza publicznego. Nawet jeśli ktoś podsłuchuje sieć, nie zobaczy niczego, co mógłby później ponownie wykorzystać.

Tworzenie klucza

Klucz tworzą Państwo na własnym komputerze, a nie na serwerze. W systemach Windows 10 i 11, macOS oraz Linux polecenie ssh-keygen jest już dostępne. Prosimy otworzyć PowerShell lub Terminal:

anna@laptop:~$ ssh-keygen -t ed25519 -C "anna@laptop 2026"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/anna/.ssh/id_ed25519):
Enter passphrase for "/home/anna/.ssh/id_ed25519" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/anna/.ssh/id_ed25519
Your public key has been saved in /home/anna/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:q3J8vX0bT2kPz9mWc1nR4sLh7uYdE5aF6gBiC0oN2xQ anna@laptop 2026

Co się tutaj dzieje?

• -t ed25519 wybiera typ klucza. Ed25519 jest krótki, szybki i bezpieczny, a od wersji OpenSSH 9.5 jest też typem domyślnym, jeśli nic nie zostanie podane. Jeśli muszą Państwo obsługiwać stary system, który nie zna ed25519, prosimy użyć RSA o długości co najmniej 3072 bitów: ssh-keygen -t rsa -b 4096. Starsze typy, takie jak DSA, zostały usunięte z OpenSSH; prosimy ich nie używać.
• -C to jedynie komentarz. Warto wpisać tam coś, po czym później rozpoznają Państwo, z którego urządzenia pochodzi klucz. To bardzo pomaga, gdy trzeba unieważnić klucz.
• Passphrase szyfruje klucz prywatny na dysku. Jeśli laptop zostanie skradziony, złodziej będzie miał jedynie zaszyfrowany plik. Bez passphrase od razu uzyska dostęp do wszystkich Państwa serwerów.

Mają Państwo teraz dwa pliki:

W systemie Windows znajdują się one w C:\Users\anna\.ssh\. Klucz publiczny to jeden wiersz zaczynający się od ssh-ed25519:

anna@laptop:~$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHk2... anna@laptop 2026

Umieszczanie klucza publicznego na serwerze

Serwer szuka kluczy publicznych w pliku ~/.ssh/authorized_keys użytkownika, jako który się Państwo logują. Każdy wiersz to jeden klucz. Klucz można tam umieścić na trzy sposoby:

1. Podczas instalacji. Większość dostawców przy tworzeniu lub ponownej instalacji VPS udostępnia pole na klucz publiczny. W WebOké pole to nazywa się „Klucz SSH” i znajduje się na ekranie VPS; u innych dostawców działa to podobnie. To najlepszy sposób: logowanie hasłem nigdy nie musi być włączone.

2. Za pomocą ssh-copy-id (macOS i Linux), dopóki logowanie hasłem jeszcze działa:

anna@laptop:~$ ssh-copy-id anna@192.0.2.10
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed
anna@192.0.2.10's password:
Number of key(s) added: 1

3. Ręcznie, na przykład z systemu Windows lub przez konsolę dostawcy. Prosimy wkleić wiersz z pliku .pub do authorized_keys i ustawić właściwe uprawnienia:

anna@web1:~$ mkdir -p ~/.ssh
anna@web1:~$ nano ~/.ssh/authorized_keys
anna@web1:~$ chmod 700 ~/.ssh
anna@web1:~$ chmod 600 ~/.ssh/authorized_keys

Te uprawnienia nie są drobiazgiem. Serwer SSH je sprawdza (ustawienie StrictModes jest domyślnie włączone): jeśli inni mogą zapisywać w Państwa katalogu .ssh lub w katalogu domowym, serwer zignoruje Państwa klucze. Wtedy po prostu znów pojawi się pytanie o hasło, bez wyraźnego komunikatu o błędzie. Jak odczytywać uprawnienia, dowiedzą się Państwo w lekcji 3.1.

Następnie prosimy przetestować logowanie w nowym oknie:

anna@laptop:~$ ssh anna@192.0.2.10
Enter passphrase for key '/home/anna/.ssh/id_ed25519':
anna@web1:~$

Pytanie pochodzi teraz z Państwa własnego komputera (passphrase klucza), a nie z serwera.

ssh-agent: jednorazowe odblokowanie

Wpisywanie passphrase za każdym razem jest uciążliwe. ssh-agent przechowuje odblokowany klucz w pamięci, dopóki są Państwo zalogowani na swoim komputerze:

anna@laptop:~$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/anna/.ssh/id_ed25519:
Identity added: /home/anna/.ssh/id_ed25519 (anna@laptop 2026)
anna@laptop:~$ ssh-add -l
256 SHA256:q3J8vX0bT2kPz9mWc1nR4sLh7uYdE5aF6gBiC0oN2xQ anna@laptop 2026 (ED25519)

W macOS agent współpracuje z pękiem kluczy, a w Windows jest to usługa „OpenSSH Authentication Agent” (jednorazowo należy ją włączyć w oknie Usługi). Dzięki temu mają Państwo wygodę logowania bez hasła, a mimo to zaszyfrowany klucz na dysku.

Prosimy uważać na agent forwarding (ssh -A): pozwala on serwerowi, na który się Państwo logują, korzystać z Państwa agenta. Kto ma uprawnienia root na tym serwerze, może wtedy działać dalej z użyciem Państwa klucza. Prosimy używać tej funkcji tylko na serwerach, którym w pełni Państwo ufają, lub skorzystać z ProxyJump (lekcja 2.3).

Jeden klucz na urządzenie i wiedza, gdzie które się znajdują

Częsty błąd: kopiowanie jednego klucza prywatnego na laptop, komputer stacjonarny i telefon. Po utracie jednego urządzenia trzeba wtedy wszędzie wymienić klucz i ponownie skonfigurować wszystkie urządzenia. Lepiej jest:

• na każdym urządzeniu utworzyć osobny klucz z czytelnym komentarzem (-C "anna@telefoon");
• umieścić wszystkie klucze publiczne w authorized_keys, po jednym w wierszu;
• po utracie urządzenia usunąć tylko ten jeden wiersz.

Prosimy regularnie sprawdzać, które klucze mają dostęp:

anna@web1:~$ ssh-keygen -lf ~/.ssh/authorized_keys
256 SHA256:q3J8vX0bT2kPz9mWc1nR4sLh7uYdE5aF6gBiC0oN2xQ anna@laptop 2026 (ED25519)
256 SHA256:Zt5oP1yW8eQ3rK6sV0bN9mD2xA4cH7jL1uI5fG8tE3w anna@telefoon (ED25519)

Jeśli znajdą Państwo klucz, którego nie rozpoznają, jest to sygnał alarmowy (lekcja 10.3). Włamywacze chętnie dodają własny klucz do authorized_keys, aby móc później wrócić.

Można też użyć klucza sprzętowego (FIDO2, np. YubiKey). Dzięki ssh-keygen -t ed25519-sk tajna część znajduje się na samym kluczu i trzeba go dotknąć przy każdym użyciu. Skradziony plik jest wtedy bezwartościowy. To dobry kolejny krok, ale na początek nie jest konieczny.

Zgubili Państwo klucz prywatny?

Jeśli zgubią Państwo jedyny klucz prywatny, a logowanie hasłem jest wyłączone, nie wejdą Państwo już na serwer przez SSH. Dlatego:

• prosimy zawsze umieszczać na serwerze co najmniej dwa klucze (na przykład z laptopa i komputera stacjonarnego);
• warto wiedzieć, jak działa konsola dostawcy (lekcja 1.2). Logują się tam Państwo tak, jakby do serwera była podłączona klawiatura, i działa to również bez SSH. W WebOké nazywa się to Konsola i znajduje się na ekranie VPS; inni dostawcy nazywają to konsolą VNC, konsolą WWW lub konsolą awaryjną.

W systemach AlmaLinux i Rocky Linux

Wszystko z tej lekcji działa tak samo. Jedna dodatkowa pułapka: przy włączonym SELinux katalog ~/.ssh musi mieć właściwą etykietę bezpieczeństwa. Jeśli utworzyli Państwo lub skopiowali katalog ręcznie, a klucz jest ignorowany, naprawi to restorecon -Rv ~/.ssh.

Podsumowanie

• Para kluczy składa się z klucza prywatnego (zostaje u Państwa) i klucza publicznego (trafia na serwer, do ~/.ssh/authorized_keys).
• Klucze tworzy się poleceniem ssh-keygen -t ed25519 na własnym komputerze, z passphrase; dla wygody warto używać ssh-agent.
• Uprawnienia mają znaczenie: ~/.ssh na 700, a authorized_keys na 600, w przeciwnym razie serwer zignoruje klucz.
• Jeden klucz na urządzenie, z czytelnym komentarzem, aby można było unieważnić pojedynczy klucz.
• Prosimy mieć drugi klucz i znać konsolę dostawcy jako wejście awaryjne.

Quiz

Zadanie

Zadanie O2.1: Tworzenie i używanie klucza. Prosimy utworzyć na własnym komputerze klucz ed25519 z passphrase i czytelnym komentarzem, umieścić go na serwerze (przez pole u dostawcy, za pomocą ssh-copy-id lub ręcznie), sprawdzić uprawnienia i zalogować się kluczem w nowym oknie. Następnie prosimy wpisać odcisk klucza (z ssh-keygen -lf ~/.ssh/id_ed25519.pub) i odpowiedzieć na pytania o to, gdzie znajduje się Państwa klucz prywatny i co zrobią Państwo w razie jego utraty. Program sprawdza jedynie, czy odcisk ma właściwy format; resztę wykonują Państwo samodzielnie.

Przeczytaj więcej

Kroki opisane w tych artykułach dotyczą ekranu VPS i paneli WebOké; u innych dostawców działa to podobnie.

• Logowanie do VPS przez SSH (i tworzenie klucza SSH)
• Instrukcja DirectAdmin 15.2: Klucze SSH i logowanie przez SSH
• Brak dostępu do VPS: co teraz?
• Dokumentacja ssh-keygen: https://man.openbsd.org/ssh-keygen
• Informacje o wydaniu OpenSSH 9.5 (ed25519 jako domyślny): https://www.openssh.org/txt/release-9.5