Konfiguracja kluczy SSH bez utraty dostępu

Wygeneruj i zidentyfikuj klucz lokalnie

W aktualnym kliencie OpenSSH utwórz osobny klucz poleceniem ssh-keygen -t ed25519 -a 100 -f ~/.ssh/vpseverywhere_admin. Po wyświetleniu monitu wpisz silne hasło. Polecenie tworzy prywatny plik vpseverywhere_admin oraz publiczny plik vpseverywhere_admin.pub. Jeśli Ed25519 jest niedostępny z powodu konkretnego wymogu zgodności lub polityki, wybierz konfigurację RSA zatwierdzoną dla danego środowiska, zamiast kopiować stary klucz.

Wyświetl odcisk klucza publicznego poleceniem ssh-keygen -lf ~/.ssh/vpseverywhere_admin.pub i zapisz go w zaufanym miejscu. Nie wyświetlaj ani nie przesyłaj pliku prywatnego. Nie wklejaj go też w polu panelu oznaczonym jako klucz SSH — takie pole powinno przyjmować jednowierszowy klucz publiczny zaczynający się od ssh-ed25519.

• Do administracji używaj osobnego klucza, a nie jednego klucza współdzielonego przez zespół.
• Chroń urządzenie lokalne szyfrowaniem dysku i regularnymi aktualizacjami.
• Kopię klucza prywatnego przechowuj wyłącznie w zaszyfrowanym magazynie z kontrolą dostępu.

Zainstaluj klucz publiczny

Jeśli dostęp hasłem jest tymczasowo włączony, zainstaluj klucz publiczny poleceniem ssh-copy-id -i ~/.ssh/vpseverywhere_admin.pub USER@SERVER_IP, zastępując oba symbole zastępcze. Możesz też dodać dokładny wiersz klucza publicznego za pomocą funkcji wdrażania u dostawcy. Przy ręcznej edycji na VPS katalog ~/.ssh użytkownika docelowego powinien należeć do tego użytkownika i zwykle mieć tryb 700, a plik authorized_keys — tryb 600.

Połącz się jawnie poleceniem ssh -i ~/.ssh/vpseverywhere_admin USER@SERVER_IP. Przy pierwszym połączeniu przed zaakceptowaniem klucza hosta sprawdź jego odcisk w niezależnym, zaufanym źródle. Zmiana klucza hosta może być uzasadniona po reinstalacji, ale może też oznaczać przechwycenie połączenia lub przypisanie adresu innemu serwerowi.

• Nie rozwiązuj ostrzeżenia o kluczu hosta przez bezrefleksyjne usunięcie starego wpisu.
• W miarę możliwości używaj imiennego administratora bez bezpośredniego logowania roota.
• Umieść klucz każdej osoby w osobnym wierszu, aby można go było łatwo unieważnić.

Ułatw niezawodne codzienne korzystanie

W lokalnym pliku ~/.ssh/config utwórz alias klienta SSH z nazwą Host, adresem HostName, kontem User i wpisem IdentityFile ~/.ssh/vpseverywhere_admin. Jeśli wymaga tego system operacyjny, ustaw plik konfiguracyjny tak, aby mógł go odczytać tylko Twój użytkownik. Agent SSH ogranicza konieczność wielokrotnego wpisywania hasła do klucza, ale odblokowuj klucze wyłącznie na zaufanych urządzeniach i nie przekazuj agenta do niezaufanych hostów.

W zespole wdrażaj indywidualne klucze publiczne za pomocą narzędzi do zarządzania konfiguracją i szybko usuwaj je po zakończeniu dostępu. Nie rozsyłaj jednego klucza prywatnego przez komunikator ani system zgłoszeń. Klucze zabezpieczone sprzętowo mogą dodatkowo chronić administrację systemami o dużej wartości, jeśli klient i serwer obsługują wybrany typ.

• Nazywaj klucze według roli i środowiska, nie umieszczając sekretów w nazwie.
• Przeglądaj autoryzowane klucze po zmianach kadrowych lub zmianach w automatyzacji.
• Na współdzielonych stacjach roboczych ustawiaj krótki, kontrolowany czas działania agenta.

Wyłącz słabsze metody dopiero po testach

Pozostaw bieżącą sesję otwartą, uruchom drugi terminal i upewnij się, że nowy klucz pozwala się zalogować oraz wykonać zamierzone polecenie administracyjne. Następnie sprawdź każdą zmianę konfiguracji serwera SSH poleceniem sudo sshd -t, zanim wykonasz sudo systemctl reload ssh. Uwierzytelnianie hasłem i bezpośrednie logowanie roota można wyłączyć dopiero wtedy, gdy nie zależy od nich żaden potrzebny użytkownik ani proces automatyczny.

Zachowaj metodę odzyskiwania przez konsolę dostawcy i udokumentuj sposób przywrócenia dostępu. Utracony klucz trzeba pilnie unieważnić; utrata jedynego działającego klucza bez dostępu do konsoli oznacza awarię.