Ошибка туннелирования 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, и когда я подключил браузер к этому серверу comp-socks, он просматривал, но на компе, где я запускал команду 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 hosts и добавить сервис, к которому вы хотите получить доступ.

Мое дело:

$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-имя, разрешенное с помощью команд host / dig) был 192.168.2.47. Простая опечатка, вызванная предыдущей реконфигурацией IP. После исправления / etc / hosts туннельное соединение работало безупречно:

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

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

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

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

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

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

-N -L 1234:localhost:1234