"Канал 3: відкрито не вдалося: адміністративно заборонено: відкрито не вдалося" під час створення сеансу VNC в тунелі SSH


10

Створюючи з'єднання 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 та отримувати доступ до нього, не маючи необхідності також увійти в систему на локальному рівні.


1
Майк, будь ласка, перегляньте тур, щоб побачити, як працює цей сайт, і якщо моя відповідь вирішила вашу проблему, прийміть її.
Jakuje

Відповіді:


14

Шукаєте, що це не так AllowTunnel(це для переадресації VPN та рівня 3 за допомогою tunпристроїв). Ви шукаєте AllowTcpForwarding, який обробляє локальну та віддалену переадресацію порту TCP-трафіку в ssh.

Подивіться, які значення знаходяться на вашому сервері, і змініть його на yes:

AllowTcpForwarding yes

Дякую за швидку відповідь. Можливо, це вирішило мою проблему. Я бачив інші з тією ж проблемою , і одне речення було AllowTunnel yesв sshd_config, але це не робота для мене.
Майк Сварц

1
Це, мабуть, якась міська легенда, як і інша відповідь. Поняття не має, звідки воно взялося, і так просто відкрити сторінку керівництва і перевірити значення. Якщо це працює для вас, майте на секунду перевірити відповідь як рішення, щоб допомогти іншим.
Jakuje

1
Чому голосування вниз?
Якову

AllowTcpForwarding Вказує, чи дозволено переадресація TCP. Доступні параметри "так" або "всі", щоб дозволити переадресацію TCP, "ні", щоб запобігти переадресації TCP, "локальний", щоб дозволити місцеве (з точки зору ssh (1)) лише переадресації, або "віддалений", щоб дозволити віддалене тільки переадресація За замовчуванням - «так».
Барт Полот


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 user@server.domain.com -L 3456:127.0.0.1:5901

Дивно, що справжній IP викликав збій, коли я використовував localhost literal IP для тунелю. Distro: Ubuntu 16.04 LTS.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.