ssh тунель відмовляється від з'єднання з "каналом 2: відкриття не вдалося"

Раптом (читайте: не змінюючи жодних параметрів) мій netbsd virtualmachine почав діяти дивно. Симптоми стосуються ssh тунелювання.

З мого ноутбука я запускаю:

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

Потім в іншій оболонці:

$ irssi -c localhost -p 7000

Налагодження ssh говорить:

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

Я також намагався підключитися до localhost: 80 для підключення до (віддаленого) веб-сервера з однаковими результатами.

Віддалений хост працює з 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

Я трохи загубився. Я спробував запустити tcpdumpна віддалений хост, і я помітив ці "погані 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>

Я спробував перезапустити демону ssh безрезультатно. Я ще не перезавантажувався - можливо, хтось тут може запропонувати іншу діагностику. Я думаю, це може бути або драйвер віртуальної мережевої карти, або хтось вкоренив наш ssh.

Ідеї ​​..?

Проблема вирішена:

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

... мабуть, " localhost " не сподобався віддаленому хосту. Тим не менш, дистанційний /etc/hostsмістить:

::1                     localhost localhost.
127.0.0.1               localhost localhost.

поки інтерфейс локальної мережі є

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

Зітхнути. стільки за щедрість 100рр, яку я поклав :)

Хоча проблема ОП вже вирішена, я вирішив поділитися рішенням своєї проблеми, оскільки мені надійшло те саме повідомлення про помилку від ssh, і я не знайшов рішення на інших сайтах.

У моєму випадку мені довелося підключитися до сервісу, який слухає лише на IPv6. Я намагався:

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

і кілька інших способів, але це не спрацювало. Будь-яка спроба підключення http://localhost:51005викликає подібні помилки: channel 2: open failed: connect failed: Connection refused

Рішення таке:

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

IPv6-адреса повинна бути у квадратних дужках.

Я спершу спробую це.

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

Ви можете використовувати "-v" до 3 разів для збільшення багатослівності.

Я думаю, що це повідомлення про помилку може виникнути, якщо брандмауер блокує порт 7000, але ви це вже виключили. (Якщо пізніші читачі цього не виключили, подивіться вихід netstat --numeric-ports.)

Я думаю, що, можливо, я бачив це повідомлення про помилку давно, коли ssh вперше дізнався про адреси IPV6 після оновлення. Я можу помилитися з цього приводу. Якщо вам здається, що експериментуєте, ви можете спробувати IP-адрес із зворотним зв'язком "0: 0: 0: 0: 0: 0: 0: 1" (або ":: 1").

"... мабуть," localhost "віддалений хост не сподобався. Однак, віддалений / etc / hosts містить:"

За винятком того, що ви запускаєте ssh на клієнті, тож ваш localhost не сподобався вашому клієнту. Файл віддаленого / etc / hosts призначений для віддаленого з'єднання , яке не входить .

Я зіткнувся з цією ж помилкою, намагаючись підключитися до mysql на іншому сервері через тунель ssh. Я виявив, що параметр bind-address у /etc/my.cnf на цільовому сервері був пов'язаний із моїм зовнішнім ip (подвійним сервером NIC), а не внутрішнім, для чого я не використовував.

Коли я встановив bind-address = 127.0.0.1, я міг успішно використовувати свій ssh ​​тунель наступним чином:

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

Я зіткнувся з цією помилкою, коли пересилав порти з повним доменним іменем замість localhost:

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

Порт відкривався лише для localhost, тому щоб прийняти з'єднання з повністю кваліфікованим іменем, мені довелося додати обов'язковий опис порту :

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

що дозволить з’єднати з будь-якого місця (так що це не так безпечно, використовуйте їх економно).

Для мене додавання ведучого ":" працює так, щоб команда у вашому випадку виглядала б так:

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

???

канал 2: відкрито не вдалося: з'єднання не вдалося: з'єднання відмовлено

У user@hostпорту 7000 немає прослуховування, це просто, і все.

Я отримав те саме повідомлення про помилку:

канал 3: відкрито не вдалося: з'єднання не вдалося: з'єднання відмовлено

Причиною стала помилка людини - я намагався отримати доступ до іншого порту на віддаленому хості, ніж той, який я вказав.

Просто подумав, що я поділюсь цим, хоча це, мабуть, не причина, чому більшість із вас відчувають цю помилку.

Для мене я намагався, ssh -L <port>:<remote server IP>:<port> <login>@<remote server IP>коли мав би робити ssh -L <port>:127.0.0.1:<port> <login>@<remote server IP>.

Я сподіваюся, що це комусь допоможе!

Альтернативне тлумачення - в моєму випадку, ваше неправильне введення тексту.

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

Тут відбувається те, що IP-адреса має занадто багато нулів, тому не є дійсною адресою. Отже, ssh трактує це як доменне ім'я, замість якого він не може вирішити. На жаль!

PS: Я доповнюю це, щоб ми мали вичерпний перелік можливих проблем при усуненні тих же симптомів.