ssh: „Odmowa dostępu przez konfigurację konta PAM” dla jednego użytkownika innego niż root, ale nie dla innego

Na maszynie wirtualnej inicjuję się. Jestem w stanie zalogować się jako użytkownik inny niż root ( admin), ale nie inny ( tbbscraper) przez SSH z uwierzytelnianiem za pomocą klucza publicznego. Jedyny komunikat o błędzie, który mogę znaleźć w dowolnym pliku dziennika, to

Sep 18 17:21:04 [REDACTED] sshd[18942]: fatal: Access denied for user tbbscraper by PAM account configuration [preauth]

Po stronie klienta syndrom jest

$ ssh -v -i [REDACTED] tbbscraper@[REDACTED]
...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: [REDACTED]
debug1: Authentications that can continue: publickey
debug1: Trying private key: [REDACTED]
debug1: read PEM private key done: type RSA
Connection closed by [REDACTED]

Zmiana „tbbscraper” na „admin” pozwala na pomyślne logowanie: debug1: Authentication succeeded (publickey).pojawia się zamiast komunikatu „Połączenie zamknięte”.

To nie wydaje się być problemem z uprawnieniami ...

# for x in admin tbbscraper
> do ls -adl /home/$x /home/$x/.ssh /home/$x/.ssh/authorized_keys
> done
drwxr-xr-x 3 admin admin 4096 Sep 18 17:19 /home/admin
drwx------ 2 admin admin 4096 Sep 18 16:53 /home/admin/.ssh
-rw------- 1 admin admin  398 Sep 18 17:19 /home/admin/.ssh/authorized_keys
drwxr-xr-x 3 tbbscraper tbbscraper 4096 Sep 18 17:18 /home/tbbscraper
drwx------ 2 tbbscraper tbbscraper 4096 Sep 18 17:18 /home/tbbscraper/.ssh
-rw------- 1 tbbscraper tbbscraper  398 Sep 18 17:18 /home/tbbscraper/.ssh/authorized_keys

# cmp /home/{admin,tbbscraper}/.ssh/authorized_keys ; echo $?
0

... ani problem kontroli dostępu na poziomie PAM ...

# egrep -v '^(#|$)' /etc/security/*.conf
#

... więc żadna z istniejących odpowiedzi na podobne pytania nie wydaje się mieć zastosowania. Jedyny inny dowód, jaki mam, to:

root@[REDACTED] # su - admin
admin@[REDACTED] $

ale

root@[REDACTED] # su - tbbscraper
su: Authentication failure
(Ignored)
tbbscraper@[REDACTED] $

co sugeruje jakiś problem z PAM na większą skalę, ale nie mogę znaleźć niczego wyraźnie złego w tych rzeczach /etc/pam.d. Jakieś pomysły?

VM to instancja EC2, system operacyjny to Debian 7.1 (gotowy AMI Amazon).

Po tym wszystkim okazuje się, że jest to literówka jednoznakowa /etc/shadow. Zauważyć różnicę:

admin:!:15891:0:99999:7:::
tbbscraper:!::15966:0:99999:7:::

Zgadza się, za wykrzyknikiem na tbbscraperlinii są dwa dwukropki . To przenosi wszystkie pola nad jednym i sprawia, że ​​PAM myśli, że konto wygasło 8 stycznia 1970 r.

Dziękujemy za opublikowanie pytania. Otrzymywałem ten sam błąd, ale mój problem nie był związany z plikiem cienia. Znalazłem swoją poprawkę i chciałem również opublikować odpowiedź dla każdego innego Googlującego ten błąd. To pytanie o awarię serwera pojawia się jako pierwsze.

Spróbuj sprawdzić /etc/security/access.conf!

Używamy Active Directory do uwierzytelniania, ale musiałem zalogować się jako lokalny użytkownik spoza AD (Jenkins). Mój szef pierwotnie skonfigurował pudełko z następującą linią w /etc/security/access.conf:

+:root:ALL
-:ALL:ALL

Zmieniłem to na następujące i loginy teraz działają; Nie musiałem nawet restartować żadnych usług.

+:jenkins:ALL
+:root:ALL
-:ALL:ALL

Miał ten sam komunikat o błędzie. Wyłączono sshd i uruchomiłem go ponownie w trybie debugowania

    /usr/sbin/sshd -ddd

wskazało to powód:

    debug3: User autossh not allowed because account is locked
            ...
    input_userauth_request: invalid user <username> [preauth]

Konto sprawdzone:

    passwd -S <username>

co pokazało, że konto zostało zablokowane (flaga „L”) Odblokuj konto, ustawiając nowe hasło:

    passwd <username>

Gotowy.

Mam ten sam problem dziś rano, ale serwer uwierzytelnia użytkowników względem Active Directory. Okazuje się, że hasło domeny użytkownika wygasło.

W moim przypadku zmieniałem nazwy lokalnych użytkowników CentOS 6 i zapomniałem zmienić ich nazwę w / etc / shadow (którzy są uwierzytelnieni bez klucza, nie pojawili się w mojej głowie), więc zapisy dla nowych nazw użytkowników były po prostu nieobecny w / etc / shadow. W / var / log / secure dawał mi błąd unix_chkpwd, a PAM odmówił dostępu:

    unix_chkpwd[12345]: could not obtain user info (user2)
    sshd[12354]: fatal: Access denied for user user2 by PAM account configuration

W moim przypadku było to uderzanie śmieciami / etc / tcb / USER / shadow po uszkodzeniu rootfsa ext4 w „interesujących” warunkach; wyglądał dość tekstylnie, więc nie został zauważony podczas wstępnego badania (nie można teraz ponownie zainstalować węzła, ale będzie musiał).

Miałem ten sam problem i żadna z sugerowanych opcji nie działała. Ale na jednym z forów ( https://ubuntuforums.org/showthread.php?t=1960510 ) znalazłem „obejście”, które działało idealnie.

Edytuj /etc/ssh/sshd_configi ustaw

UsePAM no

Chociaż prawdopodobnie nie jest to prawdziwe rozwiązanie, ponieważ coś jest zdecydowanie nie tak z moją maszyną (wczoraj działało dobrze!), Ta przynajmniej działa.