„Kanał 3: otwarte niepowodzenie: zabronione administracyjnie: otwarte niepowodzenie” podczas tworzenia sesji VNC w tunelu SSH

Podczas tworzenia połączenia VNC za pośrednictwem tunelowanego połączenia SSH pojawia się błąd:

channel 3: open failed: administratively prohibited: open failed

Odkryłem, że dzieje się tak tylko wtedy, gdy nie jestem zalogowany lokalnie na hoście, ponieważ usernamena hoście próbuję się połączyć za pomocą tunelowanego połączenia VNC. Tunel SSH:

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

Połączenie VNC:

vncviewer localhost:1

Próbowałem dostosować ustawienia przy /etc/ssh/sshd_configużyciu AllowTunnel yesi bez ustawienia. (Ponownie uruchomiłem ssh po każdej zmianie:) service ssh restartJednak błąd znika, jeśli mam sesję lokalną uruchomioną na zdalnym hoście (tj. Jestem zalogowany usernamelokalnie). Czy ktoś widzi to zachowanie? Wygląda na to, że powinienem być w stanie uruchomić VNC zdalnie i uzyskać do niego dostęp bez konieczności lokalnego logowania.

— Mike Swartz
źródło

Mike, sprawdź prezentację, aby zobaczyć, jak działa ta strona. Jeśli moja odpowiedź rozwiązała Twój problem, zaakceptuj ją.

— Jakuje

Odpowiedzi:

Opcja, której szukasz, nie jest AllowTunnel(dotyczy VPN i przekazywania poziomu 3 za pomocą tunurządzeń). Szukasz AllowTcpForwarding, który obsługuje lokalne i zdalne przekierowywanie portów ruchu TCP w ssh.

Sprawdź, jakie wartości są na twoim serwerze i zmień je na yes:

AllowTcpForwarding yes

— Jakuje
źródło

Dzięki za szybką odpowiedż. Wydaje się, że to rozwiązało mój problem. Widziałem ludzi o tym samym numerze i jedna sugestia było AllowTunnel yesw sshd_config, ale to nie dla mnie.

— Mike Swartz,

Jest to prawdopodobnie jakaś miejska legenda, ponieważ przyszła tu także inna odpowiedź. Nie mam pojęcia, skąd się wziął i tak łatwo jest otworzyć stronę podręcznika i sprawdzić jej znaczenie. Jeśli to działa, poczekaj chwilę, aby sprawdzić odpowiedź jako rozwiązanie, aby pomóc innym.

— Jakuje,

Dlaczego głosowanie w dół?

— Jakuje

AllowTcpForwarding Określa, czy dozwolone jest przekazywanie TCP. Dostępne opcje to „tak” lub „wszystkie”, aby zezwolić na przekazywanie TCP, „nie”, aby uniemożliwić wszystkie przekazywanie TCP, „lokalne”, aby zezwolić tylko na lokalne (z perspektywy ssh (1)) lub „zdalne”, aby umożliwić zdalne tylko przekazywanie. Domyślna wartość to „tak”.

— Bart Polot,

powiązane (fałszywe): serverfault.com/a/24389/328011

— YSC

Miałem przyczynę rozpoznania nazwy tego błędu. Mój / etc / hosts miał błędny adres IP dla nazwy serwera (nie dla localhost), jak poniżej:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Ale skonfigurowany adres IP serwera (i nazwa DNS rozwiązana za pomocą komend host / dig) to 192.168.2.47. Prosta literówka spowodowana poprzednią rekonfiguracją adresu IP. Po naprawieniu / etc / hosts połączenie tunelowe działało bezbłędnie:

ssh user@server.domain.com -L 3456:127.0.0.1:5901

To dziwne, że prawdziwe IP spowodowało awarię, gdy używałem dosłownie adresu IP hosta lokalnego dla tunelu. Distro: Ubuntu 16.04 LTS.

— Fjor
źródło