Signification de «Connexion fermée par xxx [preauth]» dans les journaux sshd

55

Nous avons un script batch de Windows, qui se connecte automatiquement à un serveur linux via PLINK (mastic). Il n'y a PAS d'authentification de clé privée publique, l'utilisateur et le mot de passe sont dans le script.

Sur notre serveur Linux, nous avons plusieurs entrées de journal sshd (/ var / log / messages):

sshd[7645]: Connection closed by xxx [preauth]

Quelle pourrait être la cause d'un tel message?
"preauth" signifie "pré-authentification"?

Parfois, dans l'entrée, "fermé par" a l'adresse IP du client Windows, une autre fois il y a l'adresse IP du serveur Linux dans "fermé par". Quelqu'un sait-il la différence entre l'adresse IP du client et l'adresse IP de l'hôte dans le message?

ssh logs authentication Wolfgang Adamec
la source
Quand on l' observe dans /usr/local/sbin/sshd -D -e, solution de contournement possible: serverfault.com/a/211176
Ivan Chau
J'éprouve le même problème et dans mon cas, je l'ai réduit au fait que la même clé fonctionne à partir d'un shell Ubuntu sur un véritable Ubuntu s'exécutant en tant que machine virtuelle et non à partir de l'Ubuntu intégré à Windows 10 (AKA Windows Linux Subsystem). . Je ne comprends pas encore pourquoi, mais peut-être que cela aide toujours quelqu'un
Jens Kisters
Vérifiez /var/log/secureavec LogLevel DEBUG3en/etc/ssh/sshd_config
Ivan Chau

Réponses:

24

Le sshdserveur se déconnectera si le client n'essaie pas de s'authentifier dans un certain délai, comme indiqué dans l' -goption.

 -g login_grace_time
         Gives the grace time for clients to authenticate themselves
         (default 120 seconds).  If the client fails to authenticate
         the user within this many seconds, the server disconnects
         and exits.  A value of zero indicates no limit.

Je suppose donc que si vous voyez l’IP du serveur dans les journaux avec ce message, la connexion a été fermée car aucune tentative d’authentification n’a eu lieu pendant ce délai de grâce. Lorsque vous voyez l'IP du client, cela signifie que l'utilisateur a fermé son client (ou le script s'est terminé) sans faire de tentative d'authentification.

oeuftete
la source
Peut-il être causé par exemple par le balayage nmap?
Qback
Ce sont généralement des tentatives de piratage. Je vois beaucoup de Chine, Russie, Japon, etc.
jjxtra
4
Si l'adresse IP dans le message est l'adresse IP du client, cela peut indiquer que le client tente de s'authentifier avec une phrase secrète incorrecte pour sa clé privée. Leur client ne parvient alors pas à décoder la clé et se déconnecte sans tentative d'authentification.
Code Commander
8

Dans mon cas, ces messages sont apparus dans / var / log / secure lorsque je rencontrais des Host key verification failed.erreurs du côté du client ssh. C’est l’un des cas qui aboutirait à une connexion sans tentative de connexion.

pcronine
la source
5

J'ai eu un problème très similaire au vôtre (bien que j'utilisais une clé publique).

Il s’avère que mon problème, et peut-être le vôtre, est dû au fait que mon répertoire personnel est un montage NFS et que selinux (sur CentOS 7) génère des erreurs (assez difficiles à détecter). La solution était simple cependant.

setsebool -P use_nfs_home_dirs 1
Simon
la source
3

Une autre source de ce type de messages est ssh-keyscan. Il saisit simplement les clés de l'hôte du serveur et se déconnecte sans aucune authentification.

x-yuri
la source
3

Une des sources de ces messages est https://sshcheck.com/, qui affiche les faiblesses possibles sur votre serveur ssh.

Cela provoque environ 4 de ces messages de manière séquentielle.

Daniel F
la source
2

J'ai eu le même problème, je l'ai résolu comme ceci:

Sur le serveur SSH, j'ai commenté et mis à Oui les valeurs suivantes dans / etc / ssh / sshd_config

 RSAAuthentication yes
 PubkeyAuthentication yes

Puis:

sudo service sshd restart
mat
la source
0

J'ai rencontré la même situation, à cause de la iptablesrègle INPUT était DROP, mais ACCEPTER l'hôte ansible, mais il n'y a pas de règleiptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Le journal des erreurs a "Nov 3 01:34:50 debian sshd[29378]: Connection closed by 10.17.64.13 [preauth]"été écrit "/var/log/auth.log"sur l'ordinateur client après ansible all -m pingl'exécution de la commande sur l'hôte ansible.

Parce que le paquet ping avait été reçu par le client mais ne revenait pas à l'hôte ansible.

VictorLee
la source