Bedeutung von "Verbindung durch xxx [preauth] geschlossen" in sshd-Protokollen

54

Wir haben ein Windows-Batch-Skript, das sich automatisch über PLINK (Putty) mit einem Linux-Server verbindet. Es gibt KEINE Authentifizierung mit einem öffentlichen privaten Schlüssel, der Benutzer und das Kennwort befinden sich im Skript.

Auf unserem Linux-Server haben wir mehrere sshd-Protokolleinträge (/ var / log / messages):

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

Was könnte die Ursache für eine solche Nachricht sein?
"Vorauthentifizierung" bedeutet vermutlich "Vorauthentifizierung"?

Manchmal steht im Eintrag "closed by" die IP-Adresse des Windows-Clients, ein anderes Mal steht die IP-Adresse des Linux-Servers unter "closed by". Kennt jemand die Unterschiede zwischen Client-IP-Adresse und Host-IP-Adresse in der Nachricht?

ssh logs authentication

— Wolfgang Adamec
quelle

Wenn beobachtet /usr/local/sbin/sshd -D -e, mögliche Abhilfe: serverfault.com/a/211176

— Ivan Chau

Ich habe das gleiche Problem und in meinem Fall habe ich es auf die Tatsache eingegrenzt, dass derselbe Schlüssel von einer Ubuntu-Shell auf einem echten Ubuntu als VM ausgeführt wird und nicht von dem in Windows 10 eingebetteten Ubuntu (AKA Windows Linux Subsystem). . Ich habe noch nicht herausgefunden warum, aber vielleicht hilft das immer noch jemandem

— Jens Kisters

Prüfen Sie /var/log/securemit LogLevel DEBUG3in/etc/ssh/sshd_config

— Ivan Chau

24

Der sshdServer wird die Verbindung trennen, wenn der Client in einem bestimmten Zeitraum nicht versucht, sich zu authentifizieren, wie in der -gOption dokumentiert .

 -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.

Ich vermute also, wenn Sie die Server-IP in den Protokollen mit dieser Meldung sehen, wurde die Verbindung geschlossen, da innerhalb dieser Kulanzzeit kein Authentifizierungsversuch aufgetreten ist. Wenn Sie die Client-IP sehen, bedeutet dies, dass der Benutzer seinen Client geschlossen hat (oder das Skript beendet wurde), ohne einen Authentifizierungsversuch durchzuführen.

— oeuftete
quelle

Kann es zB durch nmap-Scannen verursacht werden?

— Qback

Dies ist in der Regel Hackversuche. Ich sehe viel aus China, Russland, Japan, etc.

— jjxtra

3

Wenn die IP-Adresse in der Nachricht die IP-Adresse des Clients ist, weist dies möglicherweise darauf hin, dass der Client versucht, sich mit der falschen Passphrase für seinen privaten Schlüssel zu authentifizieren. Der Client kann den Schlüssel dann nicht entschlüsseln und trennt die Verbindung, ohne eine Authentifizierung zu versuchen.

— Code Commander

7

In meinem Fall erschienen diese Meldungen in / var / log / secure, als ich Host key verification failed.auf der Seite des ssh-Clients Fehler bemerkte. Dies ist einer der Fälle, die zu einer Verbindung ohne Anmeldeversuch führen würden.

— Pcronin
quelle

4

Ich hatte ein sehr ähnliches Problem wie Sie (obwohl ich einen öffentlichen Schlüssel verwendet habe).

Es stellte sich heraus, dass mein und möglicherweise Ihr Problem dadurch verursacht wurde, dass mein Ausgangsverzeichnis ein NFS-Mount war und Selinux (unter CentOS 7) einige Fehler verursachte (die nur schwer aufzuspüren waren). Die Lösung war allerdings einfach.

setsebool -P use_nfs_home_dirs 1

— Simon
quelle

2

Eine weitere Quelle für diese Art von Nachrichten ist ssh-keyscan. Es werden lediglich Server-Host-Schlüssel abgerufen und die Verbindung getrennt, ohne dass eine Authentifizierung erfolgt.

— x-yuri
quelle

2

Eine Quelle dieser Nachrichten ist https://sshcheck.com/, die mögliche Schwachstellen auf Ihrem SSH-Server anzeigt.

Es werden nacheinander ca. 4 dieser Meldungen ausgelöst.

— Daniel F
quelle

1

Ich hatte das gleiche Problem, ich habe es so gelöst:

Auf dem SSH-Server habe ich das Kommentarzeichen entfernt und die folgenden Werte in / etc / ssh / sshd_config auf yes gesetzt

 RSAAuthentication yes
 PubkeyAuthentication yes

Und dann:

sudo service sshd restart

— matt
quelle

0

Ich traf die gleiche Situation, weil die iptablesINPUT-Regel DROP war, aber den ansible Host AKZEPTIEREN, aber es gibt nicht die Regeliptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Das Fehlerprotokoll "Nov 3 01:34:50 debian sshd[29378]: Connection closed by 10.17.64.13 [preauth]"wurde "/var/log/auth.log"auf dem Clientcomputer geschrieben, nachdem der Befehl ansible all -m pingauf dem anonymen Host ausgeführt wurde.

Weil das Ping-Paket vom Client empfangen wurde, aber nicht zum anonymen Host zurückkehrte.

— VictorLee
quelle