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

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]

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

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

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.)

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/

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