ssh: "Zugriff durch PAM-Kontokonfiguration verweigert" für einen Nicht-Root-Benutzer, aber keinen anderen

Auf einer VM, die ich initialisiere, kann ich mich als ein Benutzer ohne Rootberechtigung ( admin), aber nicht als ein anderer Benutzer ( tbbscraper) über SSH mit öffentlicher Schlüsselauthentifizierung anmelden . Die einzige Fehlermeldung, die ich in einer Protokolldatei finden kann, ist

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

Auf der Clientseite ist das Syndrom

$ 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]

Das Ändern von 'tbbscraper' in 'admin' ermöglicht eine erfolgreiche Anmeldung: wird debug1: Authentication succeeded (publickey).anstelle der Meldung "Verbindung geschlossen" angezeigt.

Dies scheint kein Berechtigungsproblem zu sein ...

# 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

... noch ein Zugriffskontrollproblem auf PAM-Ebene ...

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

... so scheint keine der vorhandenen Antworten auf ähnliche Fragen zuzutreffen. Der einzige andere Beweis, den ich habe, ist:

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

aber

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

Das deutet auf ein größeres PAM-Problem hin, aber ich kann an den Inhalten offensichtlich nichts Falsches finden /etc/pam.d. Irgendwelche Ideen?

Die VM ist eine EC2-Instanz, das Betriebssystem ist Debian 7.1 (AMI von Amazon).

Nach all dem stellt sich heraus, dass es sich um einen Ein-Zeichen-Tippfehler handelte /etc/shadow. Finde den Unterschied:

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

Das ist richtig, es gibt zwei Doppelpunkte nach dem Ausrufezeichen auf der tbbscraperLinie. Das verschiebt alle Felder um eins und lässt PAM glauben, dass der Account am 8. Januar 1970 abgelaufen ist.

Vielen Dank, dass Sie Ihre Frage gestellt haben. Ich habe den gleichen Fehler erhalten, aber mein Problem hing nicht mit der Schattendatei zusammen. Ich fand mein Update und wollte eine Antwort auch für jedermann bekanntgeben, das diesen Fehler googelt. Diese Serverfehlerfrage wird zuerst gestellt.

Probieren Sie das /etc/security/access.conf!

Wir verwenden Active Directory zur Authentifizierung, aber ich musste mich als lokaler Nicht-AD-Benutzer (Jenkins) anmelden. Mein Chef hatte die Box ursprünglich mit dieser Zeile in der eingerichtet /etc/security/access.conf:

+:root:ALL
-:ALL:ALL

Ich habe es folgendermaßen geändert und die Anmeldungen funktionieren jetzt. Ich musste nicht einmal irgendwelche Dienste neu starten.

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

Hatte die selbe Fehlermeldung. Fahren Sie den sshd herunter und starten Sie ihn im Debug-Modus neu

    /usr/sbin/sshd -ddd

dies deutete auf den Grund hin:

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

Überprüftes Konto:

    passwd -S <username>

was zeigte, dass das Konto gesperrt war (Flag "L") Entsperrung des Kontos durch Setzen eines neuen Passworts:

    passwd <username>

Getan.

Ich habe heute Morgen das gleiche Problem, aber der Server authentifiziert Benutzer anhand von Active Directory. Es stellte sich heraus, dass das Domänenkennwort des Benutzers abgelaufen war.

In meinem Fall habe ich lokale CentOS 6-Benutzer umbenannt und vergessen, sie in / etc / shadow umzubenennen (die ohne Passwort authentifiziert wurden und nicht in meinem Kopf auftauchten). Die Datensätze für die neuen Benutzernamen waren also einfach abwesend in / etc / shadow. In / var / log / secure gab es mir unix_chkpwd Fehler und Zugriff verweigert von PAM:

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

In meinem Fall war es Junk, der '' / etc / tcb / USER / shadow '' traf, nachdem ext4 rootfs unter "interessanten" Bedingungen beschädigt wurde. Es sah ziemlich textreich aus und wurde bei der Erstuntersuchung nicht entdeckt (der Knoten kann jetzt nicht neu installiert werden, muss aber).

Ich hatte das gleiche Problem und keine der vorgeschlagenen Optionen hat funktioniert. Aber ich habe in einem der Foren ( https://ubuntuforums.org/showthread.php?t=1960510 ) eine "Problemumgehung" gefunden, die perfekt funktioniert hat.

Bearbeiten /etc/ssh/sshd_configund einstellen

UsePAM no

Während es wahrscheinlich nicht die wirkliche Lösung ist, weil definitiv etwas mit meiner Maschine nicht stimmt (gestern hat es gut funktioniert!), Funktioniert diese zumindest.