Jak odblokować konto do autoryzacji ssh klucza publicznego, ale nie do autoryzacji hasłem?

32

SSH nie pozwala mi się zalogować, ponieważ konto jest zablokowane. Chcę odblokować użytkownika na moim serwerze w celu autoryzacji klucza publicznego przez ssh, ale nie włączaj logowania za pomocą hasła.

Próbowałem:

# passwd -u username
passwd: unlocking the password would result in a passwordless account.
You should set a password with usermod -p to unlock the password of this account.

Wpisy dziennika uwierzytelnienia:

Mar 28 00:00:00 vm11111 sshd[11111]: User username not allowed because account is locked
Mar 28 00:00:00 vm11111 sshd[11111]: input_userauth_request: invalid user username [preauth]
kravemir
źródło
Państwo powinno (IMHO) to zrobić dla wszystkich użytkowników ... prosty config gdy robi to dla całego sshd
Skaperen
passwd -uto zły pomysł. Zobacz odpowiedź Giles poniżej.
Peter Jenkins,

Odpowiedzi:

15

Odblokuj konto i podaj użytkownikowi złożone hasło, jak sugeruje @Skaperen.

Edytuj /etc/ssh/sshd_configi upewnij się, że:

PasswordAuthentication no

Sprawdź, czy linia nie jest komentowana ( #na początku) i zapisz plik. Na koniec uruchom ponownie sshdusługę.

Zanim to zrobisz, upewnij się, że najpierw działa uwierzytelnianie klucza publicznego.

Jeśli musisz to zrobić tylko dla jednego (lub niewielkiej liczby) użytkowników, pozostaw PasswordAuthenticationwłączone i zamiast tego użyj Match User:

Match User miro, alice, bob
    PasswordAuthentication no

Umieść na dole pliku, ponieważ jest ważny do następnego Matchpolecenia lub EOF.

Możesz także użyć Match Group <group name>lub negacjiMatch User !bloggs

Jak wspomniałeś w komentarzach, możesz również odwrócić go, aby wyłączyć uwierzytelnianie hasła w głównej części konfiguracji i użyć Matchinstrukcji, aby włączyć je dla kilku użytkowników:

PasswordAuthentication no
.
.
.
Match <lame user>
    PasswordAuthentication yes
garethTheRed
źródło
mam wrażenie, że Miro chciał wyłączyć hasło tylko na jeden raz . ale zobacz mój wcześniejszy komentarz
Skaperen
@Skaperen - możesz mieć rację. Nieznacznie zmieniłem swoją odpowiedź.
garethTheRed
Ta Matchskładnia wygląda dobrze, ale spróbuję ją odwrócić. Włącz logowanie za pomocą hasła dla (kilku słabych) użytkowników.
kravemir
@Miro - To dobry pomysł, dodałem go do mojej odpowiedzi na przyszłość.
garethTheRed
37

Cokolwiek zrobisz, nie pozostawiaj konta w stanie pozostawionym przez passwd -u, z pustym polem hasła: pozwala na logowanie bez wprowadzania hasła (z wyjątkiem SSH, ponieważ SSH tego odmawia).

Zmień konto, aby nie mieć hasła, ale zostanie odblokowane. Konto nie ma hasła, jeśli skrót hasła w bazie danych haseł nie jest skrótem żadnego ciągu. Tradycyjnie używany jest do tego ciąg jednoznakowy, taki jak *lub !.

Zablokowane konta używają również specjalnego znacznika w polu hasła, który powoduje, że łańcuch nie jest skrótem żadnego łańcucha. Znacznik zależy od systemu. W systemie Linux passwdpolecenie oznacza zablokowane hasła, umieszczając !na początku symbol a, a OpenSSH traktuje konto jako zablokowane, jeśli pole zaczyna się od !. Inne warianty Uniksa zwykle używają podobnych, ale nie identycznych mechanizmów, więc uważaj, jeśli baza danych haseł jest współużytkowana przez sieć heterogeniczną.

W systemie Linux można wyłączyć dostęp do konta za pomocą hasła, jednocześnie umożliwiając dostęp SSH (za pomocą innej metody uwierzytelniania, zwykle pary kluczy) za pomocą

usermod -p '*' username

Użytkownik nie będzie mógł przywrócić konta do hasła, ponieważ wymaga to podania prawidłowego hasła.

Jeśli chcesz, możesz zamiast tego skonfigurować SSH, aby odmawiał uwierzytelnienia za pomocą hasła, niezależnie od tego, czy konto ma hasło. Nadal będziesz musiał zadbać o to, aby SSH nie traktował konta jako zablokowanego, więc na przykład w systemie Linux musisz usunąć !pole hasła (ale nie pozostaw tego pola pustego - ustaw je *zgodnie z powyższym opisem ). Aby wyłączyć uwierzytelnianie hasła dla SSH, dodaj PasswordAuthenticationdyrektywę do /etc/sshd_configlub /etc/ssh/sshd_config(w zależności od tego, co znajduje się w twoim systemie). Użyj Matchbloku, aby ta dyrektywa miała zastosowanie tylko do określonego użytkownika; Matchbloki muszą się pojawić

…
Match User username
    PasswordAuthentication no
Gilles „SO- przestań być zły”
źródło
6
Dzięki - usermod -p '*' usernamedziałał urok!
Homme Zwaagstra
1
OpenSSHd pozwala zablokowanym użytkownikom (np. Hash hasłem z !prefiksem) zalogować się za pomocą innej metody uwierzytelnienia, jeśli UsePAM yesjest ustawiona na sshd_config. Jest to prawdopodobnie ustawienie domyślne w większości dystrybucji (np. W Fedorze).
maxschlepzig
1
Mam system osadzony bez PAM, więc rozróżnienie '*'vs. '!'jest bardzo przydatne.
jpkotta
8

Nie musisz włączać ani ustawiać haseł, a tak naprawdę nie powinieneś, jeśli już używasz silnych kluczy. Wystarczy ponownie zablokować konto (sudo passwd -l nazwa użytkownika) z istniejącej sesji i naprawić konfigurację SSH.

Powodem tego jest prawdopodobnie to, że edytowałeś jedno z domyślnych ustawień demona SSH (w / etc / ssh / sshd_config).

Zmień to w / etc / ssh / sshd_config i zrestartuj SSH:

UsePAM yes

Zasadniczo, chyba że masz naprawdę dobry powód, aby wyłączyć PAM, zalecamy włączenie go; włączenie PAM w SSH pozwoli ci nadal się logować, nawet po usunięciu hasła. Cokolwiek robisz, nie ustawiaj pustego hasła lub podobnego ... zablokowanie pola hasła nie musi oznaczać zablokowania całego konta.

Szybka wskazówka dotycząca bałagania w SSH: utrzymuj kolejną sesję otwartą (w innym oknie) przy każdej zmianie konfiguracji SSH, a następnie sprawdź, czy nadal możesz się zalogować; jeśli przypadkowo przerwiesz dostęp, skorzystaj z bieżącej sesji, aby go naprawić.

(Zastrzeżenie: Pracuję w Userify, który zapewnia oprogramowanie do zarządzania kluczami SSH.)

Jamieson Becker
źródło
0

Miałem ten problem na CentOS 7. Jestem zwykłym użytkownikiem Linuksa opartym na Debianie, więc byłem rybą z wody. Zauważyłem, że na niektórych serwerach działało, a na jednym nie. Audyt.log nie powiedział nic przydatnego, a bezpieczny.log też nic nie dał. Odkryłem, że jedyną prawdziwą różnicą były różnice w kontekście bezpieczeństwa plików i katalogów między tymi, które działały, a tymi, które nie działały. Uzyskaj bezpieczeństwo dzięki

sudo ls -laZ <user-home>/.ssh

katalogu (zakładam, że wiele domyślnych ustawień w sshd_config).

Powinieneś zobaczyć niektóre ssh_home_ti user_home_tatrybuty. Jeśli nie, użyj chconpolecenia, aby dodać brakujące atrybuty.

Na przykład

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

W moim przypadku podejrzewam, że użytkownik został utworzony w niestandardowy sposób. Jego domem był katalog /var/lib.

Więcej informacji w: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

hanzo2001
źródło
-2

odblokuj konto i zmień hasło na dowolny losowy ciąg

Skaperen
źródło