tunel ssh odmawia połączenia z „kanał 2: otwarte nie powiodło się”

Nagle (czytaj: bez zmiany parametrów) moja wirtualna maszyna netbsd zaczęła działać dziwnie. Objawy dotyczą tunelowania ssh.

Z mojego laptopa uruchamiam:

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

Następnie w innej powłoce:

$ irssi -c localhost -p 7000

Debata ssh mówi:

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

Próbowałem również z localhost: 80, aby połączyć się z (zdalnym) serwerem WWW, z identycznymi wynikami.

Host zdalny uruchamia NetBSD:

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

Jestem trochę zagubiony. Próbowałem uruchomić tcpdumpna zdalnym hoście i zauważyłem te „złe chksum”:

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>

Próbowałem zrestartować demona ssh bezskutecznie. Nie zrestartowałem się jeszcze - być może ktoś tutaj może zasugerować inną diagnostykę. Myślę, że może to być albo sterownik wirtualnej karty sieciowej, albo ktoś zrootował nasze ssh.

Pomysły ..?

Problem rozwiązany:

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

... najwyraźniej „ host lokalny ” nie był lubiany przez hosta zdalnego. Jednak pilot /etc/hostszawiera:

::1                     localhost localhost.
127.0.0.1               localhost localhost.

podczas gdy interfejs sieci lokalnej to

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

Westchnienie. tyle za nagrodę 100rp, którą włożyłem :)

Chociaż problem OP został już rozwiązany, postanowiłem udostępnić rozwiązanie mojego problemu, ponieważ dostałem ten sam komunikat o błędzie od ssh i nie znalazłem żadnego rozwiązania na innych stronach.

W moim przypadku musiałem połączyć się z usługą, która nasłuchuje tylko na IPv6. Próbowałem:

ssh -f [email protected] -L 51005: 127.0.0.1: 51005 -N
ssh -f [email protected] -L 51005: localhost: 51005 -N

i kilka innych sposobów, ale to nie działało. Każda próba połączenia http://localhost:51005powoduje błędy takie jak to: channel 2: open failed: connect failed: Connection refused

Rozwiązaniem jest:

ssh -f [email protected] -L 51005: [:: 1]: 51005 -N

Adres IPv6 musi być w nawiasach kwadratowych.

Najpierw spróbuję tego.

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

Możesz użyć „-v” do 3 razy, aby zwiększyć gadatliwość.

Myślę, że ten komunikat o błędzie może się pojawić, jeśli zapora blokuje port 7000, ale już to wykluczyłeś. (Jeśli późniejsi czytelnicy tego nie wykluczyli, spójrz na wynik netstat --numeric-ports.)

Myślę, że mogłem zobaczyć ten komunikat o błędzie dawno temu, kiedy ssh po raz pierwszy dowiedział się o adresach IPV6 po aktualizacji. Mogę się mylić w tej sprawie. Jeśli masz ochotę na eksperymentowanie, możesz wypróbować adres zwrotny IPV6 „0: 0: 0: 0: 0: 0: 0: 1” (lub „:: 1”).

„... najwyraźniej„ host lokalny ”nie był lubiany przez hosta zdalnego. Jednak zdalny plik / etc / hosts zawiera:”

Z wyjątkiem tego, że korzystałeś z ssh na kliencie, więc 'localhost' nie był lubiany przez twojego klienta. Plik zdalny / etc / hosts jest do zdalnego łączenia się nie przychodzących połączeń.

Napotkałem ten sam błąd podczas próby połączenia się z mysql na innym serwerze przez tunel ssh. Odkryłem, że parametr adresu powiązania w /etc/my.cnf na serwerze docelowym był powiązany z moim zewnętrznym ip (podwójnym serwerem NIC), a nie wewnętrznym, do czego nie miałem zastosowania.

Gdy ustawię adres powiązania = 127.0.0.1, mogę z powodzeniem korzystać z mojego tunelu ssh w następujący sposób:

ssh -N -f -L 3307:127.0.0.1:3306 [email protected]

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

Wystąpił ten błąd, gdy przekierowywałem porty z pełną nazwą domeny zamiast localhost:

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

Port był otwierany tylko dla hosta lokalnego, więc aby zaakceptować połączenia o pełnej nazwie, musiałem dodać opis portu powiązania :

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

które pozwoliłyby na połączenia z dowolnego miejsca (więc nie jest to takie bezpieczne, używaj go oszczędnie).

Dla mnie dodanie wiodącego „:” działa, więc polecenie w twoim przypadku wyglądałoby tak:

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

???

kanał 2: otwarte nieudane: połączenie nieudane: połączenie odrzucone

Przy user@hostporcie nasłuchowym 7000 nie ma nic, to proste i to wszystko.

Otrzymałem ten sam komunikat o błędzie:

kanał 3: otwarte nieudane: połączenie nieudane: połączenie odrzucone

A przyczyną był błąd ludzki - próbuję uzyskać dostęp do innego portu na hoście zdalnym niż ten, który podałem.

Pomyślałem, że podzielę się tym, chociaż prawdopodobnie nie jest to powód, dla którego większość z was ma ten błąd.

Dla mnie próbowałem, ssh -L <port>:<remote server IP>:<port> <login>@<remote server IP>kiedy powinienem to zrobić ssh -L <port>:127.0.0.1:<port> <login>@<remote server IP>.

Mam nadzieję, że to komuś pomoże!

Alternatywną interpretacją jest w moim przypadku błędne wpisanie.

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

Tutaj dzieje się tak, że adres IP ma jeden zbyt wiele zer, a zatem nie jest prawidłowym adresem. Tak więc ssh traktuje to jako nazwę domeny, której nie może rozwiązać. Ups!

PS: Uzupełniam to, abyśmy mieli wyczerpującą listę możliwych problemów podczas rozwiązywania tych samych objawów.