Klucze SSH: jak je wygenerować, wgrać na serwer i wyłączyć logowanie hasłem

zaktualizowano 7 listopada 2026

Klucze SSH to para plików tworzonych poleceniem ssh-keygen: klucz prywatny zostaje na komputerze, a klucz publiczny, z końcówką .pub, trafia do pliku ~/.ssh/authorized_keys na serwerze. W większości przypadków wystarcza ssh-keygen -t ed25519. RSA o długości 4096 bitów ma sens tylko wtedy, gdy serwer jest zbyt stary na Ed25519. Cały proces to cztery kroki: wygenerowanie pary, wgranie części publicznej, próbne logowanie w osobnym oknie i dopiero na końcu wyłączenie haseł.

Według podręcznika ssh-keygen w dokumentacji OpenSSH polecenie uruchomione bez argumentów tworzy klucz Ed25519. Ten sam podręcznik zastrzega, że zapomnianego hasła do klucza nie da się odzyskać: trzeba wtedy wygenerować nowy klucz i skopiować jego część publiczną na pozostałe maszyny. Przykłady poniżej używają użytkownika admin i serwera vps.example.com.

Ed25519 czy RSA: który typ wybrać

Ed25519 jest obsługiwany przez OpenSSH od wersji 6.5 z 30 stycznia 2014, a od wersji 9.5 z 4 października 2023 właśnie ten typ ssh-keygen tworzy domyślnie. Najnowszym wydaniem na 4 listopada 2026 jest OpenSSH 10.6 z 6 października 2026. Dokumentacja serwerowa Ubuntu zaleca Ed25519 ze względu na krótszy klucz i mniejsze wymagania obliczeniowe, a RSA 4096 podaje jako alternatywę.

Podręcznik uznaje 3072 bity RSA za wystarczające, więc 4096 to wybór z zapasem, a nie konieczność. Wsparcie dla algorytmu DSA zostało usunięte w OpenSSH 10.0 z 9 kwietnia 2025, więc klucze DSA nie wchodzą już w grę.

Generowanie klucza krok po kroku

1. Uruchomić ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_vps -C "laptop-praca". Opcja -f ustawia nazwę pliku, a -C dopisuje komentarz, po którym później widać, do którego urządzenia należy klucz. Bez niej komentarzem jest nazwa użytkownika i komputera w postaci user@host.
2. Dwukrotnie wpisać hasło do klucza (passphrase). Chroni ono prywatną część pliku. Podręcznik opisuje dobre hasło jako liczące od 10 do 30 znaków, niebędące prostym zdaniem ani niczym łatwym do odgadnięcia. Puste hasło oznacza brak hasła. Zmienia się je później poleceniem ssh-keygen -p -f ~/.ssh/id_ed25519_vps.
3. Sprawdzić odcisk klucza: ssh-keygen -l -f ~/.ssh/id_ed25519_vps.pub.

Powstają dwa pliki: id_ed25519_vps (prywatny) i id_ed25519_vps.pub (publiczny). Plik prywatny nie może być dostępny dla innych użytkowników, bo ssh po prostu go zignoruje. Zawartość pliku .pub tajna nie jest. Własna nazwa pliku ma jeszcze jeden skutek: domyślnie ssh szuka tylko plików id_rsa, id_ecdsa, id_ed25519 i ich odmian, więc klucz o innej nazwie trzeba wskazać opcją -i albo wpisem IdentityFile w ~/.ssh/config.

Hasło do klucza i ssh-agent

Program ssh-agent przechowuje klucze prywatne i udostępnia je poleceniu ssh, dzięki czemu hasło wystarczy wpisać raz, przy dodawaniu klucza do agenta, a nie przy każdym połączeniu. W powłoce zgodnej z Bourne shell wygląda to tak:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_vps
ssh-add -l

Pierwsze polecenie uruchamia agenta i ustawia jego zmienne środowiskowe w bieżącej powłoce, drugie pyta o hasło i ładuje klucz, trzecie wypisuje odciski kluczy będących w agencie. Samo ssh-add bez argumentów dodaje wyłącznie domyślne pliki, czyli nie klucz o własnej nazwie. Opcja -t ogranicza czas życia klucza w agencie, a ssh-add -D usuwa wszystkie klucze. Wpis AddKeysToAgent yes w ~/.ssh/config sprawia, że ssh samo dodaje do działającego agenta każdy klucz wczytany z pliku. Domyślna wartość to no.

W Windows usługa ssh-agent jest domyślnie wyłączona. Według dokumentacji Microsoftu w PowerShellu z podwyższonymi uprawnieniami włącza ją polecenie Get-Service ssh-agent | Set-Service -StartupType Automatic, uruchamia Start-Service ssh-agent, a klucz ładuje ssh-add.

Wgranie klucza publicznego na serwer

ssh-copy-id -i ~/.ssh/id_ed25519_vps.pub admin@vps.example.com

Skrypt loguje się przez ssh, zwykle hasłem konta, więc logowanie hasłem musi być w tym momencie jeszcze włączone. Dopisuje klucz do ~/.ssh/authorized_keys użytkownika, a w razie potrzeby tworzy plik i katalog. Opcja -n wykonuje próbę bez zmian i wypisuje klucze, które zostałyby zainstalowane, a -p wskazuje port. Ręcznie wystarczy wkleić zawartość pliku .pub jako nową linię, bo każda linia pliku authorized_keys zawiera jeden klucz.

Na serwerze liczą się uprawnienia. Jeżeli plik authorized_keys, katalog ~/.ssh albo katalog domowy są zapisywalne dla innych użytkowników, sshd nie użyje klucza, dopóki opcja StrictModes (domyślnie yes) nie zostanie wyłączona. Podręcznik zaleca dla ~/.ssh odczyt, zapis i wykonanie tylko dla właściciela, a dla authorized_keys odczyt i zapis tylko dla właściciela:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Próbne logowanie warto wykonać w nowym oknie terminala: ssh -i ~/.ssh/id_ed25519_vps admin@vps.example.com. Gdy nie działa, ssh -v wypisuje komunikaty diagnostyczne dotyczące połączenia i uwierzytelniania.

Wyłączenie logowania hasłem po teście

W pliku /etc/ssh/sshd_config albo w osobnym pliku w katalogu /etc/ssh/sshd_config.d/ ustawia się:

PasswordAuthentication no
KbdInteractiveAuthentication no

Domyślnie PasswordAuthentication ma wartość yes. Drugi wpis jest potrzebny, bo przy UsePAM yes uwierzytelnianie keyboard-interactive z PAM, jak zauważa podręcznik, zwykle pełni tę samą rolę co hasło. Pakiet openssh-server w Debianie ustawia je standardowo na no, ale warto to sprawdzić. Potem:

sudo sshd -t
sudo sshd -T | grep -i -E "passwordauthentication|kbdinteractiveauthentication"
sudo systemctl restart ssh.service

Polecenie sshd -t sprawdza poprawność pliku konfiguracji, a sshd -T wypisuje konfigurację faktycznie obowiązującą. To drugie ma znaczenie, bo dla każdego słowa kluczowego liczy się pierwsza znaleziona wartość, a w Debianie pliki z /etc/ssh/sshd_config.d/*.conf są włączane na początku, więc nadpisują wpisy z pliku głównego. Nazwa usługi ssh.service pochodzi z dokumentacji Ubuntu, na innych systemach może być inna.

Utrata klucza lub hasła

Zapomniane hasło do klucza nie jest do odzyskania. Trzeba wygenerować nową parę i wgrać nowy klucz publiczny na serwery, tak samo jak po utracie samego pliku prywatnego. Dokumentacja Microsoftu mówi wprost o utworzeniu nowej pary i zaktualizowaniu klucza publicznego we wszystkich systemach.

Zgubiony laptop albo dysk wymaga usunięcia jego klucza z serwerów. Ponieważ każda linia w authorized_keys to jeden klucz, wystarczy skasować tę jedną linię, a komentarz nadany opcją -C podpowiada, która to. Hasło do klucza tylko utrudnia złamanie skradzionego pliku, więc nie zastępuje usunięcia klucza z serwera. Dlatego każde urządzenie powinno mieć własną parę: skasowanie jednej linii nie odcina wtedy pozostałych komputerów.

Najgorszy wariant to utrata jedynego klucza po wyłączeniu haseł. SSH nie ma wtedy czym uwierzytelnić użytkownika i potrzebny jest inny sposób dostępu do maszyny, na przykład konsola dostawcy albo dostęp fizyczny. Tego scenariusza unika się, dodając przed wyłączeniem haseł drugi klucz, przechowywany osobno.

Najczęstsze pytania

Więcej poradników

Kopia zapasowa rsync na serwerze Linux: SSH, cron i kopie przyrostowe

Kopia zapasowa rsync na serwerze Linux: opcje -a, -n i --delete, kopiowanie przez SSH, cron, kopie przyrostowe z --link-dest i test odtwarzania.