Vraag ssh-tunnel weigert verbindingen met "kanaal 2: openen mislukt"


Plotseling (lees: zonder parameters te veranderen) begon mijn netbsd virtualmachine vreemd te handelen. De symptomen betreffen ssh-tunneling.

Vanaf mijn laptop start ik:

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

Vervolgens in een andere shell:

$ irssi -c localhost -p 7000

De ssh-foutopsporing zegt:

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

Ik probeerde ook met localhost: 80 om verbinding te maken met de (externe) webserver, met identieke resultaten.

De externe host voert NetBSD uit:

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

Ik ben een beetje verloren. Ik probeerde te rennen tcpdump op de externe host en ik heb deze 'bad chksum' gezien:

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>

Ik heb geprobeerd de ssh-daemon zonder succes opnieuw op te starten. Ik ben nog niet opnieuw opgestart - misschien kan iemand hier andere diagnostiek voorstellen. Ik denk dat het de virtuele netwerkkaartstuurprogramma is, of iemand die onze ssh heeft geroot.

Ideeën ..?


47
2018-03-19 09:32


oorsprong


Probeer het eens voor het oplossen van problemen $ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v. (Je kunt "-v" maximaal 3 keer gebruiken om de breedsprakigheid te vergroten.) Is het ook mogelijk dat ssh onlangs is bijgewerkt? - Mike Sherrill 'Cat Recall'
Het uitvoerlogboek dat ik heb geplakt, is al verzameld met -v. - lorenzog
U kunt -v tot drie keer gebruiken om de breedsprakigheid te vergroten. Dus je zou kunnen kijken naar de output van ssh -L 7000... -N -v -v (twee v's) of ssh -L 7000... -N -v -v -v. - Mike Sherrill 'Cat Recall'
@ MikeSherrill'CatRecall 'Een afkorting kan ook worden gebruikt: -vvv - jnns


antwoorden:


Probleem opgelost:

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

... blijkbaar, 'localhost'was niet geliefd bij de externe host. Toch afgelegen /etc/hosts bevat:

::1                     localhost localhost.
127.0.0.1               localhost localhost.

terwijl de lokale netwerkinterface is

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

Zucht. zo veel voor de bounty van 100rp die ik heb gedaan :)


22
2018-03-31 20:48



Ah. Welnu, ik zal niet de moeite nemen om mijn commentaar op te schrijven als een antwoord. (Onderzoek of ssh ipv6-adressen op uw systeem verkiest.) - Mike Sherrill 'Cat Recall'
Nou, je stelde voor om de -v optie te verdubbelen, maar dat liet niets nieuws zien. Maar door me na een paar dagen naar de output te laten kijken, hielp het om het probleem op te sporen. Als je het antwoord wilt opschrijven, wil ik je graag de premie geven. - lorenzog
Eigenlijk was het belangrijkste punt "localhost" vervangen door "127.0.0.1". De extra "-v" -argumenten waren misschien nuttig geweest, maar dat was niet waar ik naar streefde. Bedankt. - Mike Sherrill 'Cat Recall'
volgens die post op superuser: superuser.com/questions/346971/ssh-tunnel-connection-refused  een programma dat is geconfigureerd om op een specifiek adres te luisteren, luistert naar dat specifieke adres - jopasserat
Voor mij is het toevoegen van de leidende ":" werkt zo-opdracht in jouw geval er als volgt uit: ssh -L: 7000: 127.0.0.1: 7000 user @ host -N -v -v - valentt


Hoewel het probleem van OP al is opgelost, heb ik besloten de oplossing voor mijn probleem te delen, omdat ik dezelfde foutmelding kreeg van ssh en ik geen oplossing op andere sites vond.

In mijn geval moest ik verbinding maken met de dienst die alleen op IPv6 luistert. Ik probeerde:

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

en een paar andere manieren, maar het werkte niet. Elke poging tot verbinding met http://localhost:51005 veroorzaakt fouten als deze: channel 2: open failed: connect failed: Connection refused

De oplossing is:

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

IPv6-adres moet tussen vierkante haken staan.


18
2017-09-26 08:23



Wat als je een ssh-configuratiebestand gebruikt? voorbeeld: "LocalForward localhost: 64160 192.168.1.56:3389" - meffect
Het toevoegen van de leidende opdracht ":" werkt voor mij als volgt: ssh -f Root@192.168.0.18 -L: 51005: 127.0.0.1: 51005 -N - valentt


Ik zou dit eerst proberen.

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

U kunt "-v" tot 3 keer gebruiken om de breedsprakigheid te vergroten.

Ik denk deze foutmelding kan ontstaan ​​als een firewall poort 7000 blokkeert, maar dat had u al beslist. (Als latere lezers dit niet hebben uitgesloten, kijk dan naar de uitvoer van netstat --numeric-ports.)

ik denken Ik heb deze foutmelding misschien al heel lang geleden gezien, toen ssh voor het eerst op de hoogte was van IPV6-adressen na een update. Daar zou ik het mis kunnen hebben. Als je zin hebt om te experimenteren, kun je het IPV6-loopback-adres "0: 0: 0: 0: 0: 0: 0: 1" (of ":: 1") proberen.


6
2018-04-01 11:47





Ik ben deze fout tegengekomen toen ik probeerde verbinding te maken met mysql op een andere server via een ssh-tunnel. Ik vond dat de bind-adres parameter in /etc/my.cnf op de doelserver gebonden was aan mijn externe ip (dual NIC server) in plaats van intern, waar ik geen gebruik van had.

Toen ik bind-adres = 127.0.0.1 instelde, kon ik mijn ssh-tunnel als volgt gebruiken:

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

3
2018-04-03 23:55



Dat werkte ook voor mij. U kunt MySQL alleen aan één adres binden. - leeand00


Ik ben deze fout tegengekomen toen ik poorten doorstuurde met een volledige domeinnaam in plaats van localhost:

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

De poort werd alleen geopend voor localhost, dus om verbindingen met een volledig gekwalificeerde naam te accepteren, moest ik een toevoegen bindende poort Omschrijving:

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

die verbindingen van overal mogelijk zou maken (dus het is niet zo veilig, gebruik het spaarzaam).


3
2017-12-11 19:47





"... blijkbaar was 'localhost' niet geliefd bij de externe host. Toch bevat remote / etc / hosts:"

Behalve dat je ssh op de client draaide, dus 'localhost' was niet geliefd bij je klant. Het bestand remote / etc / hosts dient voor extern verbinden uit niet inkomend verbindingen.


2
2018-04-01 14:42



dat was ook verwarrend voor mij. Wanneer u localhost in uw lokale computer typt, wordt deze lokaal opgelost - Ahmedov


Voor mij betekent het toevoegen van leidende ":" -opdrachten in uw geval er zo uitzien:

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

2
2018-04-12 23:53



Er is te veel tijd verstreken en ik kan niet teruggaan om het te controleren, maar dit ziet er goed uit. - lorenzog


???

kanaal 2: openen mislukt: verbinding mislukt: verbinding geweigerd

Op user@host er is niets listening port 7000, dat is simpel en dat is alles.


1
2018-03-31 04:06



Dat is niet waar. Er is een service actief op host: 7000. Ik heb ook geprobeerd met andere services. - lorenzog
Nee, dan blijft het gewoon hangen. - RickyA
@RickyA: eigenlijk is dat niet waar. Als de poort niet is gebonden, wordt de verbinding geweigerd. Ik kreeg deze foutmelding van het gebruik van de verkeerde interne poort (waar geen service actief was), de fout ging weg toen ik de fout corrigeerde. poige heeft gelijk dat als er niets luistert naar de poort, dit de fout zal veroorzaken. - erb