Najlepiej używać kluczy publicznych do SSH. Więc mój sshd_config
ma 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ę?
sudo
uzyskania dostępu (albo z powodu braku uprawnień sudo, albo z uprawnieniami sudo zNOPASSWD
), 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.Odpowiedzi:
Jeśli masz uprawnienia roota do serwera i możesz ponownie wygenerować klucze ssh dla użytkowników na wypadek ich utraty
I
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)
I
nigdy nie będą potrzebować „fizycznego” (przez klawiaturę + monitor lub zdalną konsolę dla maszyny wirtualnej) dostępu do serwera
I
żaden użytkownik nie ma
sudo
dostępu do hasła (tzn. albo nie ma dostępu sudo, albo ma dostęp sudo zNOPASSWD
)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).
źródło
PasswordAuthentication no
, jest to inny problem (użytkownik i tak nie będzie mógł się zalogować).To pierwotnie wspomniane pytanie
passwd --delete <username>
jest niebezpieczne : dzięki temu pole zaszyfrowanego hasła/etc/shadow
będzie całkowicie puste.Jeśli skonfigurowałeś
sshd
odmawianie 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-passwd
wyświetli/etc/shadow
wpis, w którym pole zaszyfrowanego hasła jest tylko gwiazdką, tjTo 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:
Istnieje trzecia wartość specjalna dla pola zaszyfrowanego hasła:
adduser --disabled-login
wtedy pole będzie zawierać tylko jeden wykrzyknik.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 -l
ma 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
passwd
polecenia pochodzącego ze staregoshadow
pakietu została zmieniona, aby zmienić definicjępasswd -l
z „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 2008passwd -l
pochodzi on zshadow
zestawu ź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:
Historie błędów dla błędu 492307 i błędu 389183 w Debianie mogą być pomocne w zrozumieniu tego myślenia.
źródło
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?adduser --disabled-password
szczególności uniemożliwia uwierzytelnienie hasłem dla tego konta.*
więc jest to pierwsza rzecz, którą ludzie czytają.passwd
kodzie ź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?