ошибка туннелирования ssh: «канал 1: открытие не удалось: административно запрещено: открытие не удалось»

<p>когда я открываю этот ssh туннель:</p><pre><code>ssh -nxnt -p 22 localhost -l 0.0.0.0:8984:remote:8983 </code></pre><p>я получаю эту ошибку при попытке получить доступ к http-серверу, работающему на localhost: 8984:</p><pre><code>channel 1: open failed: administratively prohibited: open failed </code></pre><p>что означает эта ошибка, и на какой машине вы можете решить проблему?</p>

<blockquote> <p>канал 1: не удалось открыть: административно запрещено: не удалось открыть</p> </blockquote><p>приведенное выше сообщение относится к вашему ssh-серверу, отклонившему запрос вашего ssh-клиента об открытии побочного канала. обычно это происходит из <code>-d</code>, <code>-l</code> или <code>-w</code>, поскольку для передачи пересылаемых данных требуются отдельные каналы в потоке ssh.</p><p>поскольку вы используете <code>-l</code> (также применимо к <code>-d</code>), существует два варианта, по которым ваш ssh-сервер отклоняет этот запрос:</p><ul> <li><code>allowtcpforwarding</code> (как упоминал стив бузонас)</li> <li><code>permitopen</code></li> </ul><p>эти параметры можно найти в <code>/etc/ssh/sshd\_config</code>. вы должны убедиться, что:</p><ul> <li><code>allowtcpforwarding</code> либо отсутствует, либо закомментировано, либо имеет значение <code>yes</code></li> <li><code>permitopen</code> либо отсутствует, либо закомментировано, либо имеет значение <code>any</code> [1]</li> </ul><p>кроме того, если вы используете для подключения ключ ssh, убедитесь, что запись, соответствующая вашему ключу ssh в <code>~/.ssh/authorized\_keys</code>, не содержит операторов <code>no-port-forwarding</code> или <code>permitopen</code> [2] ,.</p><p>параметр <code>permittunnel</code>, если вы пытаетесь использовать параметр -w, не относится к вашей конкретной команде, но также имеет отношение и к этой теме.</p><p>[1] полный синтаксис в справочной странице <a href="https://man.openbsd.org/sshd\_config"><code>sshd\_config(5)</code></a> .</p><p>[2] полный синтаксис на странице <a href="https://man.openbsd.org/sshd#authorized\_keys\_file\_format"><code>authorized\_keys(5)</code></a> .</p>

<p>в очень странном случае я также столкнулся с этой ошибкой при попытке создать локальный туннель. моя команда была примерно такой:</p><pre><code>ssh -l 1234:localhost:1234 user@remote </code></pre><p>проблема заключалась в том, что на удаленном хосте <code>/etc/hosts</code> не было записи для "localhost", поэтому сервер ssh не знал, как настроить туннель. очень недружелюбное сообщение об ошибке для этого случая; рад, что наконец понял это.</p><p>урок: убедитесь, что имя целевого хоста вашего туннеля может быть разрешено удаленным хостом через dns или <code>/etc/hosts</code>.</p>

<p>по крайней мере, один ответ заключается в том, что "удаленный" компьютер по какой-то причине недоступен по ssh. сообщение об ошибке просто абсурдно.</p>

<p>если "удаленный" не может быть разрешен на сервере, вы получите эту ошибку. замените на ip-адрес и посмотрите, решит ли это вашу проблему ...</p><p>(в основном тот же ответ, что и у нила, но я определенно обнаружил, что это проблема на моей стороне) [у меня был псевдоним для имени машины в моем <code>~/.ssh/config</code> файл - и удаленный компьютер ничего не знал об этом псевдониме ...</p>

<p>эта ошибка окончательно появляется, когда вы используете ssh-параметры <code>controlpath</code> и <code>controlmaster</code> для совместного использования одного сокетного соединения для повторного использования между несколькими клиентскими подключениями (от одного клиента к одному пользователю @ серверу). открытие слишком много (что бы это ни значило, в моем случае ~ 20 соединений) приводит к этому сообщению. закрытие любых предыдущих подключений позволяет мне открывать новые, снова до предела.</p>

<p>"административно запрещено" - это специальный флаг сообщения icmp, который сводится к "администратор явно хочет, чтобы это соединение было заблокировано".</p><p>проверьте настройки iptables.</p>

<p>в моем случае мне пришлось заменить <code>localhost</code> на <code>127.0.0.1</code> в:</p><pre><code>ssh -l 1234:localhost:3389 user@remote </code></pre><p>чтобы это работало.</p><p>я пытался <code>rdesktop -l localhost:1234</code> следуя инструкциям amazon <a href="https://aws.amazon.com/premiumsupport/knowledge-center/connect-ec2-linux-windows/">инструкции по подключению к aws ec2 через ssh-туннелирование</a> . я пытался изменить <code>/etc/ssh/sshd\_config</code> (и клиент, и сервер работают под управлением ubuntu 16.04 lts) в ответе с наибольшим количеством голосов. я также проверил, что <code>localhost</code> находится в <code>/etc/hosts</code> с обеих сторон.</p><p>ничего не работало, пока я не изменил саму команду <code>ssh</code> на:</p><pre><code>ssh -l 1234:127.0.0.1:3389 user@remote </code></pre>

<h2>похожая проблема</h2><p>еще одно возможное преимущество</p><p>у меня была такая же проблема с использованием <code>~/.ssh/authorized\_keys</code> с <code>permitopen</code>.</p><p>поскольку я использую <code>autossh</code> для создания туннеля, мне нужны два порта:</p><ul> <li>один для подключения (10000),</li> <li>один для мониторинга (10001).</li> </ul><h3>на стороне клиента</h3><p>это дало мне похожую проблему с портом мониторинга:</p><pre><code>autossh -m 10001 -o gatewayports=yes -o serveraliveinterval=60 -o tcpkeepalive=yes -t -n -r :10000:localhost:22 -i ~/.ssh/id\_rsa user@remote </code></pre><p>у меня было это сообщение (через 10 минут):</p><pre><code>channel 2: open failed: administratively prohibited: open failed </code></pre><h3>на удаленной стороне</h3><p>мой <code>/var/log/auth.log</code> содержит:</p><pre><code>received request to connect to host 127.0.0.1 port 10001, but the request was denied. </code></pre><p>в моем <code>~/.ssh/authorized\_keys</code> (удаленная сторона) у меня было это:</p><pre><code>command="/home/user/tunnel",no-x11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa aaaa... </code></pre><h2>как это решить</h2><p>я решил это, заменив <code>localhost</code> экземпляры на <code>127.0.0.1</code>:</p><pre><code>command="/home/user/tunnel",no-x11-forwarding,no-pty,permitopen="127.0.0.1:10000",permitopen="127.0.0.1:10001" ssh-rsa aaaa... </code></pre><p>похоже, что ssh не понимает, что <code>localhost</code> является ярлыком для <code>127.0.0.1</code>, следовательно сообщение в <code>auth.log</code> и <em>административно запрещено</em> сообщение.</p><p>я понимаю, что <em>административно</em> означает "из-за конкретной конфигурации на стороне сервера".</p>

<p>это также происходит, когда <code>/etc/sshd\_config</code> имеет</p><pre><code>allowtcpforwarding no </code></pre><p>набор. переключите его на <code>yes</code>, чтобы разрешить tcp пересылку).</p>

<p>однажды я получил эту ошибку за то, что отдал пульт в параметре -l, также 0.0.0.0 является избыточным, вы можете опустить его с теми же результатами, и я думаю, что вы должны добавить -g, чтобы он работал.</p><p>это линия, которую я использую для туннелирования: <code>ssh -l 8983:locahost:8984 user@remote -4 -g -n</code></p><pre><code>-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. </code></pre>

<p>некоторые действия по устранению неполадок необходимы, чтобы найти окончательный ответ:</p><ul> <li>проверьте, включена ли переадресация портов в конфигурации ssh пользователя,</li> <li>включить многословие ssh (-v),</li> <li>проверять логи ssh на локальном хосте и защищать логи на удаленном,</li> <li>проверить другой удаленный порт,</li> <li>проверьте настройки iptables (как сказал шадур).</li> </ul>

<p>это также может быть вызвано невозможностью привязки к порту на локальной стороне.</p><pre><code>ssh -nn -l 1234:remote:5678 user@remote </code></pre><p>эта команда пытается связать прослушивающий порт 1234 на локальном компьютере, который сопоставляется со службой через порт 5678 на удаленном компьютере.</p><p>если порт 1234 на локальной машине уже используется другим процессом (возможно, фоновым сеансом ssh -f), то ssh не сможет прослушивать этот порт, и туннель не будет работать.</p><p>проблема в том, что это сообщение об ошибке может означать любую из нескольких вещей, а "административно запрещено" иногда дает неверное представление. поэтому в дополнение к проверке dns, межсетевых экранов между локальным и удаленным и sshd\_config, проверьте, не используется ли уже локальный порт. использование</p><pre><code>lsof -ti:1234 </code></pre><p>чтобы выяснить, какой процесс запущен на 1234. вам может потребоваться sudo для lsof, чтобы вывести список процессов, принадлежащих другим пользователям. тогда вы можете использовать</p><pre><code>ps aux | grep <pid> </code></pre><p>чтобы выяснить, что это за процесс.</p><p>чтобы получить все это в одной команде:</p><pre><code>ps aux | grep "$(sudo lsof -ti:1234)" 

в моем случае проблема была связана с запросом туннеля без доступа shell, в то время как сервер пытался принудительно изменить пароль для моей учетной записи. из-за отсутствия shell я не смог этого увидеть и получил только ошибку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! я решил проблему, войдя в систему с доступом shell и изменив пароль. тогда я мог бы просто снова использовать туннели без доступа к shell.

я очень удивлен, что никто не упомянул, что это может быть проблемой 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@ к логике переадресации порта (которая не будет работать).

у меня было то же сообщение при попытке туннелирования. возникла проблема с dns-сервером на удаленной стороне. проблема была решена, когда он вернулся на работу.

у меня была эта проблема при попытке подключиться через ssh с пользователем, который был авторизован для подключения только по sftp.например, это было на сервере /etc/ssh/sshd_config:match group sftponly forcecommand internal-sftp chrootdirectory /usr/chroot/%u [...] match таким образом, в этом случае, чтобы использовать ssh, вам придется либо удалить пользователя из эквивалентной группы sftponly, либо подключиться, используя пользователя, не ограниченного sftp.

я получал то же сообщение во время туннелирования ssh к debian. оказалось, что в удаленной системе не было свободного места. после освобождения дискового пространства и перезагрузки туннель начал работать.

проверить, если /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 на сервере, если это применимо).

я получил эту ошибку во время записи <a href="https://www.zachpfeffer.com/single-post/ssh-directly-to-a-machine-youd-normally-need-to-ssh-into-server-to-get-to">эта запись в <a href="https://www.zachpfeffer.com/">мой блог :/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 обратите внимание на разницу в  регистр (использование заглавных букв) между <strong> sshbeyondremote.server.com:22</strong> и <strong> sshbeyondremote.server.com:22</strong>.как только я исправил дело, я больше не видел проблему.я использовал:версия клиента 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 г. 

я видел эту ошибку на cygwin, и это должно быть верно и для linux и работал для меня. в моем случае я сделал ssh -nd : 1234 user@127.0.0.1 и когда я подключил браузер к этому серверу comp-socks, он просматривал, но на компе, где я запускал команду ssh, я получил эту ошибку, появляющуюся в консоль с каждым запросом - по крайней мере для одного сайта, хотя браузер извлекал его через прокси или, казалось, по крайней мере в той степени, в которой я видел основной возраст. но внесение этого изменения избавило от неудачного сообщения <a href="http://linuxindetails.wordpress.com/2010/02/18/channel-3-open-failed-administratively-prohibited-open-failed/">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 

небольшое дополнение к одному из комментариев выше: "ошибка разрешения dns может вызвать эту ошибку" - также убедитесь, что вы правильно указали имя своего хоста.я потратил более часа, пытаясь отладить все настройки ssh, и оказалось, что я только что написал в команде amazonaws, что эквивалентно приведенному выше примечанию об ошибке разрешения dns.

микропрограмма маршрутизатора asus rt68u (merlin asus) имеет параметр, разрешающий переадресацию порта ssh, который должен быть включен: <a href="https://i.stack.imgur.com/xflgt.jpg"><img src="https://i.stack.imgur.com/xflgt.jpg" alt="enter image description here"> динамическая переадресация портов была настроена, как описано в: <a href="https://unix.stackexchange.com/q/569058/182280">устранение неисправностей в туннеле dyamic 

причина, по которой я получил это сообщение, не самая распространенная, но стоит упомянуть. я сгенерировал с помощью сценария список туннелей, и для обеспечения представления столбца я напечатал каждый последний байт по два байта. когда я пытался открыть переадресацию туннеля на 192.168.66.08, это всегда не удавалось, потому что '08' интерпретируется gethostbyaddr как неверное восьмеричное число :)

проверьте ваш роутер на <a href="https://en.wikipedia.org/wiki/dns_rebinding">dns rebinding защита. мой маршрутизатор (pfsense) имеет включенную по умолчанию защиту перезаписи dns. это приводило к ошибке "канал открыт: ошибка административно запрещена: ошибка открытия" с ssh

кажется, есть много возможных корневых причин для этого сообщения. в моем случае это была невозможность доступа к удаленному, потому что я не предоставил <a href="https://unix.stackexchange.com/q/23291/6764">keyfile правильно.-l опция добавляет неявный ssh-переход (эффективно используя явный ssh-хост в качестве сервера бастиона/перехода). это может быть легче отладить, выполнив переход явно и создав оболочку входа в систему на целевом компьютере, используя команду proxycommand.как только это сработает, вы можете сделать переадресацию порта на основе localhost целевого компьютера (при условии, что он может войти в себя):-n -l 1234:localhost:1234 

мое дело:$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) </code></pre>

<p>другая причина разрешения имен: мой/etc/hosts имел ошибочный ip-адрес для имени сервера (не для localhost), например так:</p><pre><code>127.0.0.1 localhost 192.168.2.45 server.domain.com server </code></pre><p>но настроенный ip-адрес сервера (и dns-имя, разрешенное с помощью команд host/dig) был 192.168.2.47. простая опечатка, вызванная предыдущей реконфигурацией ip. после исправления/etc/hosts туннельное соединение работало безупречно:</p><pre><code>ssh user@server.domain.com -l 3456:127.0.0.1:5901 </code></pre><p>странно, что настоящий ip-адрес вызвал сбой, когда я использовал локальный ip-адрес localhost для туннеля. дистро: ubuntu 16.04 lts.</p>

<p>у меня была та же проблема, и я понял, что это был dns. трафик туннелируется, но dns-запроса нет. попробуйте вручную отредактировать файл dns hosts и добавить сервис, к которому вы хотите получить доступ.</p>

<p>еще один сценарий - служба, к которой вы пытаетесь получить доступ, не работает. я столкнулся с этой проблемой на днях, только чтобы вспомнить, что экземпляр httpd, к которому я пытался подключиться, был остановлен.</p><p>ваши шаги по решению проблемы должны состоять в том, чтобы начать с самого простого: перейти на другой компьютер и посмотреть, сможете ли вы подключиться локально, а затем вернуться к клиентскому компьютеру. по крайней мере, это позволит вам решить, в какой момент общение не происходит. вы можете использовать другие подходы, но это тот, который работал для меня.</p>