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

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

137 голосов | спросил Neil 1 J0000006Europe/Moscow 2011, 20:56:54

27 ответов


89
  

канал 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] Полный синтаксис в man-странице sshd_config(5).

[2] Полный синтаксис в man-странице authorized_keys(5).

ответил hyperair 18 TueEurope/Moscow2012-12-18T13:39:14+04:00Europe/Moscow12bEurope/MoscowTue, 18 Dec 2012 13:39:14 +0400 2012, 13:39:14
39

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

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

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

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

ответил cobbzilla 5 J0000006Europe/Moscow 2014, 01:16:23
19

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

ответил Neil 1 J0000006Europe/Moscow 2011, 20:59:38
13

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

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

ответил jacquesjtheron 20 AM000000110000000531 2013, 11:01:05
8

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

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

ответил Shadur 1 J0000006Europe/Moscow 2011, 23:28:36
8

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

ответил Matej Kovac 20 Maypm13 2013, 16:07:02
5

Аналогичная задача

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

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

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

ответил lauhub 22 J000000Friday16 2016, 13:31:01
4

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

AllowTcpForwarding no 

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

ответил user578125 29 Mayam13 2013, 02:03:49
2

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

  • проверьте, что переадресация портов включена в конфигурации пользователя ssh,
  • включить многословность ssh (-v),
  • проверить журналы ssh на локальном хосте и защищенные журналы на удаленном,
  • проверить различные удаленные порты,
  • проверьте настройки iptables (как сказал Шадур).
ответил Marco Solieri 2 J0000006Europe/Moscow 2011, 01:23:06
2

Я получил эту ошибку один раз для того, чтобы поместить пульт в параметр -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.
ответил Marciano 14 FriEurope/Moscow2012-12-14T00:37:50+04:00Europe/Moscow12bEurope/MoscowFri, 14 Dec 2012 00:37:50 +0400 2012, 00:37:50
2

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

ответил Leonardo Brunnet 4 +04002013-10-04T18:34:48+04:00312013bEurope/MoscowFri, 04 Oct 2013 18:34:48 +0400 2013, 18:34:48
2

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

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!

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

ответил Pieter Van Gorp 2 Mayam17 2017, 10:54:28
2

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

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

, чтобы он работал.

Я пытался rdesktop -L localhost:1234 следовать за инструкции по подключению к 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]
ответил tinlyx 30 SatEurope/Moscow2017-12-30T06:39:26+03:00Europe/Moscow12bEurope/MoscowSat, 30 Dec 2017 06:39:26 +0300 2017, 06:39:26
1

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

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

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

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

ответил Mike 18 PMpSat, 18 Apr 2015 22:44:03 +030044Saturday 2015, 22:44:03
1

Убедитесь, что /etc/resolv.conf пуст на сервере, которому вы являетесь ssh -ing. Несколько раз я обнаружил, что это связано с пустым файлом /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 на сервере, если это применимо.

ответил Ender 21 J000000Tuesday15 2015, 10:36:25
1

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

ответил Torxed 10 MarpmThu, 10 Mar 2016 17:26:43 +03002016-03-10T17:26:43+03:0005 2016, 17:26:43
0

Я видел эту ошибку на 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
ответил barlop 31 MarpmSat, 31 Mar 2012 14:40:34 +04002012-03-31T14:40:34+04:0002 2012, 14:40:34
0

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

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

ответил Andre M 19 12012vEurope/Moscow11bEurope/MoscowMon, 19 Nov 2012 03:20:00 +0400 2012, 03:20:00
0

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

ответил SlavaSt 18 PM00000090000003231 2015, 21:54:32
0

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

ответил meffect 24 +03002015-10-24T00:34:57+03:00312015bEurope/MoscowSat, 24 Oct 2015 00:34:57 +0300 2015, 00:34:57
0

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

ответил Data 20 FebruaryEurope/MoscowbMon, 20 Feb 2017 20:48:27 +0300000000pmMon, 20 Feb 2017 20:48:27 +030017 2017, 20:48:27
0

Мой случай:

$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)
ответил diyism 31 MarpmFri, 31 Mar 2017 13:11:24 +03002017-03-31T13:11:24+03:0001 2017, 13:11:24
0

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

/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 г.
ответил Zach Pfeffer 27 MaramTue, 27 Mar 2018 00:15:10 +03002018-03-27T00:15:10+03:0012 2018, 00:15:10
0

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

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

ответил Brad Dwyer 16 PMpMon, 16 Apr 2018 18:04:40 +030004Monday 2018, 18:04:40
0

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

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)"
ответил Mnebuerquo 23 PMpMon, 23 Apr 2018 20:37:07 +030037Monday 2018, 20:37:07
0

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

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

ответил Fjor 25 PMpWed, 25 Apr 2018 21:00:37 +030000Wednesday 2018, 21:00:37
0

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

ответил Philippe De Muyter 3 Maypm18 2018, 13:13:39

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132