"Canale 3: apertura non riuscita: amministrativamente vietata: apertura non riuscita" durante la creazione di una sessione VNC su un tunnel SSH

Durante la creazione di una connessione VNC tramite connessione SSH con tunnel, viene visualizzato un errore:

channel 3: open failed: administratively prohibited: open failed

Ho scoperto che ciò accade solo quando non sono connesso all'host localmente come usernamel'host su cui sto tentando di connettermi utilizzando una connessione VNC con tunnel. Tunnel SSH:

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

Connessione VNC:

vncviewer localhost:1

Ho provato a regolare le impostazioni /etc/ssh/sshd_configusando AllowTunnel yese senza l'impostazione. (Ho riavviato ssh dopo ogni modifica:) service ssh restartTuttavia, l'errore scompare se ho una sessione locale in esecuzione sull'host remoto (ovvero ho effettuato l'accesso come usernamelocale.) Qualcun altro vede questo comportamento? Sembra che dovrei essere in grado di avviare un VNC da remoto e accedervi senza dover accedere anche localmente.

— Mike Swartz
fonte

Mike, controlla il tour per vedere come funziona questo sito e se la mia risposta ha risolto il tuo problema, ti preghiamo di accettarlo.

— Jakuje,

Risposte:

L'opzione che stai cercando non è AllowTunnel(è per la VPN e l'inoltro di livello 3 utilizzando i tundispositivi). Stai cercando AllowTcpForwarding, che gestisce il port forwarding locale e remoto del traffico TCP in ssh.

Dai un'occhiata ai valori nel tuo server e modificalo in yes:

AllowTcpForwarding yes

— Jakuje
fonte

Grazie per la risposta rapida. Questo sembra aver risolto il mio problema. Avevo visto altri con lo stesso problema e un suggerimento era AllowTunnel yesin sshd_config, ma che non ha funzionato per me.

— Mike Swartz,

Probabilmente è una leggenda urbana, poiché anche l'altra risposta è arrivata qui. Non ho idea da dove provenga ed è così facile aprire la pagina del manuale e verificarne il significato. Se funziona per te, aspetta un secondo per controllare la risposta come soluzione per aiutare gli altri.

— Jakuje,

Perché il voto negativo?

— Jakuje,

AllowTcpForwarding Specifica se è consentito l'inoltro TCP. Le opzioni disponibili sono "yes" o "all" per consentire l'inoltro TCP, "no" per impedire tutto l'inoltro TCP, "local" per consentire solo l'inoltro locale (dal punto di vista di ssh (1)) o "remoto" per consentire remoto solo inoltro. L'impostazione predefinita è "sì".

— Bart Polot,

relativo (falso): serverfault.com/a/24389/328011

— YSC

Ho avuto una causa di risoluzione dei nomi per questo errore. I miei / etc / hosts avevano un indirizzo IP errato per il nome del server (non per localhost), in questo modo:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Ma l'IP del server configurato (e il nome DNS risolto con i comandi host / dig) era 192.168.2.47. Un semplice errore di battitura causato da una precedente riconfigurazione IP. Dopo aver corretto / etc / hosts la connessione al tunnel ha funzionato perfettamente:

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

È strano che l'IP reale abbia causato l'errore quando stavo usando l'IP letterale localhost per il tunnel. Distro: Ubuntu 16.04 LTS.

— Fjor
fonte