Czy powinienem usunąć hasła użytkowników po skonfigurowaniu uwierzytelniania klucza publicznego dla SSH?

Najlepiej używać kluczy publicznych do SSH. Więc mój sshd_configma PasswordAuthentication no.

Niektórzy użytkownicy nigdy się nie logują, np. Użytkownik sftp z powłoką /usr/sbin/nologin. Lub konto systemowe.

Mogę więc utworzyć takiego użytkownika bez hasła adduser gary --shell /usr/sbin/nologin --disabled-password.

Czy to dobry / zły pomysł? Czy są jakieś konsekwencje, których nie wziąłem pod uwagę?

— lonix
źródło

Tak długo, jak nie są to rzeczywiste konta użytkowników lub nie potrzebują hasła do sudouzyskania dostępu (albo z powodu braku uprawnień sudo, albo z uprawnieniami sudo z NOPASSWD), wybrana odpowiedź powinna być odpowiednia. Przesłałem poprawkę do tej odpowiedzi, aby uwzględnić problem sudo, ale pomyślałem, że w międzyczasie przywołam ją tutaj.

— Doktor J

Odpowiedzi:

Jeśli masz uprawnienia roota do serwera i możesz ponownie wygenerować klucze ssh dla użytkowników na wypadek ich utraty

masz pewność, że użytkownik (jako osoba) nie będzie miał wielu kont użytkowników i będzie musiał przełączać się między kontami w sesji SSH (cóż, jeśli zajdzie taka potrzeba , może również otworzyć wiele sesji SSH)

nigdy nie będą potrzebować „fizycznego” (przez klawiaturę + monitor lub zdalną konsolę dla maszyny wirtualnej) dostępu do serwera

żaden użytkownik nie ma sudodostępu do hasła (tzn. albo nie ma dostępu sudo, albo ma dostęp sudo z NOPASSWD)

Myślę, że będziesz dobry.

Mamy skonfigurowanych w ten sposób wiele serwerów (tylko niektóre konta potrzebują dostępu do maszyny wirtualnej za pośrednictwem zdalnej konsoli vmware, inne łączą się tylko przez SSH z uwierzytelnianiem klucza publicznego).

— Pan Shunz
źródło

Dodałbym również „wiesz, że użytkownicy nigdy nie będą musieli uzyskiwać dostępu do systemu ze zdalnych systemów, które nie mają swojego prywatnego klucza SSH”. I „Jesteś gotowy poradzić sobie z użytkownikami, którzy wpadli w sytuację, o której nie pomyślałeś”.

— Andrew Henle,

Pierwszym warunkiem jest to, że IMO nie jest konieczne. Użytkownicy powinni sami tworzyć klucze. Po prostu autoryzujesz ich klucze publiczne, gdy ci je dają. Jeśli zgubią klucz, wygenerują kolejny, a ty zastąpisz stary na serwerze.

— Christophe Drevet-Droguet

@AndrewHenle To dobra uwaga, jednak jeśli sshd ma PasswordAuthentication no, jest to inny problem (użytkownik i tak nie będzie mógł się zalogować).

— lonix,

„Nigdy” nie trwa tak długo. Administrator może łatwo dodać uwierzytelnianie hasła, jeśli zajdzie taka potrzeba.

— hyde

Cóż, pytanie wyraźnie odnosi się do kont, które zdecydowanie nie logują się (i prawdopodobnie nie powinny) logować, jak konta systemowe używane przez określone usługi lub użytkowników korzystających wyłącznie z sftp. Pytanie stwierdza również, że użytkownicy nie mają powłoki logowania. W przypadku tych typów użytkowników uważam, że zaleca się jawne wyłączenie logowania za pomocą hasła.

— Christian Gawron

To pierwotnie wspomniane pytanie passwd --delete <username> jest niebezpieczne : dzięki temu pole zaszyfrowanego hasła /etc/shadowbędzie całkowicie puste.

username::...

Jeśli skonfigurowałeś sshdodmawianie uwierzytelniania hasła, to jest to bezpieczne z SSH ... Ale jeśli jakakolwiek inna usługa w twoim systemie używa uwierzytelniania hasła i nie jest skonfigurowana do odrzucania haseł zerowych, umożliwia to dostęp bez hasła! Nie chcesz tego.

adduser --disabled-passwdwyświetli /etc/shadowwpis, w którym pole zaszyfrowanego hasła jest tylko gwiazdką, tj

username:*:...

To jest „zaszyfrowane hasło, które nigdy nie może być z powodzeniem wprowadzony”, czyli oznacza to, że konto jest ważne i technicznie pozwala loginów, ale to sprawia, że autoryzacja hasłem niemożliwe do osiągnięcia sukcesu . Jeśli więc masz na serwerze jakiekolwiek inne usługi oparte na uwierzytelnianiu hasła, ten użytkownik jest przed nimi zablokowany.

Tylko metody uwierzytelniania, które używają czegoś innego niż standardowe hasło do konta (np. Klucze SSH) będą działać dla tego użytkownika dla każdej usługi, która korzysta z plików haseł systemowych w tym systemie. Jeśli potrzebujesz użytkownika, który może zalogować się tylko za pomocą kluczy SSH, właśnie tego chcesz.

Jeśli chcesz ustawić istniejące konto na ten stan, możesz użyć tego polecenia:

echo 'username:*' | chpasswd -e

Istnieje trzecia wartość specjalna dla pola zaszyfrowanego hasła: adduser --disabled-loginwtedy pole będzie zawierać tylko jeden wykrzyknik.

username:!:...

Podobnie jak gwiazdka, uniemożliwia to uwierzytelnienie hasła, ale ma również dodatkowe znaczenie: oznacza hasło jako „zablokowane” w przypadku niektórych narzędzi administracyjnych. passwd -lma taki sam efekt, poprzedzając istniejący skrót hasłem wykrzyknikiem, co ponownie uniemożliwia użycie uwierzytelniania hasła.

Ale oto pułapka dla nieostrożnych: w 2008 roku wersja passwdpolecenia pochodzącego ze starego shadowpakietu została zmieniona, aby zmienić definicję passwd -lz „blokowania konta” na „blokowanie hasła”. Podanym powodem jest „zgodność z inną wersją passwd”.

Jeśli (jak ja) nauczyłeś się tego dawno temu, może to być nieprzyjemną niespodzianką. To nie pomaga w kwestiach, które adduser(8)najwyraźniej nie są jeszcze świadome tego rozróżnienia.

Część, która wyłącza konto dla wszystkich metod uwierzytelniania jest rzeczywiście ustawienie daty wygaśnięcia wartość z 1 na rachunek: usermod --expiredate 1 <username>. Przed rokiem 2008 passwd -lpochodzi on z shadowzestawu źródłowego używanego do tego oprócz prefiksu hasła z wykrzyknikiem - ale już tego nie robi.

Dziennik zmian pakietów Debiana mówi:

debian / patches / 494_passwd_lock-no_account_lock: Przywróć poprzednie zachowanie passwd -l (które zmieniło się w # 389183): zablokuj tylko hasło użytkownika, a nie konto użytkownika. Również wyraźnie udokumentuj różnice. To przywraca zachowanie wspólne z poprzednimi wersjami passwd i innymi implementacjami. Zamyka: # 492307

Historie błędów dla błędu 492307 i błędu 389183 w Debianie mogą być pomocne w zrozumieniu tego myślenia.

— telcoM
źródło

Dzięki za ostrzeżenie ... Zredaguję pytanie, żeby nikt nie popełnił tego błędu!

— lonix,

Czy Twoje ostrzeżenie dotyczy również przypadku, w którym korzystam adduser --disabled-passwd- więc jeśli jakaś inna usługa umożliwia uwierzytelnianie za pomocą hasła, to użytkownik może zalogować się bez hasła?

— lonix,

Nie, w adduser --disabled-passwordszczególności uniemożliwia uwierzytelnienie hasłem dla tego konta.

— telcoM,

Ponieważ usunięcie hasła wydaje się takie niewinne, ale jest tak niebezpieczne, sugeruję zamianę akapitu na ten temat na akapit dotyczący używania, *więc jest to pierwsza rzecz, którą ludzie czytają.

— Captain Man,

Wow, to paskudna niespodzianka, która czeka na zdarzenie ... i jak zwykle najwyraźniej jest to wina kompatybilności. Pojawiło się w passwdkodzie źródłowym w 2008 roku. Czy nie podoba ci się to, gdy coś, czego kiedyś się nauczyłeś, a potem na czym polegałeś, okazuje się już nie tak?

— telcoM