Помилка тунелювання SSH: "канал 1: відкрито не вдалося: адміністративно заборонено: відкрито не вдалося"

Коли я відкриваю цей ssh-тунель:

ssh -nXNT -p 22 localhost -L 0.0.0.0:8984:remote:8983

Я отримую цю помилку при спробі отримати доступ до HTTP-сервера, що працює на localhost: 8984:

channel 1: open failed: administratively prohibited: open failed

Що означає ця помилка та на якій машині ви можете виправити проблему?

канал 1: відкрито не вдалося: адміністративно заборонено: відкрито не вдалося

Вищезгадане повідомлення стосується вашого SSH-сервера, який відхиляє запит вашого клієнта SSH про відкриття бічного каналу. Зазвичай це відбувається з -D, -Lабо -w, оскільки для передачі переданих даних поперек необхідні окремі канали в потоці SSH.

Оскільки ви використовуєте -L(також застосовно до -D), є два питання, про які ваш SSH-сервер відхиляє цей запит:

• AllowTcpForwarding (як згадував Стів Бузонас)
• PermitOpen

Ці параметри можна знайти в /etc/ssh/sshd_config. Ви повинні переконатися, що:

• AllowTCPForwarding або немає, коментується, або встановлено yes
• PermitOpenабо немає, коментується, або встановлено any[1]

Крім того, якщо ви використовуєте ключ SSH для підключення, ви повинні перевірити, чи немає у записі, що відповідає вашому ключу SSH ~/.ssh/authorized_keys, no-port-forwardingабо у permitopenзаявах [2].

Не має відношення до вашої конкретної команди, але дещо стосується і цієї теми, це PermitTunnelваріант, якщо ви намагаєтесь використовувати параметр -w.

[1] Повний синтаксис в sshd_config(5)довідці.

[2] Повний синтаксис в authorized_keys(5)довідці.

У дуже дивному випадку я також зазнав цю помилку, намагаючись створити локальний тунель. Моя команда була приблизно такою:

ssh -L 1234:localhost:1234 user@remote

Проблема полягала в тому, що на віддаленому хості /etc/hostsне було запису для "localhost", тому ssh-сервер не знав, як налаштувати тунель. Дуже недружнє повідомлення про помилку для цього випадку; рада, що я нарешті зрозумів це.

Урок: переконайтеся, що цільове ім'я хосту вашого тунелю буде вирішено віддаленим хостом або через DNS, або /etc/hosts.

Принаймні одна відповідь полягає в тому, що машина «віддалена» чомусь недоступна для ssh. Повідомлення про помилку просто абсурдне.

Якщо "віддалений" не вдалося вирішити на сервері, ви отримаєте цю помилку. Замініть IP-адресу і подивіться, чи це вирішує вашу проблему ...

(В основному така ж відповідь, як і у Ніла, але я, безумовно, виявив, що це проблема з моєї сторони) [У мене був псевдонім для назви машини у моєму ~/.ssh/configфайлі - і віддалений апарат нічого не знав про цей псевдонім ...

Ця помилка остаточно з’являється, коли ви використовуєте параметри ssh ControlPathта ControlMasterдля спільного використання одного сокетного з'єднання для повторного використання між декількома підключеннями клієнтів (від одного клієнта до того ж користувача @ сервера). Відкриття занадто багато (що б це не означало, у моєму випадку ~ 20 підключень) дає це повідомлення. Якщо закрити будь-які попередні з'єднання, я можу відкривати новіші, знову до межі.

"адміністративно заборонено" - це специфічний прапор повідомлення ICMP, який зводиться до "Адміністратор явно хоче, щоб це з'єднання було заблоковано".

Перевірте налаштування iptables.

Аналогічна проблема

Інший можливий результат

У мене була та ж проблема , використовуючи ~/.ssh/authorized_keysз permitopen.

Під час autosshстворення тунелю мені потрібні два порти:

• один для підключення (10000),
• один для моніторингу (10001).

На стороні клієнта

Це створило мені подібну проблему з моніторинговим портом:

autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60  -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa user@remote

У мене було таке повідомлення (через 10 хвилин):

channel 2: open failed: administratively prohibited: open failed

На віддаленій стороні

Мій /var/log/auth.logмістив:

Received request to connect to host 127.0.0.1 port 10001, but the request was denied.

У моїй ~/.ssh/authorized_keys(віддаленій частині) у мене було таке:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa AAAA...

Як її вирішити

Я вирішив це, замінивши localhostекземпляри на 127.0.0.1:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="127.0.0.1:10000",permitopen="127.0.0.1:10001" ssh-rsa AAAA...

Схоже, що SSH не розуміє, що localhostце ярлик 127.0.0.1, отже, повідомлення auth.logі заборонене адміністративно повідомлення.

Що я тут розумію, це те, що адміністративно означає "завдяки певній конфігурації на стороні сервера".

Це також відбувається, коли /etc/sshd_configє

AllowTcpForwarding no 

набір. Переключіть його на, yesщоб дозволити переадресацію TCP.

У моєму випадку, мені довелося замінити localhostз 127.0.0.1в:

ssh -L 1234:localhost:3389 user@remote

щоб змусити його працювати.

Я намагався виконувати вказівкиrdesktop -L localhost:1234 Amazon щодо підключення до AWS EC2 через тунелювання SSH . Я намагався змінити /etc/ssh/sshd_config(як клієнтський, так і серверний Ubuntu 16.04 LTS) на найвищу відповідь. Я також перевірив, що localhostзнаходиться в /etc/hostsобох сторонах.

Нічого не працювало, поки я не змінив саму sshкоманду на:

ssh -L 1234:127.0.0.1:3389 user@remote

Для пошуку остаточної відповіді потрібна деяка діяльність з усунення несправностей:

• перевірте, чи включено переадресація портів у конфігурації ssh користувача,
• включити багатослівність ssh (-v),
• перевірити ssh-журнали на локальному хості та захистити журнали на віддаленому,
• перевірити різні віддалені порти,
• перевірте свої параметри iptables (як сказав Шадур).

Я отримав цю помилку один раз для введення пульта в параметр -L, також 0.0.0.0 є зайвим, ви можете опустити його з тими ж результатами, і я думаю, ви повинні додати -g, щоб він працював.

Це рядок, який я використовую для тунелювання: ssh -L 8983:locahost:8984 user@remote -4 -g -N

-4 tells to use only ipv4
-g Allows remote hosts to connect to local forwarded ports.
-N Do not execute a remote command.  This is useful for just forwarding ports (protocol version 2 only). I use this to clog the terminal so I don't forget to close it since generally I need the tunnels temporarily.

Це також може бути спричинено тим, що неможливо прив’язатись до порту на локальній стороні.

ssh -Nn -L 1234:remote:5678 user@remote

Ця команда намагається прив’язати до локальної машини порт 1234 прослуховування, який відображає сервіс на порт 5678 на віддаленій машині.

Якщо порт 1234 на локальній машині вже використовується іншим процесом (можливо фоновим сеансом ssh -f), то ssh не зможе прослуховувати цей порт і тунель вийде з ладу.

Проблема полягає в тому, що це повідомлення про помилку може означати будь-яку з кількох речей, а "адміністративно заборонено" іноді дає неправильну думку. Отже, крім перевірки DNS, міжмережевих стін між локальним та віддаленим та sshd_config, перевірте, чи вже використовується локальний порт. Використовуйте

lsof -ti:1234

щоб зрозуміти, який процес працює на 1234. Вам може знадобитися sudo для lsof, щоб перелічити процеси, що належать іншим користувачам. Тоді можна використовувати

ps aux | grep <pid>

щоб з'ясувати, що це за процес.

Щоб отримати все це в одній команді:

ps aux | grep "$(sudo lsof -ti:1234)"

У мене було те саме повідомлення під час спроби тунелю. Виникла проблема із сервером dns на віддаленій стороні. Проблема була вирішена, коли вона повернулася до роботи.

Я надзвичайно здивований, що ніхто не згадував, що це може бути проблема DNS.

journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to user@example.com: unknown host (Name or service not known)

Це може бути представлено, якщо remoteце не вирішується, або ви ввели невідомий синтаксис, як я це зробив тут, де я додав user@логіку до переадресації портів (яка не працюватиме).

У моєму випадку проблема сталася із запитом тунелю без доступу до оболонки, тоді як сервер мав на меті змінити пароль для мого облікового запису. Через відсутність оболонки я не міг цього бачити і отримував лише помилку

channel 2: open failed: administratively prohibited: open failed  

Моя конфігурація тунелю була такою:

ssh -p [ssh-port] -N -f -L [local-port]:127.0.0.1:[remote-port]
[server-address]

Помилка, виявлена ​​при вході безпосередньо на сервер (без -N -f):

WARNING: Your password has expired. You must change your password now
and login again!

Я вирішив проблему, увійшовши з доступом до оболонки та змінивши пароль. Тоді я міг би просто використовувати тунелі без доступу оболонки знову.

У мене виникла ця проблема, коли я намагався підключитися через SSH з користувачем, який отримав дозвіл на з'єднання лише за допомогою SFTP.

Наприклад, це було на сервері /etc/ssh/sshd_config:

Match group sftponly
    ForceCommand internal-sftp
    ChrootDirectory /usr/chroot/%u
    [...]
Match

Тому в цьому випадку, щоб використовувати SSH, вам доведеться або видалити користувача з еквівалентної sftponlyгрупи, або підключитись за допомогою користувача, який не обмежується SFTP.

Перевірте, чи /etc/resolv.confна сервері, на якому ви збираєтесь, порожній ssh. Кілька разів я виявляв, що це пов’язано з порожнім /etc/resolv.confфайлом

Якщо немає root, ви можете просто перевірити на сервері, спробувавши деякі pingабо telnet(80) на загальнодоступному імені хоста, тобто:

root@bananapi ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

Після додавання записів серверів імен до /etc/resolv.conf:

root@bananapi ~ # telnet www.google.com 80
Trying 74.125.195.104...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 302 Found
Location: http://www.google.ro/?gws_rd=cr&ei=8fStVZ-hMIv6UvX6iuAK

Однак ви також повинні перевірити, чому він /etc/resolv.confбув порожнім (зазвичай це заповнено записами серверів імен клієнтом dhcp на сервері, якщо це можливо.

Я отримував те саме повідомлення під час налаштування SSH на Debian. Виявилося, що у віддаленій системі не було вільного місця. Після звільнення місця на диску і перезавантаження, тунель почав працювати.

Я бачив цю помилку на cygwin, і це повинно бути правдою і для Linux і працювало на мене. У моєму випадку я зробив ssh -ND *: 1234 user@127.0.0.1, і коли я підключив браузер до цього сервера комп’ютерних шкарпеток, він переглянувся, але на комп, де я запустив цю команду ssh, у мене з’явилася помилка консоль із кожним запитом - принаймні для одного сайту, хоча браузер витягував його через проксі-сервер або, здавалося б, принаймні настільки, наскільки я бачив основний вік. Але внесення цієї зміни позбулося невдалого повідомлення

http://linuxindetails.wordpress.com/2010/02/18/channel-3-open-failed-administratively-prohibited-open-failed/

While trying to do some SSH tunneling, here is the error I got :
channel 3: open failed: administratively prohibited: open failed
To avoid this kind of error, have a look at the SSH daemon configuration file :
/etc/ssh/sshd_config
Add possibly the following line :
root@remote-server:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
root@remote-server:~# service ssh restart
or

root@remote-server:~# /etc/init.d/ssh restart

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

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

Перевірте свій маршрутизатор на захист від рендеринга DNS . Мій маршрутизатор (pfsense) має захист від рендеринга DNS, включений за замовчуванням. Це спричинило помилку "канал відкритий: не вдалося адміністративно заборонено: відкрити не вдалося" помилку з SSH

У мене був той самий випуск, і я зрозумів, що це DNS. Трафік тунельний, але запит DNS немає. Спробуйте відредагувати файл хостів DNS вручну та додати службу, до якої ви хочете отримати доступ.

Мій випадок:

$ssh -D 8081 localhost >>log1.txt 2>&1 &

----wait for 3 days

$tail -f log1.txt
channel 963: open failed: connect failed: Connection refused
channel 963: open failed: connect failed: Connection refused
channel 971: open failed: connect failed: Connection reset by peer
channel 982: open failed: connect failed: Connection timed out
channel 979: open failed: connect failed: Connection timed out
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed

$ps  axu | grep 8081
root       404  0.0  0.0   4244   592 pts/1    S+   05:44   0:00 grep --color=auto 8081
root       807  0.3  0.6   8596  6192 ?        S    Mar17  76:44 ssh -D 8081 localhost

$lsof -p 807 | grep TCP
ssh     807 root 1013u  sock     0,8      0t0 2076902 protocol: TCP
ssh     807 root 1014u  sock     0,8      0t0 2078751 protocol: TCP
ssh     807 root 1015u  sock     0,8      0t0 2076894 protocol: TCP
.....

$lsof -p 807 | wc -l
1047

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   malcolm-desktop

$ssh localhost
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-53-generic i686)

----after restart ssh -D 8081 localhost
$ lsof -p 1184 | grep TCP
ssh     1184 root    3u  IPv4 2332193      0t0   TCP localhost:37742->localhost:ssh (ESTABLISHED)
ssh     1184 root    4u  IPv6 2332197      0t0   TCP ip6-localhost:tproxy (LISTEN)
ssh     1184 root    5u  IPv4 2332198      0t0   TCP localhost:tproxy (LISTEN)
ssh     1184 root    6u  IPv4 2332215      0t0   TCP localhost:tproxy->localhost:60136 (ESTABLISHED)
ssh     1184 root    7u  IPv4 2336142      0t0   TCP localhost:tproxy->localhost:32928 (CLOSE_WAIT)
ssh     1184 root    8u  IPv4 2336062      0t0   TCP localhost:tproxy->localhost:32880 (CLOSE_WAIT)

Я отримав цю помилку під час написання цього запису у своєму блозі :

/etc/ssh/sshd_config було щось на кшталт:

Match Group SSHTunnel_RemoteAccessGroup
    AllowTcpForwarding yes
    PermitOpen=sshbeyondremote.server.com:22

Але ~/.ssh/configмав:

Host remote.server.com
  HostName remote.server.com
  Port 10022
  User useronremote
  IdentityFile ~/.ssh/keys/key1/openssh.keyforremote.priv
  LocalForward 2222 SSHBeyondRemote.server.com:22

Зверніть увагу на різницю в регістрі (великої літери) між SSHBeyondRemote.server.com:22 та sshbeyondremote.server.com:22 .

Після того, як я виправив справу, я більше не бачив проблеми.

Я використовував:

Версія клієнта OpenSSH:

• OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 березня 2016 року

Версія сервера OpenSSH:

• OpenSSH_7.6p1 Debian-4, OpenSSL 1.0.2n 7 грудня 2017 року

Інша причина вирішення імені: Мій / etc / hosts мав помилкову IP-адресу для імені сервера (не для localhost), наприклад:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Але налаштований IP-сервер (і ім'я DNS, вирішене за допомогою команд хост / копати), було 192.168.2.47. Простий друк, викликаний попередньою конфігурацією IP. Після виправлення / etc / hosts тунельне підключення спрацювало бездоганно:

ssh user@server.domain.com -L 3456:127.0.0.1:5901

Дивно, що справжній IP викликав збій, коли я використовував localhost literal IP для тунелю. Distro: Ubuntu 16.04 LTS.

Причина, чому у мене було таке повідомлення, не є найпоширенішим, але його варто зазначити. Я створив за сценарієм список тунелів, і щоб забезпечити подання стовпців, я надрукував кожен останній байт на два байти. Коли я намагався відкрити тунель для переадресації на 192.168.66.08, це завжди не вдалося, оскільки "08" трактується gethostbyaddr як недійсне восьмеричне число :)

Здається, існує багато можливих першопричин цього повідомлення. У моєму випадку це була неможливість отримати доступ до віддаленого пристрою, оскільки я неправильно надав файл ключів .

-LОпція додає неявне SSH стрибок (ефективно використовуючи явний SSH хоста в якості сервера / скачки бастіону). Налагодити це може бути простіше, виконуючи стрибок явно і створивши оболонку входу для цільової машини за допомогою "proxycommand".

Як тільки це працює, ви можете зробити порт вперед на основі цільової машини localhost(якщо припустити, що він може увійти до себе):

-N -L 1234:localhost:1234