SSH туннелирующая ошибка: “канал 1: открытый отказавший: административно запрещенный: открытый отказавший”

Некоторое действие поиска и устранения неисправностей необходимо для нахождения категорического ответа:

• проверьте, что перенаправление портов включено в ssh конфигурации пользователя,
• включите многословие ssh (-v),
• проверьте вход в систему ssh локальный хост и защитите вход в систему удаленный,
• протестируйте другой удаленный порт,
• проверьте свои iptables настройки (как Shadur заявил).

"административно запрещенный" определенное сообщение ICMP, махают рукой, останавливая, который кипит "Администратору, явно хочет это заблокированное соединение".

Проверьте свои iptables настройки.

По крайней мере один ответ - то, что "удаленная" машина недостижима с ssh по некоторым причинам. Сообщение об ошибке просто абсурдно.

Я видел эту ошибку на 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

канал 1: открытый отказавший: административно запрещенный: открытый отказавший

Вышеупомянутое сообщение относится к Вашему серверу SSH, отклоняющему запрос Вашего клиента SSH для открытия канала стороны. Это обычно прибывает из -D, -L или -w, поскольку отдельные каналы в потоке SSH требуются, чтобы переправлять переданные данные через.

Так как Вы используете -L (также применимый к -D), существует две рассматриваемых опции, которые заставляют Ваш сервер SSH отклонять этот запрос:

• AllowTcpForwarding (как Steve Buzonas упомянул),
• 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) страница справочника.

Я получил эту ошибку однажды для помещения удаленного в-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.

Еще один сценарий - то, что услуга, к которой Вы пытаетесь получить доступ, не работает. Я столкнулся с этой проблемой на днях только для запоминания httpd экземпляра, с которым я пробовал к связанному, был остановлен.

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

Это также происходит когда /etc/sshd_config имеет

AllowTcpForwarding no 

набор. Переключите его на yes позволить передачу TCP.

Эта ошибка окончательно открывается при использовании ssh опций ControlPath и ControlMaster для совместного использования одного сокетного соединения, которое будет снова использовано между несколькими соединениями клиента (от одного клиента на тот же user@server). Открытие слишком многих (независимо от того, что это означает в моем случае ~20 соединений) приводит к этому сообщению. Закрытие любых предыдущих соединений позволяет мне открыться более новый, снова до предела.

Если 'удаленное' не может быть разрешено на сервере, Вы получите ту ошибку. Замена IP-адресом и видит, решает ли это Ваш вопрос...

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

У меня было то же сообщение при попытке туннелировать. Была проблема с сервером DNS на удаленной стороне. Проблема была решена, когда она возвратилась к работе.

У меня была эта проблема при попытке Чтобы подключиться через SSH с пользователем, который был авторизован только для подключения с использованием SFTP.

Например, это было в сервере / etc / ssh / sshd_config :

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

Так что в этом случае использовать SSH, вам придется либо удалить пользователь из эквивалента SFTPONLY Группа или подключение пользователей, который не ограничен SFTP.

Выполните следующую команду:

df -h

Разделение выполняется в клиенте экрана , а не в самом сеансе экрана. пара может разделить свой экран любым способом, каким он захочет, независимо от вашего разделения.

Проверьте, пуст ли /etc/resolv.conf на сервере, на который вы ssh -участвуете. Несколько раз я обнаружил, что это связано с пустым файлом /etc/resolv.conf

Если не корень, вы можете просто проверить сервер, попробовав ping или telnet (80) на общедоступном имени хоста, то есть:

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

После добавления записей nameserver в /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 был пуст (обычно заполняется записями nameserver dhcp-клиентом на сервере, если применимо.

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

Проверьте свой маршрутизатор на наличие защиты DNS Rebinding . На моем маршрутизаторе (pfsense) по умолчанию включена защита от повторного связывания DNS. Это вызывало ошибку «канал открыт: сбой административно запрещено: сбой открытия» с SSH

В очень странном случае я также столкнулся с этой ошибкой при попытке создать локальный туннель. Моя команда была примерно такой:

ssh -L 1234:localhost:1234 user@remote

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

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

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

Похожая проблема

Еще одна возможная зацепка

У меня возникла такая же проблема при использовании ~/.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.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 и административно запрещено.

Насколько я понимаю, административно означает "из-за специфической конфигурации на стороне сервера".

У меня была такая же проблема, и я понял, что это 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)

В моем случае проблема была связана с запросом туннеля без доступа к оболочке, в то время как сервер пытался принудительно изменить пароль для моей учетной записи. Из-за отсутствия шелла я не мог этого увидеть и получил только ошибку

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!

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

Я получил эту ошибку при написании этой записи в моем блоге:

/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

Обратите внимание на разницу в case(заглавных букв )между 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 г.

Это также может быть вызвано невозможностью привязки к порту на локальной стороне.

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

Эта команда пытается связать прослушиваемый порт 1234 на локальном компьютере, который сопоставляется со службой на порту 5678 на удаленном компьютере.

Если порт 1234 на локальном компьютере уже используется другим процессом, (возможно, фоновый ssh ​​-f сеанс ), тогда ssh не сможет прослушивать этот порт и туннель не будет работать..

Проблема в том, что это сообщение об ошибке может означать несколько вещей, а фраза «административно запрещена» иногда дает неверное представление. Таким образом, в дополнение к проверке DNS, брандмауэров между локальным и удаленным и конфигурации sshd _, проверьте, не используется ли уже локальный порт. Используйте

lsof -ti:1234

, чтобы выяснить, какой процесс запущен на 1234. Вам может понадобиться sudo, чтобы lsof вывел список процессов, принадлежащих другим пользователям. Затем вы можете использовать

ps aux | grep <pid>

, чтобы выяснить, что это за процесс.

Чтобы получить все это одной командой:

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

Другая причина разрешения имен :Мой /etc/hosts имел ошибочный IP-адрес для имени сервера (не для локального хоста ), например:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Но настроенный IP-адрес сервера (и DNS-имя, разрешенное с помощью команд host/dig ), были 192.168.2.47. Простая опечатка, вызванная предыдущей реконфигурацией IP. После исправления /etc/hosts туннельное соединение работало безупречно:

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

Странно, что реальный IP-адрес вызвал сбой, когда я использовал литеральный IP-адрес локального хоста для туннеля. Дистрибутив :Ubuntu 16.04 LTS.

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

Похоже, это сообщение может быть вызвано многими причинами. В моем случае это была невозможность получить доступ к удаленному компьютеру, потому что я неправильно предоставил ключевой файл .

Опция -Lдобавляет неявный SSH-переход (, эффективно используя явный SSH-хост в качестве бастиона/сервера перехода ). Это может быть проще отладить, выполнив переход явно и создав оболочку входа на целевую машину с помощью «proxycommand».

Как только это заработает, вы можете выполнить переадресацию портов на основеlocalhost(целевой машины, предполагая, что она может войти в систему):

-N -L 1234:localhost:1234

Прошивка маршрутизатора Asus RT68U (Merlin Asus )имеет параметр, разрешающий переадресацию портов SSH, который необходимо включить:

Динамическая переадресация портов была настроена, как описано в:Устранение неполадок динамического туннеля

Проблема может быть связана с именем хоста назначения, если используется эта форма:

ssh -L 12345:destination:54321  tunnelhost

Убедитесь, что «назначение» разрешается из туннельного хоста. Чтобы решить мою проблему, мне пришлось использовать полное доменное имя для цели.

ssh -L 12345:destination.domain.host:54321  tunnelhost