Na tej stronie podane wyjaśnienie to:
Opcja PasswordAuthentication określa, czy powinniśmy używać uwierzytelniania opartego na haśle. Dla silnego bezpieczeństwa ta opcja musi być zawsze ustawiona na tak.
Ale nie zawiera scenariuszy przypadków użycia, które wyjaśniają, kiedy tak lub nie byłoby właściwe. Czy ktoś może bardziej szczegółowo opracować?
Odpowiedzi:
Twój link wskazuje na dokumentację 10 lat przedawnienia.
SSH obsługuje wiele sposobów uwierzytelniania użytkowników, najczęstszym z nich jest pytanie o login i hasło, ale można również uwierzytelnić użytkownika login i klucz publiczny. Jeśli ustawisz PasswordAuthentication na no, nie będziesz już mógł używać loginu i hasła do uwierzytelnienia i musisz zamiast tego użyć loginu i klucza publicznego (jeśli PubkeyAuthentication jest ustawiony na yes)
Należy pamiętać, że ustawienie PasswordAuthentication nie kontroluje WSZYSTKICH uwierzytelnień opartych na hasłach. ChallengeResponseAuthentication zwykle pyta również o hasła.
Uwierzytelnianie hasła kontroluje obsługę schematu uwierzytelniania „hasłem” zdefiniowanego w RFC-4252 (sekcja 8). ChallengeResponseAuthentication kontroluje obsługę schematu uwierzytelniania „interaktywnego z klawiaturą” zdefiniowanego w RFC-4256. Schemat uwierzytelniania „interaktywny za pomocą klawiatury” mógłby teoretycznie zadać użytkownikowi dowolną liczbę pytań o wielu twarzach. W praktyce często pyta tylko o hasło użytkownika.
Jeśli chcesz całkowicie wyłączyć uwierzytelnianie oparte na hasłach, ustaw ZARÓWNO PasswordAuthentication i ChallengeResponseAuthentication na „no”. Jeśli jesteś nastawiony na pasy i szelki, zastanów się również nad ustawieniem UsePAM na „nie”.
Uwierzytelnianie oparte na kluczu publicznym / prywatnym (włączane przez ustawienie PubkeyAuthentication) to osobny rodzaj uwierzytelnienia, który oczywiście nie obejmuje wysyłania haseł użytkowników na serwer.
Niektórzy twierdzą, że korzystanie z ChallengeResponseAuthentication jest bezpieczniejsze niż PasswordAuthentication, ponieważ trudniej jest je zautomatyzować. Dlatego zalecają pozostawienie PasswordAuthentication wyłączone, a ChallengeResponseAuthentication włączone. Ta konfiguracja zachęca również (ale niekoniecznie uniemożliwia) korzystanie z uwierzytelniania publickey w przypadku zautomatyzowanych logowań systemowych. Ponieważ jednak SSH jest protokołem sieciowym, serwer nie ma sposobu, aby zagwarantować, że odpowiedzi na ChallengeResponseAuthentication (inaczej „interaktywna klawiatura”) są faktycznie dostarczane przez użytkownika siedzącego przy klawiaturze, o ile wyzwania są zawsze i polega tylko na pytaniu użytkownika o hasło.
UsePAM...
Uwierzytelnianie hasła jest najłatwiejszą implementacją, ponieważ nie ma nic do zrobienia. Część przeciwna polega na tym, że wysyłasz swoje hasło za pośrednictwem szyfrowanego połączenia na serwer. Może to stanowić problem z bezpieczeństwem, jeśli serwer został przejęty, ponieważ można wtedy przechwycić hasło.
W przypadku klucza publicznego twoje hasło nie jest przesyłane do serwera, jest bardziej bezpieczne, ale wymaga większej konfiguracji.
Możesz ustawić tę opcję na no podczas używania kluczy lub wymusić ich użycie.