Nie mogę uruchomić sesji SSH

Sesje SSH kierowane przez VaultPAM opierają się na tym, że konektor nawiązuje połączenie z hostem docelowym na porcie TCP 22 (lub niestandardowym porcie SSH). Gdy sesja nie może się otworzyć, niemal zawsze odpowiada za to jedna z pięciu głównych przyczyn. Przejdź przez nie w kolejności wymienionej tutaj — problemy z konektorem i siecią są znacznie częstsze niż problemy z poświadczeniami lub kluczami.

Objawy

• Kliknięcie Uruchom sesję powoduje wyświetlenie wskaźnika ładowania, a następnie banera z błędem.
• Okno sesji otwiera się na chwilę, po czym zamyka się z komunikatem takim jak:
  • SSH connection refused
  • Host unreachable
  • Authentication failed
  • Host key verification failed
  • Permission denied (publickey)
• Sesja nigdy nie pojawia się w widoku Aktywne sesje.

Przyczyny

1. Konektor jest offline

Konektor kierujący ruch do hosta docelowego musi mieć status Online. Jeśli jest Offline, W trybie ograniczonym lub Wymaga odzyskania, każda próba sesji przez niego zakończy się niepowodzeniem.

Sprawdź: Otwórz Konektory na pasku bocznym. Znajdź konektor przypisany do docelowego sejfu. Potwierdź, że kolumna statusu pokazuje Online.

Napraw: Postępuj zgodnie z instrukcją Mój konektor jest offline.

2. Port 22 jest zablokowany między konektorem a celem

Maszyna konektora musi mieć możliwość połączenia z hostem docelowym na porcie SSH (domyślnie 22). Reguła zapory, grupa zabezpieczeń lub zapora na poziomie hosta (np. ufw, Zapora systemu Windows) może to blokować.

Sprawdź: Na maszynie konektora uruchom:

nc -zv <target-host> 22

lub

ssh -v <username>@<target-host>

Odpowiedź Connection refused lub przekroczenie limitu czasu potwierdza blokadę sieciową.

Napraw: Zaktualizuj zaporę lub grupę zabezpieczeń, aby zezwolić na ruch TCP 22 z adresu IP konektora do celu. Jeśli cel używa niestandardowego portu SSH, sprawdź, czy w ustawieniach sejfu skonfigurowano prawidłowy port: Sejfy → wybierz sejf → Edytuj → Ustawienia połączenia → Port.

3. Nieprawidłowa nazwa użytkownika

Nazwa użytkownika używana do połączenia SSH musi istnieć na hoście docelowym i dokładnie się zgadzać (nazwy użytkowników w systemie Linux rozróżniają wielkość liter).

Sprawdź: W Sejfy → wybierz sejf → Edytuj → Poświadczenia potwierdź, że nazwa użytkownika jest poprawna. Częste pomyłki: root zamiast ubuntu, admin zamiast administrator lub pozostawiona wartość domyślna z szablonu.

Napraw: Zaktualizuj rekord poświadczenia, aby używał prawidłowej nazwy użytkownika.

4. Niezgodność klucza hosta

VaultPAM zapisuje klucz hosta SSH przy pierwszym połączeniu. Jeśli host docelowy został odbudowany, a jego klucze serwera SSH uległy zmianie (np. po ponownej instalacji systemu operacyjnego), VaultPAM odmówi połączenia, aby chronić przed atakami typu man-in-the-middle.

Objawy: Komunikat o błędzie zawiera Host key verification failed lub REMOTE HOST IDENTIFICATION HAS CHANGED.

Sprawdź: Otwórz Sejfy → wybierz sejf → Edytuj → Ustawienia połączenia. Jeśli widoczny jest zapisany odcisk palca klucza hosta, porównaj go z bieżącym kluczem hosta, uruchamiając na maszynie docelowej:

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

Napraw: Jeśli zmiana klucza jest oczekiwana (uzasadniona odbudowa), kliknij Zresetuj klucz hosta w ustawieniach połączenia sejfu. VaultPAM zaakceptuje nowy klucz przy następnej próbie połączenia i zapisze go do przyszłej weryfikacji.

5. Brakujący lub odrzucony klucz SSH

Jeśli sejf skonfigurowano do używania uwierzytelniania kluczem publicznym zamiast pobierania hasła, konektor musi mieć dostęp do klucza prywatnego, który jest autoryzowany na hoście docelowym.

Sprawdź: W Sejfy → wybierz sejf → Edytuj → Poświadczenia potwierdź, że typ poświadczenia jest ustawiony na Klucz SSH i że dołączono klucz. Sprawdź, czy odpowiadający klucz publiczny jest wymieniony w ~/.ssh/authorized_keys na hoście docelowym dla skonfigurowanego użytkownika.

Napraw: Prześlij prawidłowy klucz prywatny do rekordu poświadczenia lub dodaj klucz publiczny konektora do authorized_keys na hoście docelowym.

Kroki rozwiązania

1. Otwórz Konektory na pasku bocznym i potwierdź, że konektor przypisany do docelowego sejfu pokazuje status Online. Jeśli nie, przed kontynuacją postępuj zgodnie z instrukcją Mój konektor jest offline.
2. Na maszynie konektora uruchom nc -zv <target-host> 22, aby potwierdzić, że port TCP 22 jest osiągalny. Jeśli jest zablokowany, zaktualizuj odpowiednią regułę zapory lub grupy zabezpieczeń.
3. Otwórz Sejfy → wybierz sejf → Edytuj → Poświadczenia i zweryfikuj nazwę użytkownika. Popraw ją, jeśli nie odpowiada kontu hosta docelowego.
4. Jeśli błąd wspomina o niezgodności klucza hosta, otwórz Sejfy → wybierz sejf → Edytuj → Ustawienia połączenia i kliknij Zresetuj klucz hosta, a następnie ponów próbę sesji.
5. Jeśli sejf używa uwierzytelniania kluczem SSH, potwierdź, że klucz prywatny jest dołączony do rekordu poświadczenia, a pasujący klucz publiczny znajduje się w ~/.ssh/authorized_keys na hoście docelowym.
6. Po każdej zmianie ponów próbę sesji, klikając Uruchom sesję na sejfie.

Ścieżka eskalacji

Jeśli przeszedłeś przez wszystkie pięć przyczyn, a sesja nadal kończy się niepowodzeniem:

1. Zanotuj dokładny komunikat o błędzie wyświetlony na banerze sesji.
2. Na maszynie konektora zbierz ostatnie 100 wierszy dziennika konektora:
   • Docker: docker logs -n 100 vaultpam-connector
   • systemd: journalctl -u vaultpam-connector -n 100
3. Uruchom nc -zv <target-host> 22 na maszynie konektora i dołącz wynik.
4. Otwórz zgłoszenie do pomocy technicznej, podając: nazwę konektora, host docelowy (zamaskowany, jeśli jest wrażliwy), dokładny komunikat o błędzie, dane wyjściowe dziennika oraz wynik nc.

Powiązane artykuły

• Mój konektor jest offline
• Rotacja poświadczenia