SSH: Verbindungsrücksetzung durch Peer

Ich habe einen Solaris 10-Server in einem anderen Netzwerk. Ich kann es anpingen und telneten, aber ssh stellt keine Verbindung her. Das PuTTY-Protokoll enthält nichts Interessantes (beide verhandeln mit ssh v2) und dann bekomme ich

"Event Log: Network error: Software caused connection abort".

ssh läuft definitiv:

svcs -a | grep ssh
online         12:12:04 svc:/network/ssh:default

Hier ist ein Auszug aus den / var / adm / messages des Servers (anonymisiert)

Jun  8 19:51:05 ******* sshd[26391]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer

Wenn ich mich jedoch mit der Box telnete, kann ich mich lokal bei ssh anmelden. Ich kann auch auf andere (Nicht-Solaris-) Computer in diesem Netzwerk zugreifen, sodass ich nicht glaube, dass es sich um ein Netzwerkproblem handelt (obwohl ich nicht sicher bin, da ich ein paar hundert Meilen entfernt bin).

Die Firewall des Servers ist deaktiviert, sodass dies kein Problem darstellen sollte

root@******** # svcs -a | grep -i ipf
disabled       Apr_27   svc:/network/ipfilter:default

Irgendwelche Ideen, was ich überprüfen soll?

Update: Aufgrund des folgenden Feedbacks habe ich sshd im Debug-Modus ausgeführt. Hier ist die Client-Ausgabe:

$ ssh -vvv root@machine -p 32222
OpenSSH_5.0p1, OpenSSL 0.9.8h 28 May 2008
debug2: ssh_connect: needpriv 0
debug1: Connecting to machine [X.X.X.X] port 32222.
debug1: Connection established.
debug1: identity file /home/lawrencj/.ssh/identity type -1
debug1: identity file /home/lawrencj/.ssh/id_rsa type -1
debug1: identity file /home/lawrencj/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
debug1: no match: Sun_SSH_1.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

Und hier ist die Serverausgabe:

root@machine # /usr/lib/ssh/sshd -d -p 32222
debug1: sshd version Sun_SSH_1.1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 32222 on ::.
Server listening on :: port 32222.
debug1: Bind to port 32222 on 0.0.0.0.
Server listening on 0.0.0.0 port 32222.
debug1: Server will not fork when running in debugging mode.
Connection from 1.2.3.4 port 2652
debug1: Client protocol version 2.0; client software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
debug1: Calling cleanup 0x4584c(0x0)

Diese Linie scheint ein wahrscheinlicher Kandidat zu sein:

debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible

Überprüfen Sie Ihre .ssh / autorisierte_keys-Datei auf dem Server, wenn Sie die schlüsselbasierte Authentifizierung verwenden. Ich hatte das gleiche Problem, und die Person, die den Zugriff eingerichtet hatte, hatte den Schlüssel mit Zeilenumbrüchen eingefügt. Durch Entfernen der Zeilenumbrüche wurde das Problem behoben. Sie können dies jedoch testen, indem Sie die Datei "authorized_keys" aus dem Weg räumen oder die Kennwortauthentifizierung auswählen zuerst und sehen, ob Sie das gleiche Problem bekommen:

ssh -o PreferredAuthentications=password username@hostname

Versuchen Sie, GSSAPI vollständig zu deaktivieren:

GSSAPIAuthentication no

Sind Sie in der Liste der erlaubten Benutzer in sshd_conf?

Möglicherweise können Sie weitere nützliche Debugging-Informationen abrufen, indem Sie sshddas -dFlag ausführen (und möglicherweise das -pFlag, um einen anderen Port anzugeben, wenn Sie das Original ausführen möchten sshd) und dann mit Ihrem ssh -vClient eine Verbindung herstellen.

Update: Es sieht so aus, als ob Ihr Problem eher mit dem Netzwerk als mit der Authentifizierung zusammenhängt. Sie können sehen, dass auf beiden Seiten des Gesprächs die Verbindung zurückgesetzt wurde. Sie können sich beim zuständigen Netzwerkteam erkundigen, ob ein Zwischennetzwerkknoten (z. B. eine Firewall) das Problem verursacht.

Das ist interessant, ich habe das gleiche Problem. Nur ich kann ssh aus dem lokalen Netzwerk, aber nicht bei Verwendung von VPN.

11. Mai 18:03:10 Servername sshd [14733]: [ID 800047 auth.crit] schwerwiegend: Lesen vom Socket fehlgeschlagen: Verbindung durch Peer zurückgesetzt

Ich werde nie zu einem pw aufgefordert. Die Sitzungen sterben zu schnell.

Ich habe vermutet, dass etwas mit Problemen beim Schlüsselaustausch zu tun hat, da Sie sagen, dass SSHv2 ausgehandelt wird.

Konnte noch keine gute Beschreibung dazu finden; Es gibt jedoch diese eine PuTTY-Referenz .

Sie sollten eine Paketerfassung auf dem Server versuchen, um festzustellen, wo die SSH-Kommunikation stoppt.

Sie können auch versuchen, " ssh -v" zu sehen, welche Fehler der Client sieht.

Dies ist 99% der Zeit, die durch TCP-Wrapper (hosts.deny) verursacht wird. Sie müssen dort wahrscheinlich Ihre IP-Adresse zulassen:

/etc/hosts.deny

Der Grund, warum es von localhost aus funktioniert, ist, dass 127.0.0.1 dort wahrscheinlich zulässig ist (oder über /etc/hosts.allow).

Ihr sshd gibt an, die Verbindung zu handhaben (auch beim Debuggen). Mir scheint, das Kind stirbt stillschweigend, sobald es mit den Authentifizierungsmechanismen des Systems interagieren will. Dies ist ungefähr die Zeit, in der normalerweise nach UID, GID gesucht und PAM ausgeführt wird. Verwendet Ihr Server LDAP oder NIS +?

Es ist am besten, das Debug auf einem ordnungsgemäß funktionierenden Server auszuführen und zu sehen, was als nächstes kommen soll (verwenden Sie vimdiff oder diff).

Ich habe kürzlich ein sehr ähnliches Problem, als eine Gruppe zu viele Mitglieder hatte (die Länge aller Mitglieder betrug ungefähr 500-600 Zeichen). Obwohl das unter Linux war.

Wenn Sie den Server für das Debuggen ausführen, geben Sie -ddd (Triple Debug) an, um weitere Informationen zu erhalten.

Sie sagen, dass sich der Zielhost in einem anderen Netzwerk befindet. Und dass die 'Server-Firewall deaktiviert ist'.

Befindet sich zwischen Ihrem Netzwerk und dem Zielnetzwerk eine Firewall oder ein Paketfiltergerät?

Es lohnt sich, eine Traceroute durchzuführen, um zu sehen, was sich zwischen den beiden Netzwerken befindet.

Stellen Sie außerdem sicher, dass Sie während der Übertragung keine Pakete verlieren. Ein einfacher Test mit Ping kann Ihnen helfen, herauszufinden, ob Sie Netzwerkprobleme haben.

In meinem Fall hat mir das Durchsuchen von / var / log / messages gezeigt, dass zu viele Sitzungen geöffnet waren (begrenzt durch PAM): 21. August 18:05:43 nv20 pam_limits [13325]: Zu viele Anmeldungen (max. 20) für Benutzer

Ein paar Strg-D's später und ssh arbeitete wieder ...

Ich habe gerade ein ähnliches Problem mit demselben Symptom behoben: getrennt nach:

debug1: SSH2_MSG_KEXINIT sent.

Ausführen des SSH-Servers an zwei Ports, 22 und 'einem anderen nicht genannten Port'. Ich könnte eine Verbindung über Port 22 herstellen, aber nicht über den anderen Port mit der oben genannten plötzlichen Trennung vor dem Austausch des Hostschlüssels.

Es stellte sich heraus, dass sshd für Port 22 als root ausgeführt wurde, während sshd für den anderen Port als Benutzer ubuntu ausgeführt wurde . Offensichtlich kann der Ubuntu-Benutzer den privaten Hostschlüssel nicht lesen, wie in /var/log/auth.log gezeigt :

error: Could not load host key: /etc/ssh/ssh_host_rsa_key
error: Could not load host key: /etc/ssh/ssh_host_dsa_key
fatal: No supported key exchange algorithms

Der Befehl 'sudo netstat -nap | grep ssh 'hat 2 verschiedene Prozesse für Port 22 und den anderen Port (bearbeitet) zurückgegeben:

$ sudo netstat -nap | grep ssh
tcp        0      0 0.0.0.0:other port      0.0.0.0:*               LISTEN      17620/sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      31160/sshd
tcp6       0      0 :::other port           :::*                    LISTEN      17620/sshd
tcp6       0      0 :::22                   :::*                    LISTEN      31160/sshd

Zeigt an, dass der SSH-Server an Port 22 den Prozess Nr. 31160 verwendet, während der andere Port den Port Nr. 17620 verwendet .

Und 'ps -eaf | grep ssh 'zeigte, dass ein Prozess als root ausgeführt wurde, während der andere als ubuntu (bearbeitet) ausgeführt wurde:

$ ps -eaf | grep ssh
ubuntu   17620     1  0 Apr25 ?        00:00:00 /usr/sbin/sshd
root     31160     1  0 08:35 ?        00:00:00 /usr/sbin/sshd

Um das Problem zu lösen, musste ich den als Ubuntu ausgeführten Prozess ( kill 17620 ) beenden und den SSH-Server mit dem Befehl 'sudo /etc/init.d/ssh restart' neu starten .

Ich weiß nicht genau, wie das passiert ist, aber nachdem ich versucht hatte, das Problem zu reproduzieren, stellte ich fest, dass ich möglicherweise versucht habe, sshd neu zu starten, ohne root zu sein. Es funktioniert, aber der neue Port wird vom Ubuntu-Benutzer gehostet:

$ /etc/init.d/ssh restart
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
 * Restarting OpenBSD Secure Shell server sshd
start-stop-daemon: warning: failed to kill 31884: Operation not permitted
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key

Wenn ich das getan habe, wurde ich gebissen, weil ich diese Fehlermeldungen ignoriert habe. Dies kann jedoch als Fehler angesehen werden, da der Server nicht mehr ordnungsgemäß neu gestartet werden kann, ohne das Ubuntu-laufende SSHD zu beenden.

Für diejenigen, die sich fragen, verwende ich einen anderen Port anstelle von Port 22, um die meisten Verbindungsversuche an Port 22 auf allen meinen Servern zu verhindern, und blockiere dann Port 22 mithilfe einer Firewall. Dies ist einfach, funktioniert aber und ermöglicht mir, von jeder IP-Adresse aus eine Verbindung herzustellen.

Dieses Problem kann gelöst werden, indem die folgenden 2 Befehle an der Konsolen- / Terminal-Eingabeaufforderung auf dem Computer ausgeführt werden, auf die Putty nicht zugreifen kann:

$ sudo apt-get --purge entfernen openssh-server
$ sudo apt-get installiere openssh-server

Der erste Befehl deinstalliert den openssh-Server mithilfe von purge vollständig, im Gegensatz zu autoremove, wodurch Konfigurationsdateien zurückbleiben. Mit dem zweiten Befehl wird der opnessh-Server neu installiert

Versuchen Sie nun erneut, in die Maschine zu schieben.