Twoja pierwsza sesja SSH, z drogą powrotu.

Zbierz dane dostępu i ścieżkę odzyskiwania

Potrzebujesz rzeczywistego adresu serwera, portu SSH, nazwy użytkownika do logowania, początkowej metody uwierzytelniania oraz zaufanego źródła odcisku klucza hosta serwera. Wybrana nazwa hosta w konfiguratorze nie ustanawia DNS ani nie tworzy konta. Uzyskaj te dane z rzeczywistej konfiguracji usługi, a nie z założeń o obrazie Linux.

Potwierdź, jak uzyskać dostęp do konsoli lub środowiska ratunkowego i kto może odzyskać dostęp. Sprawdź, czy możesz teraz otworzyć tę ścieżkę odzyskiwania; nie odkrywaj podczas blokady, że brakuje ci uprawnień lub danych do odzyskiwania. Jeśli żadna niezależna ścieżka odzyskiwania nie jest dostępna, nie zmieniaj ustawień dostępu, dopóki nie zostanie zapewniona.

Przykłady używają terminala klienta Bash na twoim komputerze oraz serwera Ubuntu/Debian. Zastąp swoje rzeczywiste dane dla builder, port 22 oraz 192.0.2.10, który jest zarezerwowanym adresem przykładowym. Polecenia to instrukcje do przejrzenia w twoim środowisku; ten przewodnik nie łączył się z serwerem OffVPS ani go nie konfigurował.

Utwórz klucz klienta bez zastępowania istniejącego

Twój klucz prywatny pozostaje na komputerze klienta. Pasujący klucz publiczny można zainstalować w autoryzowanych kluczach konta serwera. Żaden z nich nie jest kluczem hosta serwera: ten osobny klucz pomaga zidentyfikować maszynę, z którą się łączysz. Trzymaj klucz prywatny i jego hasło poza wiadomościami do pomocy technicznej, repozytoriami i przesłanymi plikami na serwer.

ssh -V
ls -ld "$HOME/.ssh"
ls "$HOME/.ssh/offvps_first_vps" "$HOME/.ssh/offvps_first_vps.pub"

Najpierw sprawdź ścieżki. Jeśli katalog SSH nie istnieje, utwórz go z uprawnieniami 700. Jeśli którykolwiek z nazwanych plików klucza już istnieje, wybierz inną nazwę lub świadomie użyj ponownie istniejącego klucza; nie nadpisuj go. Wygeneruj dedykowany klucz z hasłem:

ssh-keygen -t ed25519 -f "$HOME/.ssh/offvps_first_vps" -C "first-vps"
ssh-keygen -lf "$HOME/.ssh/offvps_first_vps.pub" -E sha256

Drugie polecenie wyświetla odcisk klucza publicznego, a nie materiał klucza prywatnego. podręcznik ssh-keygen opisuje typy kluczy, pliki wyjściowe i odciski. Jeśli zarządzane urządzenie wymaga innej polityki kluczy, postępuj zgodnie z tą polityką i zweryfikuj wsparcie serwera. Zachowaj odpowiednio chronioną kopię zapasową klucza prywatnego, jeśli twój plan odzyskiwania od niej zależy.

Zweryfikuj serwer przed uwierzytelnieniem

Za pośrednictwem zaufanej konsoli lub innego uwierzytelnionego kanału konfiguracji uzyskaj odcisk klucza hosta Ed25519 serwera. Na serwerze używającym standardowej ścieżki OpenSSH administrator może sprawdzić plik publiczny za pomocą:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Porównaj pełny odcisk SHA256 i algorytm z pierwszym monitem połączenia SSH. Odcisk uzyskany tylko przez to samo niezweryfikowane połączenie sieciowe nie jest niezależną weryfikacją. Jeśli serwer oferuje inny algorytm klucza hosta, uzyskaj odcisk tego klucza, zamiast porównywać różne wartości. Wytyczne weryfikacji klucza hosta OpenSSH wyjaśniają to porównanie.

Jeśli klucz zmieni się nieoczekiwanie przy późniejszej wizycie, zatrzymaj się. Przebudowa może zgodnie z prawem zastąpić klucze hosta, ale zweryfikuj to zdarzenie i nowy odcisk przez kanał odzyskiwania. Nie wyciszaj ostrzeżenia ani nie usuwaj starego wpisu znanego hosta tylko po to, aby połączenie się powiodło.

Zainstaluj tylko klucz publiczny i otwórz pierwszą sesję

Jeśli twój klucz publiczny został już zainstalowany przez autoryzowany proces konfiguracji, połącz się bezpośrednio. W przeciwnym razie użyj istniejącej zweryfikowanej metody dostępu, aby dodać klucz publiczny do zamierzonego konta. Na kliencie z ssh-copy-id, i tylko gdy ta początkowa metoda logowania działa, to polecenie dołącza wybrany klucz publiczny:

ssh-copy-id -i "$HOME/.ssh/offvps_first_vps.pub" -p 22 [email protected]

Ubuntu przewodnik OpenSSH opisuje instalację klucza publicznego i wymagania dotyczące uprawnień. Nie zastępuj całego pliku authorized_keys ani nie zmieniaj wpisów innego administratora. Następnie otwórz sesję opartą na kluczu:

ssh -o IdentitiesOnly=yes -i "$HOME/.ssh/offvps_first_vps" \
  -p 22 [email protected]

Po zalogowaniu sprawdź id oraz hostname. Potwierdź, że konto odpowiada danym konfiguracji; sama nazwa hosta nie jest weryfikacją klucza hosta. Jeśli twoje zadania wymagają administracji, uruchom sudo -v i ustal, że to konto ma zamierzoną ścieżkę uprawnień. Pozostaw tę pierwszą sesję otwartą.

Otwórz inny terminal klienta i zażądaj nowego połączenia, które nie może użyć gniazda współdzielenia połączeń SSH. Ogranicz ten test do uwierzytelniania kluczem publicznym, aby fallback hasła nie ukrył zepsutej konfiguracji klucza:

ssh -o ControlMaster=no -o ControlPath=none \
  -o IdentitiesOnly=yes -o PreferredAuthentications=publickey \
  -i "$HOME/.ssh/offvps_first_vps" -p 22 [email protected]

Sprawdź id, hostname i, tam gdzie potrzeba, sudo -v również w tej drugiej sesji. Sam nowy terminal nie wystarczy, jeśli klient używa istniejącego połączenia. ControlPath=none wyłącza to współdzielenie; zobacz konfiguracja klienta OpenSSH. Zamknij pierwotną sesję dopiero po udanym niezależnym połączeniu i gdy ścieżka odzyskiwania pozostaje dostępna.

Przed każdą późniejszą zmianą dostępu

W tej pierwszej sesji pozostaw port SSH, metody uwierzytelniania i reguły zapory bez zmian. Przed późniejszą ich zmianą zapisz bieżącą konfigurację i udokumentuj, jak ją przywrócić przez zaufaną konsolę. Potwierdź działające logowanie kluczem przed wyłączeniem innej metody. Pozostaw pierwszą sesję otwartą, wprowadzając jedną sprawdzoną zmianę naraz.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

W systemach z tą ścieżką pliku wykonywalnego OpenSSH, -t sprawdza składnię konfiguracji i poprawność klucza hosta; -T raportuje również efektywne ustawienia. Reguły Match specyficzne dla połączenia mogą wymagać parametrów -C dla testowanego konta i adresu. Te sprawdzenia nie testują osiągalności zapory ani nie dowodzą, że nowe logowanie działa. Zobacz tryby testowe sshd. Rozwiąż błędy przed zastosowaniem lub ponownym załadowaniem konfiguracji usługi, a następnie powtórz niezależne sprawdzenie logowania.

Przekroczenie limitu czasu: potwierdź adres, port, reguły dostawcy i zaporę hosta przez ścieżkę odzyskiwania.
Połączenie odrzucone: sprawdź, czy SSH nasłuchuje na oczekiwanym adresie i porcie.
Odmowa dostępu: sprawdź nazwę użytkownika, wybrany klucz publiczny i uprawnienia pliku klucza konta z wciąż otwartej sesji.
Zmieniona identyfikacja hosta: zweryfikuj maszynę i nowy odcisk niezależnie przed kontynuowaniem.

Zapisz zweryfikowany odcisk klucza hosta, konto, port i procedurę odzyskiwania w swoich notatkach operacyjnych. Trzymaj materiał klucza w tajemnicy. Gdy dostęp będzie powtarzalny, przejdź do twoje pierwsze wydanie API lub budżet zasobów dla aplikacji.

Wykorzystana dokumentacja

Główne źródła dla tej strony. Sprawdź dokumentację wersji zainstalowanej we własnym środowisku.