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

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

203
02.06.2011, 01:05
11 ответов

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

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

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

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

8
27.01.2020, 19:27
  • 1
    Не обязательно. Сообщение сгенерировано, когда хост не может служить запросу. Случай обычно, потому что администратор заблокировал соединение, но это может также быть, это - это не явно заблокированный, но нет никакого маршрута к желаемому узлу. AFAIK ssh не имеет никакой логики для определения, почему связь прервалась, она просто предполагает, что, при попытке соединиться, затем она существует, и если Вы не можете добраться там, соединение, должно быть, было заблокировано намеренно. –  Steve Buzonas 03.06.2012, 00:11
  • 2
    Мм, нет. Существуют явные различия между типом ответа ICMP, который не говорит "маршрута для хостинга" и тот, который говорит "административно запрещенный", и если кто-то сознательно не неправильно сконфигурировал маршрутизатор, последние средства точно, что это говорит относительно олова. –  Shadur 04.01.2014, 01:07
  • 3
    я просто был 'административно запрещен' при использовании имени хоста, которое не решало, таким образом, это, действительно кажется, вместилище. Возможно, ssh делает некоторый перевод? –  GS - Apologise to Monica 23.09.2014, 08:38

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

26
27.01.2020, 19:27
  • 1
    Нет это не; я использую icmp-admin-prohibited в качестве флага отклонения в конфигурациях брандмауэра все время. –  Shadur 01.06.2011, 22:29
  • 2
    +1, административно запрещенное сообщение заставило бы полагать, что это - блокировка брандмауэра, однако Вы получаете то же сообщение, когда нет никакой блокировки брандмауэра, но открытых сбоев, потому что нет никакого маршрута к удаленному хосту. –  Steve Buzonas 03.06.2012, 00:04
  • 3
    я только что провел несколько минут, ища эту проблему, сообщение которой не имеет никакого смысла в моем контексте вниз. К счастью это довольно ясно после проверки средних файлов рабочего журнала станции. –  yaccz 10.06.2013, 23:46
  • 4
    Действительно, если "удаленный" недостижимо - потому что это снижается, офлайн, не существует, имя хоста не решает - затем Вы будете видеть это сообщение об ошибке. –  Michael Martinez 09.09.2015, 01:39

Я видел эту ошибку на 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
0
27.01.2020, 19:27
  • 1
    AFAIK включено по умолчанию, потому что отключение не добавляет уровня безопасности, прежде всего, просто неудобство добавления стороннего туннеля. У меня есть подобная проблема при попытке проксировать к внутренним серверам от от местоположения сайта, и туннелирование включено + iptables сброшенное с действием по умолчанию к ACCEPT. –  Steve Buzonas 02.06.2012, 06:09
  • 2
    @SteveBuzonas я вижу это в/etc/sshd_config так a), он не отключает туннелирование b) в отношении моего ответа, решение, там может не быть хорошая идея. Вот то, что sshd_config говорит о той опции #, Чтобы отключить туннелировавшие пароли в виде открытого текста, измениться на не здесь! #PermitTunnel никакая проверка –  barlop 02.06.2012, 11:05
  • 3
    @SteveBuzonas Ваша, на которую это, вероятно, установлено не и можно туннелировать, поскольку действительно туннелирование включено по умолчанию. –  barlop 02.06.2012, 11:06
  • 4
    , о котором я думал AllowTCPForwarding, Комментарий Вы говорите о # To disable tunneled clear text в отношении PasswordAuthentication будучи установленным на не, PermitTunnel установка должна позволить сетевые туннели уровня 2 или уровня 3 через бочку/касание и значения по умолчанию к нет. L, R, и опции D используют передачу TCP и не устройство для туннелирования. –  Steve Buzonas 03.06.2012, 00:00

канал 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) страница справочника.

131
27.01.2020, 19:27
  • 1
    Здесь, что я конкретно добавляю в sshd_config, чтобы заставить его работать: TCPKeepAlive да AllowTCPForwarding да PermitOpen, который любой, у меня есть некоторые, "открывает отказавший", но это кажется нормальной вещью. Вещи работают очень хорошо. –  Pierre Thibault 17.01.2015, 08:58
  • 2
    угловой случай для замечания: можно получить эту ошибку при попытке создать устройство касания/бочки с SSH, и SSH позволяет его, но ядро не делает. Это может произойти в контейнерах LXC. См. blog.felixbrucker.com/2015/10/01 / … для точных деталей, но в этом случае можно хотеть добавить lxc.cgroup.devices.allow = c 10:200 rwm к конфигурации Вашего контейнера, и гарантируют это если /dev/net/tun не существует, mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tun выполняется на начальной загрузке в контейнере. –  Azendale 16.04.2016, 03:58
  • 3
    @Azendale, это интересно, спасибо. Это приводит к тому же самому сообщению об ошибке или чему-то немного отличающемуся? –  hyperair 10.05.2016, 10:52

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

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

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

0
27.01.2020, 19:27
  • 1
    полезный общий совет, но не ответ на поставленный вопрос. –  Kyle Jones 19.11.2012, 08:24

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

AllowTcpForwarding no 

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

4
27.01.2020, 19:27

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

10
27.01.2020, 19:27
  • 1
    , который я приехал, сюда ища, где установить этот предел мультиплексирования ControlMaster. Если кто-либо знает, они - больше, чем приветствие для совместного использования. –  clacke 17.07.2013, 03:55
  • 2
    clacke: согласно bugs.debian.org/cgi-bin/bugreport.cgi?bug=546854 можно добавить параметр MaxSession в/etc/ssh/sshd_config файле для установки этого. Согласно странице справочника, это установлено на 10 по умолчанию. –  oliver 23.10.2013, 13:36
  • 3
    @oliver: подтверждение, работы MaxSession, спасибо. ударенный к 64 на моей рабочей книге. –  Matej Kovac 03.04.2014, 11:58
  • 4
    Будьте осторожны, это не MaxSession но MaxSessions. Хотя существуют некоторые меры защиты, не повреждайте свою ssh конфигурацию сервера... –  Stéphane Gourichon 30.01.2015, 16:36

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

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

19
27.01.2020, 19:27
  • 1
    Можно также видеть ту же ошибку при использовании -D (DynamicForward) как SOCKS проксируют в браузере. Т.е. попытка получить доступ к веб-сайту, который не может разрешить туннельный хост. –  timss 02.09.2016, 12:05

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

2
27.01.2020, 19:27

Теги

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