ssh: «Accès refusé par la configuration du compte PAM» pour un utilisateur non root mais pas pour un autre

Sur une machine virtuelle que j'initialise, je peux me connecter en tant qu'un utilisateur non root ( admin) mais pas un autre ( tbbscraper) via SSH avec authentification par clé publique. Le seul message d'erreur que je peux trouver dans n'importe quel fichier journal est

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

Côté client, le syndrome est

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

Changer 'tbbscraper' en 'admin' permet une connexion réussie: debug1: Authentication succeeded (publickey).apparaît à la place du message "Connexion fermée".

Cela ne semble pas être un problème d'autorisations ...

# 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

... ni un problème de contrôle d'accès au niveau PAM ...

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

... donc aucune des réponses existantes à des questions similaires ne semble s'appliquer. Le seul autre élément de preuve que j'ai, c'est:

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

mais

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

ce qui suggère un problème PAM à plus grande échelle, mais je ne trouve rien de mal à l'évidence /etc/pam.d. Des idées?

La machine virtuelle est une instance EC2, le système d'exploitation est Debian 7.1 (AMI standard d'Amazon).

Après tout cela, il s'est avéré qu'il s'agissait d'une faute de frappe à un caractère /etc/shadow. Trouvez la différence:

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

C'est vrai, il y a deux deux points après le point d'exclamation sur la tbbscraperligne. Cela pousse tous les champs sur un et fait penser à PAM que le compte a expiré le 8 janvier 1970.

Merci d'avoir posté votre question. J'obtenais la même erreur, mais mon problème n'était pas lié au fichier caché. J'ai trouvé mon correctif et je voulais également publier une réponse pour quiconque googler cette erreur. Cette question de défaillance du serveur apparaît en premier.

Essayez de vérifier le /etc/security/access.conf!

Nous utilisons Active Directory pour l'authentification, mais je devais me connecter en tant qu'utilisateur local non AD (jenkins). Mon patron avait initialement configuré la boîte avec ces lignes dans /etc/security/access.conf:

+:root:ALL
-:ALL:ALL

Je l'ai changé comme suit et les connexions fonctionnent maintenant; Je n'avais même pas besoin de redémarrer de services.

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

Eu le même message d'erreur. Arrêt du sshd et redémarrage en mode débogage

    /usr/sbin/sshd -ddd

cela a indiqué la raison:

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

Compte vérifié:

    passwd -S <username>

qui a montré que le compte était verrouillé (drapeau "L") Déverrouillé le compte en définissant un nouveau mot de passe:

    passwd <username>

Terminé.

J'ai eu le même problème ce matin, mais le serveur authentifie les utilisateurs par rapport à Active Directory. Il s'avère que le mot de passe du domaine de l'utilisateur a expiré.

Dans mon cas, je renommais les utilisateurs locaux de CentOS 6, et j'ai oublié de les renommer dans / etc / shadow (qui sont authentifiés par mot de passe sans clé, ne s'affichaient pas dans mon esprit), donc les enregistrements pour les nouveaux noms d'utilisateur étaient juste absent dans / etc / shadow. Dans / var / log / secure, cela me donnait une erreur unix_chkpwd et un accès refusé par PAM:

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

Dans mon cas, il s'agissait de fichiers indésirables "/ etc / tcb / USER / shadow" 'après une corruption de rootfs ext4 dans des conditions "intéressantes"; il avait l'air assez texturé et n'a donc pas été repéré lors de l'examen initial (ne peut pas réinstaller le nœud pour le moment mais devra le faire).

J'ai eu le même problème et aucune des options suggérées n'a fonctionné. Mais j'ai trouvé dans l'un des forums ( https://ubuntuforums.org/showthread.php?t=1960510 ) une "solution de contournement" qui fonctionnait parfaitement.

Modifier /etc/ssh/sshd_configet définir

UsePAM no

Bien que ce ne soit probablement pas la vraie solution, car quelque chose ne va vraiment pas avec ma machine (hier, elle fonctionnait bien!), Celle-ci fonctionne au moins.