Ogranicz logowanie przez SSH i używaj certyfikatów

Gdy logowanie za pomocą kluczy działa, serwer nie musi już akceptować haseł przez sieć. To blokuje wszystkich, którzy próbują zgadywać hasła. W tej części bezpiecznie wyłączasz logowanie za pomocą haseł oraz logowanie jako użytkownik root. Na koniec zobaczysz, jak certyfikaty SSH ułatwiają zarządzanie dostępem do wielu serwerów.

Wymagania wstępne

• Logowanie kluczem działa, patrz [[SSH Level 2 - Klucz zamiast hasła|SSH Level 2]].
• Twój użytkownik ma uprawnienia sudo, patrz [[Instalacja serwera Level 4 - Przygotuj serwer|Przygotuj serwer]].
• Konsola w Proxmox jest otwarta. Służy ona jako awaryjna ścieżka dostępu, jeśli zostaniesz zablokowany w SSH.

Wyłącz logowanie hasłem oraz jako użytkownik root

Usługa SSH odczytuje konfigurację z pliku /etc/ssh/sshd_config oraz z plików w katalogu /etc/ssh/sshd_config.d/. Utwórz osobny plik, aby łatwo śledzić wprowadzone zmiany i móc je cofnąć:

# Redaktorer konfigurationsfilen for SSH-serveren med sudo og nano
nano /etc/ssh/sshd_config.d/10-sikker.conf

Wpisz:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

PasswordAuthentication no wyłącza zwykłą uwierzytelnianie hasłem. KbdInteractiveAuthentication no również wyłącza interaktywne uwierzytelnianie klawiaturą, które w przeciwnym razie może akceptować hasła za pośrednictwem PAM. PermitRootLogin no całkowicie blokuje logowanie jako użytkownik root.

W przypadku większości ustawień SSH obowiązuje pierwsza wartość odczytana przez usługę. Twój plik nie ma więc automatycznie priorytetu nad innymi plikami: lokalizacja dyrektywy Include, wcześniejsze ustawienia oraz ewentualne bloki Match mogą wpłynąć na wynik. Sprawdź efektywne wartości przed wprowadzeniem zmian.

Sprawdź ustawienia przed ich zastosowaniem:

sudo sshd -t

Jeśli nie pojawi się żadna wiadomość, składnia jest poprawna. Następnie sprawdź wartości wynikające z nowej konfiguracji:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '

Wszystkie trzy powinny wyświetlać no. Jeśli otrzymasz inne wartości, sprawdź plik /etc/ssh/sshd_config oraz pliki w nim zawarte przed przejściem dalej. W przypadku reguł Match możesz również zweryfikować bieżące połączenie za pomocą polecenia sudo sshd -T -C user=użytkownik,addr=ADRESA-KLIENTA,host=NAZWA_KLIENTA, zastępując przykładowe wartości nazwą użytkownika, adresem klienta i nazwą klienta dla logowania poddanego testowi. Wykonaj ten sam kontrolny przegląd trzech ustawień.

Gdy wartości są poprawne, wczytaj zmianę:

sudo systemctl reload ssh

Nie zamykaj okna, w którym jesteś zalogowany. Otwórz nowe okno terminala i przetestuj:

ssh debian-vm                 # powinno działać
ssh root@SERVER-IP            # powinno zostać odrzucone
ssh -o PubkeyAuthentication=no user@SERVER-IP   # powinno zostać odrzucone, bez pytania o hasło

Hasło użytkownika jest nadal wymagane do sudo. Jest zapisywane na serwerze, a nie przesyłane przez sieć.

Pogłębienie: Certyfikaty SSH

W przypadku dziesięciu serwerów i pięciu administratorów każdy klucz musi znajdować się na każdym serwerze. Powoduje to powstanie pięćdziesięciu wpisów w pliku authorized_keys, a gdy ktoś odchodzi, klucz należy usunąć ze wszystkich miejsc.

Przy użyciu certyfikatów wydawca certyfikatów (CA) podpisuje Twój klucz. Serwery ufają CA, nie każdemu pojedynczemu kluczowi. Certyfikat zawiera również:

• principals: nazwy, dla których ważny jest certyfikat, np. admin
• okres obowiązywania: kiedy certyfikat przestaje być ważny

Konfiguracja serwera

Potrzebujesz publicznego klucza od osoby zarządzającej CA (np. nauczyciela). Umieść go na serwerze:

sudo nano /etc/ssh/lab_user_ca.pub

Określ, które podmioty mogą się zalogować jako użytkownik user:

sudo mkdir -p /etc/ssh/auth_principals
echo admin | sudo tee /etc/ssh/auth_principals/user

Poinformuj usługę SSH o certyfikacie CA:

sudo nano /etc/ssh/sshd_config.d/10-lab-ca.conf

TrustedUserCAKeys /etc/ssh/lab_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

%u zostaje zastąpione nazwą użytkownika, pod którą wykonano logowanie. Skonfiguruj i przeładaj za pomocą poleceń sudo sshd -t oraz sudo systemctl reload ssh.

Zaloguj się za pomocą certyfikatu

Certyfikat znajduje się obok klucza prywatnego i kończy się na -cert.pub. Zobacz jego zawartość:

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Szukaj Principals, Valid oraz Signing CA. Umieść certyfikat w pliku ~/.ssh/config:

Host debian-vm
    HostName SERVER-IP
    User user
    IdentityFile ~/.ssh/id_ed25519
    CertificateFile ~/.ssh/id_ed25519-cert.pub

Teraz logujesz się za pomocą polecenia ssh debian-vm, podczas gdy Twój klucz nie znajduje się w pliku authorized_keys na serwerze.

Jak podpisuje CA (dla osoby zarządzającej CA)

ssh-keygen -t ed25519 -f lab_user_ca                  # utwórz klucz CA tylko raz, przechowuj go bezpiecznie
ssh-keygen -s lab_user_ca -I elev@skolen -n admin -V +52w id_ed25519.pub

-n oznacza podmiot (principal), -V określa czas ważności, a -I jest identyfikatorem wyświetlanym w dziennikach na serwerze. Prywatny klucz CA zapewnia dostęp do wszystkich serwerów, które mu ufają, dlatego nigdy nie powinien być przechowywany na serwerze ani udostępniany.

Jeśli coś pójdzie nie tak

1. Jesteś zablokowany na zewnątrz: Zaloguj się w konsoli Proxmox, usuń plik utworzony przez Ciebie w /etc/ssh/sshd_config.d/ i uruchom sudo systemctl reload ssh.
2. sshd -t zgłasza błąd:` Komunikat wskazuje nazwę pliku i numer linii. Popraw literówkę przed załadowaniem konfiguracji.
3. Certyfikat nie jest akceptowany: Sprawdź, czy identyfikator (principal) w certyfikacie (ssh-keygen -L) znajduje się w /etc/ssh/auth_principals/user, oraz że certyfikat nie wygasł. Na serwerze polecenie sudo journalctl -u ssh -n 20 pokaże powód odrzucenia logowania.

Ważne pojęcia

Kontrolelementer

• ssh root@SERVER-IP blir avvist.
• Pålogging med passord via SSH blir avvist.
• Du kan forklare hvorfor du testet i ett nytt vindu før du lukket den gamle.
• Utvidelse: du kan forklare hvorfor en CA er enklere enn authorized_keys på mange servere.

Kilde: OpenSSH – sshd_config.