web-dev-qa-db-fra.com

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

Nous avons un script batch Windows, qui se connecte automatiquement à un serveur Linux via PLINK (PuTTY). Il n'y a AUCUNE authentification par 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?
"pré-autorisation" signifie probablement "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 connaît-il la différence entre l'adresse IP du client et l'adresse IP de l'hôte dans le message?

sshlogsauthentication
58
Wolfgang Adamec

Le serveur sshd se déconnectera si le client n'essaie pas de s'authentifier dans un certain laps de temps, comme indiqué dans le -g option.

 -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 soupçonne 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 ne s'est produite dans 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.

25
oeuftete

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

9
pcronin

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 était un montage NFS et que selinux (sur CentOS 7) lançait des erreurs (qui étaient assez difficiles à localiser). La solution était cependant simple.

setsebool -P use_nfs_home_dirs 1
5
Simon

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

4
x-yuri

Une source de ces messages est https://sshcheck.com/ qui affiche une faiblesse possible sur votre serveur ssh.

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

3
Daniel F

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

Et alors:

Sudo service sshd restart
2
matt

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

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

Parce que le paquet ping a été reçu par le client mais n'est pas retourné à l'hôte ansible.

0
VictorLee

Dans mon cas, il y a eu une attaque DoS sur ma machine. Le serveur a atteint la limite de fichiers ouverts simultanément et n'a pas pu ouvrir authorized_keys fichier pour vérifier mon identité.

VFS: file-max limit XXXXX reached des messages dans dmesg sont apparus informant du problème après avoir finalement réussi à me connecter.

0
DevilaN