Co przygotować
Potrzebujesz działającego dostępu do serwera i konta, na które wolno się logować. Zostaw bieżącą sesję otwartą do końca testów. Klucz prywatny zostaje na Twoim urządzeniu; na serwer trafia wyłącznie plik z rozszerzeniem .pub. Hasło klucza chroni jego lokalną kopię i nie jest hasłem konta na serwerze.
Utwórz i prześlij klucz
W terminalu klienta wykonaj poniższe polecenia. Adres host.example i nazwę użytkownika zastąp własnymi danymi. Jeśli wskazany plik już istnieje, wybierz inną nazwę zamiast go nadpisywać.
ssh-keygen -t ed25519 -f ~/.ssh/mermiko_ed25519 -C "moj-laptop"
ssh-copy-id -i ~/.ssh/mermiko_ed25519.pub [email protected]Jeżeli nie masz ssh-copy-id, administrator może dopisać publiczny klucz jako osobny wiersz do ~/.ssh/authorized_keys. Katalog i plik powinny należeć do właściwego użytkownika; typowe uprawnienia to 700 dla .ssh i 600 dla pliku z kluczami.
Przetestuj w drugim terminalu
ssh -i ~/.ssh/mermiko_ed25519 -o IdentitiesOnly=yes [email protected]Przy pierwszym połączeniu porównaj odcisk klucza hosta z informacją uzyskaną z zaufanego kanału, np. konsoli serwera. Nie akceptuj zmienionego odcisku tylko po to, żeby pozbyć się ostrzeżenia. Zmiana może wynikać z reinstalacji, ale wymaga wyjaśnienia.
Dopiero później zmieniaj politykę logowania
Wyłączenie logowania hasłem jest oddzielnym etapem. Najpierw potwierdź działanie klucza w nowej sesji i dostęp do konsoli awaryjnej. Przed przeładowaniem demona sprawdź konfigurację przez sshd -t; nazwa usługi zależy od dystrybucji. Po zmianie ponownie otwórz nowe połączenie, zanim zamkniesz stare.
- Klucz prywatny nie trafia do repozytorium ani do zgłoszenia pomocy.
- Dla kolejnego urządzenia utwórz osobny klucz — łatwiej unieważnić pojedynczy dostęp.
- Po utracie urządzenia usuń jego publiczny klucz z kont, na których był dopuszczony.
Źródła i dokumentacja
Odnośniki do źródeł pozwalają sprawdzić daty, dostępność oraz pełny kontekst informacji.