SSH-Tunnel verweigert Verbindungen mit "Kanal 2: Öffnen fehlgeschlagen"

70

Plötzlich (lesen: ohne Parameter zu ändern) reagierte meine netbsd virtualmachine merkwürdig. Die Symptome betreffen das SSH-Tunneln.

Von meinem Laptop starte ich:

$ ssh -L 7000:localhost:7000 user@host -N -v

Dann in einer anderen Schale:

$ irssi -c localhost -p 7000

Das SSH-Debug lautet:

debug1: Connection to port 7000 forwarding to localhost port 7000 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 7000 for localhost port 7000, connect from 127.0.0.1 port 53954, nchannels 3

Ich habe auch mit localhost: 80 versucht, eine Verbindung zum (entfernten) Webserver herzustellen, mit identischen Ergebnissen.

Auf dem Remote-Host wird NetBSD ausgeführt:

bash-4.2# uname -a
NetBSD host 5.1_STABLE NetBSD 5.1_STABLE (XEN3PAE_DOMU) #6: Fri Nov  4 16:56:31 MET 2011  root@youll-thank-me-later:/m/obj/m/src/sys/arch/i386/compile/XEN3PAE_DOMU i386

Ich bin ein bisschen verloren. Ich habe versucht, tcpdumpauf dem Remote-Host zu laufen , und habe diese "schlechten Chksum" entdeckt:

09:25:55.823849 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 67, bad cksum 0 (->3cb3)!) 127.0.0.1.54381 > 127.0.0.1.7000: P, cksum 0xfe37 (incorrect (-> 0xa801), 1622402406:1622402421(15) ack 1635127887 win 4096 <nop,nop,timestamp 5002727 5002603>

Ich habe versucht, den ssh-Daemon ohne Erfolg neu zu starten. Ich habe noch keinen Neustart durchgeführt. Vielleicht kann hier jemand eine andere Diagnose vorschlagen. Ich denke, es könnte entweder der virtuelle Netzwerkkartentreiber sein, oder jemand hat unser SSH verwurzelt.

Ideen ..?

— Lorenzog
quelle

1

Versuchen Sie es zur Fehlerbehebung $ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v. (Sie können "-v" bis zu dreimal verwenden, um die Ausführlichkeit zu erhöhen.) Ist es auch möglich, dass ssh kürzlich aktualisiert wurde?

— Mike Sherrill 'Cat Recall'

Das von mir eingefügte Ausgabeprotokoll wurde bereits mit -v zusammengestellt.

— Lorenzog

1

Sie können -v bis zu dreimal verwenden, um die Ausführlichkeit zu erhöhen. Sie können sich also die Ausgabe von ssh -L 7000... -N -v -v(zwei vs) oder (zwei vs) ansehen ssh -L 7000... -N -v -v -v.

— Mike Sherrill "Cat Recall"

@ MikeSherrill'CatRecall 'Eine Kurzform kann auch verwendet werden: -vvv

— jnns

42

Problem gelöst:

$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v

... anscheinend wurde ' localhost ' vom Remote-Host nicht gemocht. Remote /etc/hostsenthält jedoch:

::1                     localhost localhost.
127.0.0.1               localhost localhost.

während die lokale Netzwerkschnittstelle ist

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33184
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2

Seufzer. Soviel zum Kopfgeld von 100 RP, das ich angelegt habe :)

— Lorenzog
quelle

1

Ah. Dann werde ich nicht die Mühe machen, meinen Kommentar als Antwort zu schreiben. (Prüfen Sie, ob ssh IPv6-Adressen auf Ihrem System bevorzugt.)

— Mike Sherrill 'Cat Recall'

Nun, Sie haben vorgeschlagen, die Option -v zu verdoppeln, aber das hat nichts Neues gezeigt. Indem ich mich jedoch nach ein paar Tagen erneut mit der Ausgabe befasste, konnte ich das Problem besser identifizieren. Wenn Sie die Antwort aufschreiben möchten, gebe ich Ihnen gerne das Kopfgeld.

— Lorenzog

1

Tatsächlich war der wichtige Punkt, "localhost" durch "127.0.0.1" zu ersetzen. Die zusätzlichen "-v" Argumente hätten hilfreich sein können, aber sie waren nicht das, was ich anstrebte. Vielen Dank.

— Mike Sherrill "Cat Recall"

laut diesem post auf superuser: superuser.com/questions/346971/ssh-tunnel-connection-refused hört ein programm, das zum abhören einer bestimmten adresse konfiguriert ist, diese bestimmte adresse ab

— jopasserat

1

Für mich funktioniert das Hinzufügen von ":" so, dass der Befehl in Ihrem Fall so aussehen würde: ssh -L: 7000: 127.0.0.1: 7000 user @ host -N -v -v

— valentin 12.04.17

21

Obwohl das Problem von OP bereits gelöst wurde, habe ich beschlossen, die Lösung für mein Problem mit anderen zu teilen, da ich von ssh dieselbe Fehlermeldung erhalten habe und auf anderen Sites keine Lösung gefunden habe.

In meinem Fall musste ich mich mit dem Dienst verbinden, der nur auf IPv6 lauscht. Ich habe es versucht:

ssh -f root@192.168.0.18 -L 51005: 127.0.0.1: 51005 -N
ssh -f root@192.168.0.18 -L 51005: localhost: 51005 -N

und ein paar andere Möglichkeiten, aber es hat nicht funktioniert. Jeder Verbindungsversuch http://localhost:51005verursacht folgende Fehler: channel 2: open failed: connect failed: Connection refused

Die Lösung ist:

ssh -f root@192.168.0.18 -L 51005: [:: 1]: 51005 -N

Die IPv6-Adresse muss in eckigen Klammern stehen.

— rzymek
quelle

1

Was ist, wenn Sie eine ssh-Konfigurationsdatei verwenden? Beispiel: "LocalForward localhost: 64160 192.168.1.56:3389"

— Effekt 13.11.15

Für mich funktioniert das Hinzufügen von führenden ":"

— Befehlen

9

Ich würde das zuerst versuchen.

$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v

Sie können "-v" bis zu dreimal verwenden, um die Ausführlichkeit zu erhöhen.

Ich denke, diese Fehlermeldung kann auftreten, wenn eine Firewall Port 7000 blockiert, aber Sie hatten dies bereits ausgeschlossen. (Wenn spätere Leser dies nicht ausgeschlossen haben, sehen Sie sich die Ausgabe von an netstat --numeric-ports.)

Ich glaube, ich habe diese Fehlermeldung schon vor langer Zeit gesehen, als ssh nach einem Update zum ersten Mal auf IPV6-Adressen aufmerksam wurde. Darin könnte ich mich irren. Wenn Sie experimentieren möchten, können Sie die IPV6-Loopback-Adresse "0: 0: 0: 0: 0: 0: 0: 0: 1" (oder ":: 1") verwenden.

— Mike Sherrill 'Cat Recall'
quelle

3

"... anscheinend wurde 'localhost' vom entfernten Host nicht gemocht. Dennoch enthält remote / etc / hosts:"

Es sei denn, Sie haben ssh auf dem Client ausgeführt, sodass 'localhost' von Ihrem Client nicht gemocht wurde. Die Remote-Datei / etc / hosts ist für die Remote-Verbindung von nicht eingehenden Verbindungen gedacht .

— Bilbo Beutlin
quelle

1

das hat mich auch verwirrt. Wenn Sie localhost in Ihr lokales Gerät eingeben, wird es lokal aufgelöst

— Ahmedov

3

Ich bin auf den gleichen Fehler gestoßen, als ich versucht habe, über einen SSH-Tunnel eine Verbindung zu MySQL auf einem anderen Server herzustellen. Ich stellte fest, dass der Parameter bind-address in /etc/my.cnf auf dem Zielserver an meine externe IP-Adresse (dualer NIC-Server) gebunden war und nicht an die interne, für die ich keine Verwendung hatte.

Wenn ich bind-address = 127.0.0.1 setze, kann ich meinen ssh-Tunnel wie folgt erfolgreich verwenden:

ssh -N -f -L 3307:127.0.0.1:3306 user@server.name

mysql -h 127.0.0.1 --port=3307 --protocol=TCP -uusername -ppassword

— Tom McQuarrie
quelle

Das hat auch bei mir funktioniert. Sie können MySQL nur an eine Adresse binden.

— leeand00

3

Ich bin auf diesen Fehler gestoßen, als ich Ports mit einem vollständigen Domainnamen anstelle von localhost weitergeleitet habe:

ssh -L 5900:host.name.com:5900 x11vnc

Der Port wurde nur für localhost geöffnet. Um also Verbindungen mit einem vollständig qualifizierten Namen zu akzeptieren, musste ich eine verbindliche Portbeschreibung hinzufügen :

ssh -L *:5900:host.name.com:5900 x11vnc

Dies würde Verbindungen von überall zulassen (so ist es nicht so sicher, verwenden Sie es sparsam).

— Cengique
quelle

2

Für mich funktioniert das Hinzufügen von ":" so, dass der Befehl in Ihrem Fall so aussehen würde:

ssh -L :7000:localhost:7000 user@host -N -v

— valentt
quelle

Es ist zu viel Zeit vergangen und ich kann nicht zurückgehen und nachsehen, aber das sieht gut aus.

— Lorenzog

1

???

Kanal 2: Öffnen fehlgeschlagen: Verbindung fehlgeschlagen: Verbindung abgelehnt

Bei user@hostPort 7000 gibt es nichts zu hören, das ist einfach und das ist alles.

— Poige
quelle

1

Das ist nicht wahr. Auf dem Host wird ein Dienst ausgeführt: 7000. Ich habe es auch mit anderen Diensten versucht.

— Lorenzog

2

Nein, dann würde es einfach hängen bleiben.

— RickyA

4

@ RickyA: Eigentlich stimmt das nicht. Wenn der Port nicht gebunden ist, wird die Verbindung abgelehnt. Ich habe diesen Fehler erhalten, weil ich den falschen internen Port verwendet habe (auf dem kein Dienst ausgeführt wurde). Der Fehler wurde behoben, als ich den Fehler korrigierte. poige hat insofern recht, als wenn nichts auf dem Port lauscht, es den Fehler verursacht.

— erb

1

Ich habe die gleiche Fehlermeldung erhalten:

Kanal 3: Öffnen fehlgeschlagen: Verbindung fehlgeschlagen: Verbindung abgelehnt

Und die Ursache war menschliches Versagen - ich habe versucht, auf einen anderen als den angegebenen Port auf dem Remote-Host zuzugreifen.

Ich dachte nur, ich teile das, obwohl dies wahrscheinlich nicht der Grund ist, warum die meisten von Ihnen diesen Fehler haben.

— Roei Bahumi
quelle

In meinem Fall: Genau das habe ich getan. Solch ein blöder Fehler, aber diese Antwort hat mich veranlasst, den Hafen zu überprüfen. Doh.

— Ken Sharp

1

Für mich habe ich versucht, ssh -L <port>:<remote server IP>:<port> <login>@<remote server IP>wann ich es hätte tun sollen ssh -L <port>:127.0.0.1:<port> <login>@<remote server IP>.

Ich hoffe das hilft jemandem!

— Ryanwc
quelle

1

Eine alternative Interpretation ist in meinem Fall Ihre falsche Eingabe.

user@host ~ $ ssh -vvvNL 4444:127.0.0.0.1:4444
...
channel 2: open failed: connect failed: Name or service not known

Was hier passiert, ist, dass die IP-Adresse eine zu viele Nullen hat und somit keine gültige Adresse ist. Ssh behandelt es stattdessen als einen Domainnamen, den es nicht auflösen kann. Hoppla!

PS: Ich ergänze dies, damit wir eine umfassende Liste möglicher Probleme bei der Behandlung der gleichen Symptome haben.

— Hincor
quelle