Chaque connection SSH AD commence par un échec dans audit.log

Chaque fois que je me connecte à mon server Centos 7.x, j'obtiens toujours un échec transparent dans le file audit.log. Cela rend mes tentatives d'avoir un script quotidien pour les connections échouées très difficile car nous ne pouvons pas être sûr de ce qui est un véritable échec. Voici un extrait d' aureport -au -ts today

 1669. 06/02/17 08:40:03 handsm@internal 10.1.0.24 ssh /usr/sbin/sshd no 1428242 1670. 06/02/17 08:40:03 handsm@internal 10.1.0.24 ssh /usr/sbin/sshd no 1428243 1671. 06/02/17 08:40:06 handsm@internal server01 ssh /usr/sbin/sshd yes 1428244 1672. 06/02/17 08:40:06 handsm@internal 10.1.0.24 ssh /usr/sbin/sshd yes 1428246 1673. 06/02/17 08:40:13 [email protected] ? /dev/pts/3 /usr/bin/sudo yes 1428284

Vous pouvez voir les 2 premières lignes sont des échecs puis j'obtiens un succès immédiat. Quelqu'un a-t-il une idée de ce qui peut arriver?

Edit_1: Fichiers journaux SSH verbeux inclus:

Feb 6 09:59:42 wb-prod-ctl sshd[50489]: Connection from 10.1.0.24 port 58847 on 192.168.61.5 port 22 Feb 6 09:59:45 wb-prod-ctl sshd[50489]: Failed publickey for handsm@internal from 10.1.0.24 port 58847 ssh2: RSA c4:a3:e9:ad:2f:5c:fa:b4:de:49:6a:7d:83:fa:11:d5 Feb 6 09:59:45 wb-prod-ctl sshd[50489]: Postponed gssapi-with-mic for handsm@internal from 10.1.0.24 port 58847 ssh2 [preauth] Feb 6 09:59:46 wb-prod-ctl sshd[50489]: Failed gssapi-with-mic for handsm@internal from 10.1.0.24 port 58847 ssh2 Feb 6 09:59:48 wb-prod-ctl sshd[50489]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=server01.internal.office user=handsm@internal Feb 6 09:59:48 wb-prod-ctl sshd[50489]: Accepted password for handsm@regsec from 10.1.0.24 port 58847 ssh2 Feb 6 09:59:48 wb-prod-ctl sshd[50489]: pam_unix(sshd:session): session opened for user handsm@internal by (uid=0) Feb 6 09:59:48 wb-prod-ctl sshd[50489]: User child is on pid 50492 Feb 6 09:59:48 wb-prod-ctl sshd[50492]: Starting session: shell on pts/3 for [email protected] from 10.1.0.24 port 58847

On dirait un échec avec gssapi-avec-mic ??

Edit_2: J'ai désactivé GSSAPIAuthentication maintenant sans effet néfaste et l'erreur dans mes logs SSH pour gssapi-with-mic est allé …… cependant (!), Je rest avec l'erreur Failed publickey .

Donc, mon server autorise à la fois les connections AD (uid + mot de passe) et les connections sans mot de passe (keys publiques / privées). Je pense que mon problème est le fait même, et je ne pourrais pas être en mesure de le résoudre, c'est-à-dire que SSH attend l'une ou l'autre méthode et si l'une n'est pas utilisée, l'autre écrit une erreur dans le journal.

Est-ce que quelqu'un d'autre a l'expérience de cela?

Edit_3 : Problème résolu – merci à Liczyrzrepa .

Il semble donc que les parameters par défaut de Putty soient "Tentative d'authentification en utilisant Pageant" (voir l'image ci-dessous). Lorsque j'ai créé une nouvelle session Putty sur le server en question et désactivé ce paramètre, je ne vois plus l'erreur Failed publickey . Jours heureux! J'espère que cela aide les autres.

entrer la description de l'image ici

Par défaut, le client OpenSSH tentera l'authentification par key publique si vous avez déjà créé des keys. Ma conjecture est que si vous faites ls ${HOME}/.ssh/ vous verrez une paire de keys – id_rsa et id_rsa.pub . Lorsque votre client se connecte au server, il tente d'utiliser cette paire de keys pour se connecter. Parce que id_rsa.pub n'est pas dans ${HOME}/.ssh/authorized_keys sur votre server, ou que ce file a des permissions incorrectes, sshd sur le server marque correctement cette tentative de connection comme ayant échoué. Essayez ce qui suit:

 ssh -o PubkeyAuthentication=no

La définition de cette option empêchera le client SSH d'utiliser des keys dans ${HOME}/.ssh/ lors de la tentative d'authentification sur le server. Si cela ne permet pas aux messages du journal de s'afficher, ajoutez -vv aux options du client ssh afin que nous puissions voir exactement ce qu'il en est.