it-swarm.com.de

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

Auf einer VM Ich initialisiere) kann ich mich als ein Nicht-Root-Benutzer (admin) anmelden, aber nicht als ein anderer (tbbscraper) über SSH mit public Schlüsselauthentifizierung. 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 Client-Seite ist das Syndrom

$ ssh -v -i [REDACTED] [email protected][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: debug1: Authentication succeeded (publickey). wird 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 Problem mit der Zugriffskontrolle auf PAM-Ebene ...

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

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

[email protected][REDACTED] # su - admin
[email protected][REDACTED] $

aber

[email protected][REDACTED] # su - tbbscraper
su: Authentication failure
(Ignored)
[email protected][REDACTED] $

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

Das VM ist eine EC2-Instanz, das Betriebssystem ist Debian 7.1 (Amazon's Standard-AMI).

24
zwol

Nach all dem stellt sich heraus, dass es sich bei /etc/shadow Um einen Tippfehler mit einem Zeichen handelt. Erkenne den Unterschied:

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

Richtig, nach dem Ausrufezeichen in der Zeile tbbscraper befinden sich zwei Doppelpunkte. Dadurch werden alle Felder über ein Feld verschoben, und PAM geht davon aus, dass das Konto am 8. Januar 1970 abgelaufen ist.

30
zwol

Vielen Dank, dass Sie Ihre Frage gestellt haben. Ich habe den gleichen Fehler erhalten, aber mein Problem hing nicht mit der Schattendatei zusammen. Ich habe mein Update gefunden und wollte auch eine Antwort für alle anderen veröffentlichen, die diesen Fehler googeln. Diese Serverfehlerfrage wird zuerst gestellt.

Überprüfen Sie den /etc/security/access.conf!

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

+:root:ALL
-:ALL:ALL

Ich habe es wie folgt geändert und die Anmeldungen funktionieren jetzt. Ich musste nicht einmal irgendwelche Dienste neu starten.

+:jenkins:ALL
+:root:ALL
-:ALL:ALL
8
BoomShadow

Hatte die gleiche Fehlermeldung. Sshd wurde heruntergefahren und im Debug-Modus neu gestartet

    /usr/sbin/sshd -ddd

dies gab den Grund an:

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

Überprüftes Konto:

    passwd -S <username>

dies zeigte, dass das Konto gesperrt war (Flag "L"). Deaktivierte das Konto durch Festlegen eines neuen Passworts:

    passwd <username>

Erledigt.

3
MarkHelms

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

2
Ab_Ro

In meinem Fall habe ich lokale CentOS 6-Benutzer umbenannt und vergessen, sie in/etc/shadow umzubenennen (die ohne Kennwort authentifiziert sind und nicht in meinem Kopf aufgetaucht sind), sodass die Datensätze für die neuen Benutzernamen gerecht waren fehlt in/etc/shadow. In/var/log/Secure gab es mir den Fehler unix_chkpwd und den von PAM verweigerten Zugriff:

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

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

Bearbeiten /etc/ssh/sshd_config und setzen

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.

0
The Godfather

In meinem Fall war es Junk, der ''/etc/tcb/USER/shadow '' nach der Korruption von ext4 rootfs unter "interessanten" Bedingungen traf; Es sah ziemlich textig aus und wurde bei der ersten Untersuchung nicht entdeckt (kann den Knoten momentan nicht neu installieren, muss es aber).

0