Logowanie do serwera przez SSH z kluczem Ed25519

KROK 01

Zanim zaczniesz

Wszystkie czynności wykonujesz z poziomu terminala na swoim komputerze, zwanym dalej klientem. W przykładach używamy nazwy serwer.example.com oraz nazwy użytkownika admin. Przed rozpoczęciem zastąp je własnymi danymi: rzeczywistym adresem serwera i nazwą swojego konta.

Potrzebujesz działającego połączenia SSH z serwerem. Zachowaj otwartą osobną sesję do czasu potwierdzenia, że nowy klucz działa. Przed zaakceptowaniem klucza hosta porównaj jego odcisk z informacją uzyskaną od administratora innym zaufanym kanałem. Odcisk służy sprawdzeniu tożsamości serwera, a nie tylko usunięciu ostrzeżenia przy pierwszym połączeniu.

W całym poradniku nie zmieniamy pliku konfiguracyjnego sshd, nie modyfikujemy portu ani nie wyłączamy logowania hasłem. Dodajemy wyłącznie nową metodę uwierzytelniania. Klucz prywatny nie opuszcza komputera klienta i nie powinien być nigdy przesyłany przez sieć ani pokazywany osobom postronnym.

KROK 02

Utwórz oddzielny klucz

Klucz zapisujemy w nowym pliku, aby nie nadpisać istniejących kluczy, na przykład domyślnego id_ed25519. Parametr -f wskazuje ścieżkę docelową, a -C dodaje komentarz, który pomoże zidentyfikować klucz w pliku authorized_keys na serwerze. Polecenie poprosi o podanie passphrase – warto je ustawić, ponieważ chroni plik klucza prywatnego przed użyciem w razie jego przejęcia.

Jeśli plik o podanej nazwie już istnieje, ssh-keygen zapyta, czy go nadpisać. W razie wątpliwości sprawdź najpierw zawartość katalogu ~/.ssh, aby przypadkiem nie utracić istniejących kluczy. Plik publiczny (z rozszerzeniem .pub) możesz swobodnie przesyłać – klucz prywatny pozostaje wyłącznie u Ciebie.

ssh-keygen -t ed25519 -f ~/.ssh/nc24_serwer -C "dostep-do-serwera"

Polecenie tworzy dwa pliki: ~/.ssh/nc24_serwer (klucz prywatny) i ~/.ssh/nc24_serwer.pub (klucz publiczny). Po podaniu i potwierdzeniu passphrase klucz jest gotowy do użycia.

KROK 03

Dodaj klucz publiczny

Na komputerze z systemem Linux możesz użyć ssh-copy-id. Narzędzie dopisuje wskazany klucz publiczny do pliku authorized_keys zdalnego konta. W macOS może nie być zainstalowane; w takiej sytuacji administrator może dopisać zawartość pliku .pub do ~/.ssh/authorized_keys tego użytkownika na serwerze. Ustal wcześniej nazwę konta, aby nie dodać dostępu do innego użytkownika.

Nie przesyłaj zawartości klucza prywatnego. Typowe uprawnienia na serwerze to 700 dla katalogu ~/.ssh i 600 dla authorized_keys; pliki powinny należeć do właściwego użytkownika. Istotne jest przede wszystkim, aby katalog i plik nie były zapisywalne przez inne osoby. Nietypowe położenie pliku lub dodatkowe reguły dostępu wymagają sprawdzenia konfiguracji serwera.

ssh-copy-id -i ~/.ssh/nc24_serwer.pub admin@serwer.example.com

Polecenie kopiuje wskazany klucz publiczny na serwer i dopisuje go do pliku authorized_keys konta admin. Przy pierwszym użyciu program poprosi o hasło do zdalnego konta, aby uwierzytelnić operację.

KROK 04

Sprawdź logowanie w drugiej sesji

W drugim oknie terminala wykonaj próbę logowania z nowym kluczem. Parametr -i wskazuje plik, a IdentitiesOnly=yes ogranicza dobór tożsamości do skonfigurowanych kluczy zamiast wszystkich kluczy agenta. PreferredAuthentications=publickey wyłącza w tej próbie przechodzenie do logowania hasłem konta. Jeśli klucz ma hasło ochronne, klient może nadal o nie zapytać. To hasło odszyfrowuje lokalny klucz; nie jest hasłem konta na serwerze.

Nie używaj w tym teście opcji BatchMode – przy braku passphrase w agencie SSH logowanie od razu zakończy się błędem, co może mylnie sugerować problem z konfiguracją, podczas gdy wystarczy dodać klucz do agenta poleceniem ssh-add.

ssh -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -i ~/.ssh/nc24_serwer admin@serwer.example.com

Jeśli konfiguracja jest poprawna, nastąpi logowanie bez pytania o hasło do serwera. Zostaniesz poproszony wyłącznie o passphrase chroniący lokalny klucz prywatny – o ile go ustawiłeś.

KROK 05

Gdy serwer odrzuca klucz

Komunikat Permission denied (publickey) oznacza, że serwer nie zaakceptował przedstawionego klucza. Sprawdź, czy używasz poprawnej nazwy konta na serwerze i czy klucz publiczny został skopiowany do właściwego pliku authorized_keys. Upewnij się, że plik .pub, który wysłałeś, pochodzi z tego samego zestawu co klucz prywatny – łatwo pomylić klucze, gdy ma się ich kilka.

Po stronie serwera plik authorized_keys musi należeć do logującego się użytkownika i nie może być zapisywalny przez innych. Dodanie opcji -v do polecenia ssh pokaże szczegółowy przebieg negocjacji – zwróć uwagę na linie informujące, które klucze są oferowane i czy zostały odrzucone. Nie publikuj pełnych logów z -v, ponieważ zawierają one nazwę hosta i konta.

ssh -v -o IdentitiesOnly=yes -i ~/.ssh/nc24_serwer admin@serwer.example.com

W szczegółowym zapisie połączenia sprawdź, jaki klucz klient próbuje przedstawić i czy serwer go przyjmuje. Nazwy komunikatów mogą różnić się między wersjami. Odrzucenie klucza może też wynikać z zasad dostępu, wyłączonego konta albo niedozwolonego algorytmu, więc sam komunikat nie wskazuje jeszcze jednej konkretnej przyczyny.

KROK 06

Wycofanie dostępu i dalsza administracja

Aby wycofać możliwość kolejnych logowań tym kluczem, administrator usuwa odpowiadający mu wpis z authorized_keys. Najpierw upewnia się, że zachowuje działającą metodę dostępu. Skasowanie pliku na jednym komputerze nie unieważnia jego kopii przechowywanych gdzie indziej. Usunięcie wpisu nie zamyka również już zestawionych sesji; ich zakończenie to odrębna decyzja administratora.

Warto stosować osobne klucze dla każdej osoby i każdego urządzenia – ułatwia to późniejsze selektywne blokowanie dostępu bez wpływu na innych użytkowników. W tym poradniku nie wyłączamy logowania hasłem, aby zachować awaryjną metodę logowania na wypadek problemów z kluczem.