«Канал 3: открытие не удалось: административно запрещено: открытие не удалось» при создании сеанса VNC в туннеле SSH

При создании VNC-соединения через туннельное SSH-соединение я получаю сообщение об ошибке:

channel 3: open failed: administratively prohibited: open failed

Я обнаружил, что это происходит только тогда, когда я не вошел на хост локально, как usernameна хосте, к которому я пытаюсь подключиться, используя туннельное соединение VNC. Туннель SSH:

ssh -p 6000 -L 5901:127.0.0.1:5901 username@192.168.0.2

VNC соединение:

vncviewer localhost:1

Я попытался настроить параметры в /etc/ssh/sshd_configиспользовании AllowTunnel yesи без настройки. (Я перезапускал ssh после каждого изменения:) service ssh restartОднако ошибка исчезает, если на удаленном хосте запущен локальный сеанс (т. Е. Я вошел в систему как usernameлокально.) Кто-нибудь еще видит такое поведение? Кажется, что я должен иметь возможность запустить VNC удаленно и получить доступ к нему без необходимости входить локально.

— Майк Шварц
источник

Майк, пожалуйста, проверь тур, чтобы увидеть, как работает этот сайт, и если мой ответ решил твою проблему, прими его.

— Jakuje

Ответы:

Опция, которую вы ищете, - нет AllowTunnel(она предназначена для VPN и переадресации уровня 3 с использованием tunустройств). Вы ищете AllowTcpForwarding, который обрабатывает локальную и удаленную переадресацию портов TCP-трафика в SSH.

Посмотрите, какие значения на вашем сервере и измените его на yes:

AllowTcpForwarding yes

— Jakuje
источник

Спасибо за быстрый ответ. Кажется, это исправило мою проблему. Я видел другие с той же проблемой , и одно предложение было AllowTunnel yesв sshd_config, но это не работа для меня.

— Майк Шварц

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

— Jakuje

Почему отрицательный голос?

— Jakuje

AllowTcpForwarding Указывает, разрешена ли пересылка TCP. Доступны следующие опции: «да» или «все», чтобы разрешить пересылку TCP, «нет», чтобы запретить всю пересылку TCP, «локальный», чтобы разрешить только локальную (с точки зрения ssh (1)) пересылку, или «удаленный», чтобы разрешить удаленную пересылку. только пересылка. По умолчанию «да».

— Барт

Похожая (ложь): serverfault.com/a/24389/328011

— СМУ

У меня была причина разрешения имени для этой ошибки. Мой / 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.

— Fjor
источник