it-swarm-ru.tech

Ошибка туннелирования 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

Что означает эта ошибка, и на какой машине вы можете решить проблему?

210
Neil

канал 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) .

134
hyperair

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

ssh -L 1234:localhost:1234 [email protected]

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

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

55
cobbzilla

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

27
Neil

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

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

19
jacquesjtheron

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

11
Matej Kovac

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

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

8
Shadur

В моем случае мне пришлось заменить localhost на 127.0.0.1 в:

ssh -L 1234:localhost:3389 [email protected]

чтобы это работало.

Я пытался 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 [email protected]
6
tinlyx

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

Еще одно возможное преимущество

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

У меня было это сообщение (через 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 и ​​административно запрещено сообщение.

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

5
lauhub

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

AllowTcpForwarding no 

набор. Переключите его на yes, чтобы разрешить TCP пересылку).

4
user578125

Однажды я получил эту ошибку за то, что отдал пульт в параметре -L, также 0.0.0.0 является избыточным, вы можете опустить его с теми же результатами, и я думаю, что вы должны добавить -g, чтобы он работал.

Это линия, которую я использую для туннелирования: ssh -L 8983:locahost:8984 [email protected] -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.
3
Marciano

Некоторые действия по устранению неполадок необходимы, чтобы найти окончательный ответ:

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

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

ssh -Nn -L 1234:remote:5678 [email protected]

Эта команда пытается связать прослушивающий порт 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)"
3
Mnebuerquo

В моем случае проблема была связана с запросом туннеля без доступа 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.

2
Pieter Van Gorp

Я очень удивлен, что никто не упомянул, что это может быть проблемой DNS.

journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to [email protected]: unknown Host (Name or service not known)

Это может быть представлено, если remote не разрешимо или вы ввели неизвестный синтаксис, как я сделал здесь, где я добавил [email protected] к логике переадресации порта (которая не будет работать).

2
Torxed

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

2
Leonardo Brunnet

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

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

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

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

1
Mike

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

1
SlavaSt

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

Если не root, вы можете просто проверить на сервере, попробовав несколько ping или telnet (80) для публичного имени хоста, т.е.

[email protected] ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

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

[email protected] ~ # 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 на сервере, если это применимо).

1
Ender

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

/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 г.
0
Zach Pfeffer

Я видел эту ошибку на Cygwin, и это должно быть верно и для Linux и работал для меня. В моем случае я сделал ssh -ND *: 1234 [email protected] и когда я подключил браузер к этому серверу 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 :
[email protected]:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
[email protected]:~# service ssh restart
or

[email protected]:~# /etc/init.d/ssh restart
0
barlop

Небольшое дополнение к одному из комментариев выше: "Ошибка разрешения DNS может вызвать эту ошибку" - также убедитесь, что вы правильно указали имя своего хоста.

Я потратил более часа, пытаясь отладить все настройки ssh, и оказалось, что я только что написал в команде amazonaws, что эквивалентно приведенному выше примечанию об ошибке разрешения DNS.

0
Brad Dwyer

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

enter image description here

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

0
gatorback

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

0
Philippe De Muyter

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

0
meffect

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

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

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

-N -L 1234:localhost:1234
0
nobar

Мое дело:

$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)
0
diyism

Другая причина разрешения имен: Мой/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 [email protected] -L 3456:127.0.0.1:5901

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

0
Fjor

У меня была та же проблема, и я понял, что это был DNS. Трафик туннелируется, но DNS-запроса нет. Попробуйте вручную отредактировать файл DNS hosts и добавить сервис, к которому вы хотите получить доступ.

0
Data

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

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

0
Andre M