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).
źródło
/etc/pam.d/sshd
proszęOdpowiedzi:
Po tym wszystkim okazuje się, że jest to literówka jednoznakowa
/etc/shadow
. Zauważyć różnicę:Zgadza się, za wykrzyknikiem na
tbbscraper
linii są dwa dwukropki . To przenosi wszystkie pola nad jednym i sprawia, że PAM myśli, że konto wygasło 8 stycznia 1970 r.źródło
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
:Zmieniłem to na następujące i loginy teraz działają; Nie musiałem nawet restartować żadnych usług.
źródło
Miał ten sam komunikat o błędzie. Wyłączono sshd i uruchomiłem go ponownie w trybie debugowania
wskazało to powód:
Konto sprawdzone:
co pokazało, że konto zostało zablokowane (flaga „L”) Odblokuj konto, ustawiając nowe hasło:
Gotowy.
źródło
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.
źródł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:
źródło
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ł).
źródło
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_config
i ustawChociaż 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.
źródło