Errore tunneling SSH: "canale 1: apertura non riuscita: amministrativamente vietata: apertura non riuscita"

Quando apro questo tunnel ssh:

ssh -nXNT -p 22 localhost -L 0.0.0.0:8984:remote:8983

Ottengo questo errore quando provo ad accedere al server HTTP in esecuzione su localhost: 8984:

channel 1: open failed: administratively prohibited: open failed

Cosa significa questo errore e su quale macchina è possibile risolvere il problema?

canale 1: apertura non riuscita: amministrativamente vietata: apertura non riuscita

Il messaggio sopra si riferisce al server SSH che rifiuta la richiesta del client SSH di aprire un canale laterale. Questo viene tipicamente da -D, -Lo -w, come canali separati nel flusso SSH sono tenuti a traghettare i dati trasmessi attraverso.

Dal momento che stai utilizzando -L(applicabile anche a -D), ci sono due opzioni in questione che fanno sì che il tuo server SSH rifiuti questa richiesta:

• AllowTcpForwarding (come menzionato Steve Buzonas)
• PermitOpen

Queste opzioni sono disponibili in /etc/ssh/sshd_config. È necessario assicurarsi che:

• AllowTCPForwarding non è presente, è commentato o è impostato su yes
• PermitOpennon è presente, è commentato o è impostato su any[1]

Inoltre, se si utilizza una chiave SSH per connettersi, è necessario verificare che la voce corrispondente alla chiave SSH in ~/.ssh/authorized_keysnon contenga no-port-forwardingo permitopenistruzioni [2].

Non rilevante per il tuo particolare comando, ma in qualche modo rilevante anche per questo argomento, è l' PermitTunnelopzione se stai tentando di usare l'opzione -w.

[1] Sintassi completa nella sshd_config(5)manpage.

[2] Sintassi completa nella authorized_keys(5)manpage.

In un caso molto strano, ho anche riscontrato questo errore durante il tentativo di creare un tunnel locale. Il mio comando era qualcosa del genere:

ssh -L 1234:localhost:1234 user@remote

Il problema era che sull'host remoto /etc/hostsnon c'erano voci per "localhost", quindi il server ssh non sapeva come impostare il tunnel. Un messaggio di errore molto ostile per questo caso; felice di averlo finalmente capito.

La lezione: assicurati che il nome host di destinazione del tuo tunnel sia risolvibile dall'host remoto, tramite DNS o /etc/hosts.

Almeno una risposta è che la macchina "remota" non è raggiungibile con ssh per qualche motivo. Il messaggio di errore è semplicemente assurdo.

Se il "telecomando" non può essere risolto sul server, verrà visualizzato l'errore. Sostituisci con un indirizzo IP e vedi se il problema si risolve ...

(Fondamentalmente la stessa risposta di Neil - ma certamente ho scoperto che quello era il problema dalla mia parte) [Avevo un alias per il nome della macchina nel mio ~/.ssh/configfile - e la macchina remota non sapeva nulla di quell'alias ...

Questo errore viene visualizzato definitivamente quando si utilizzano le opzioni ssh ControlPathe ControlMasterper la condivisione di una connessione socket da riutilizzare tra più connessioni client (da un client allo stesso utente @ server). Aprire troppe (qualunque cosa significhi, nel mio caso ~ 20 connessioni) produce questo messaggio. Chiudere tutte le connessioni precedenti mi consente di aprire più recenti, di nuovo fino al limite.

"Amministrativamente vietato" è un flag di messaggio ICMP specifico che si riduce a "L'amministratore vuole esplicitamente bloccare questa connessione".

Controlla le impostazioni di iptables.

Un problema simile

Un altro possibile vantaggio

Ho avuto lo stesso problema ~/.ssh/authorized_keyscon permitopen.

Mentre utilizzo autosshper creare un tunnel, ho bisogno di due porte:

• uno per la connessione (10000),
• uno per il monitoraggio (10001).

Dal lato client

Questo mi ha dato un problema simile con la porta di monitoraggio:

autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60  -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa user@remote

Ho ricevuto quel messaggio (dopo 10 minuti):

channel 2: open failed: administratively prohibited: open failed

Sul lato remoto

Il mio /var/log/auth.logcontenuto:

Received request to connect to host 127.0.0.1 port 10001, but the request was denied.

Nel mio ~/.ssh/authorized_keys(lato remoto) avevo questo:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa AAAA...

Come risolverlo

Ho risolto questo problema sostituendo le localhostistanze con 127.0.0.1:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="127.0.0.1:10000",permitopen="127.0.0.1:10001" ssh-rsa AAAA...

Sembra che SSH non capisca che localhostè un collegamento a 127.0.0.1, quindi il messaggio auth.loge il messaggio amministrativamente proibito .

Quello che ho capito qui è che amministrativamente significa "a causa di una configurazione specifica sul lato server".

Questo succede anche quando /etc/sshd_configha

AllowTcpForwarding no 

impostato. Passare a yesper consentire l'inoltro TCP.

Nel mio caso, ho dovuto sostituire localhostcon 127.0.0.1in:

ssh -L 1234:localhost:3389 user@remote

per farlo funzionare.

Stavo cercando di rdesktop -L localhost:1234seguire le istruzioni di Amazon sul collegamento ad AWS EC2 tramite tunneling SSH . Avevo provato a cambiare /etc/ssh/sshd_config(sia client che server eseguono Ubuntu 16.04 LTS) in base alla risposta più votata. Ho anche verificato che si localhosttrova /etc/hostssu entrambi i lati.

Niente ha funzionato fino a quando non ho cambiato il sshcomando stesso in:

ssh -L 1234:127.0.0.1:3389 user@remote

Sono necessarie alcune attività di risoluzione dei problemi per trovare una risposta definitiva:

• controlla che il port forwarding sia abilitato nella configurazione ssh dell'utente,
• abilita la verbosità di ssh (-v),
• controlla i registri ssh sull'host locale e registri sicuri su quello remoto,
• testare diverse porte remote,
• controlla le impostazioni del tuo iptables (come ha detto Shadur).

Ho ricevuto questo errore una volta per aver inserito il telecomando nel parametro -L, inoltre 0.0.0.0 è ridondante, puoi ometterlo con gli stessi risultati e penso che dovresti aggiungere -g affinché funzioni.

Questa è la linea che utilizzo per il tunneling: 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.

Ciò può anche essere causato dall'incapacità di collegarsi alla porta sul lato locale.

ssh -Nn -L 1234:remote:5678 user@remote

Questo comando sta tentando di associare una porta di ascolto 1234 sul computer locale, che esegue il mapping a un servizio sulla porta 5678 su un computer remoto.

Se la porta 1234 sul computer locale è già utilizzata da un altro processo, (forse una sessione ssh -f in background), allora ssh non sarà in grado di ascoltare su quella porta e il tunnel fallirà.

Il problema è che questo messaggio di errore può significare una qualsiasi delle varie cose e "amministrativamente vietato" a volte dà l'idea sbagliata. Quindi oltre a controllare DNS, i firewall tra locale e remoto e sshd_config, controlla se la porta locale è già utilizzata. Uso

lsof -ti:1234

per capire quale processo è in esecuzione su 1234. Potrebbe essere necessario sudo per lsof per elencare i processi di proprietà di altri utenti. Quindi puoi usare

ps aux | grep <pid>

per scoprire cos'è questo processo.

Per ottenere tutto in un solo comando:

ps aux | grep "$(sudo lsof -ti:1234)"

Ho avuto lo stesso messaggio mentre cercavo di scavare un tunnel. Si è verificato un problema con il server DNS sul lato remoto. Il problema è stato risolto quando è tornato al lavoro.

Sono estremamente sorpreso che nessuno abbia menzionato che questo potrebbe essere un problema DNS.

journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to user@example.com: unknown host (Name or service not known)

Questo potrebbe essere presentato se remotenon è risolvibile o hai inserito una sintassi sconosciuta come ho fatto qui in cui ho aggiunto un user@alla logica port-forward (che non funzionerà).

Nel mio caso, il problema era dovuto alla richiesta di un tunnel senza accesso alla shell mentre il server mirava a forzare una modifica della password sul mio account. A causa della mancanza di una shell, non riuscivo a vederlo e ho ricevuto solo l'errore

channel 2: open failed: administratively prohibited: open failed  

La mia configurazione del tunnel era la seguente:

ssh -p [ssh-port] -N -f -L [local-port]:127.0.0.1:[remote-port]
[server-address]

L'errore ha mostrato quando si accede direttamente al server (senza -N -f):

WARNING: Your password has expired. You must change your password now
and login again!

Ho risolto il problema accedendo con l'accesso alla shell e cambiando la password. Quindi potrei semplicemente usare nuovamente i tunnel senza accesso alla shell.

Ho riscontrato questo problema durante il tentativo di connessione tramite SSH con un utente autorizzato a connettersi solo tramite SFTP.

Ad esempio, questo era nel server /etc/ssh/sshd_config:

Match group sftponly
    ForceCommand internal-sftp
    ChrootDirectory /usr/chroot/%u
    [...]
Match

Quindi, in questo caso, per utilizzare SSH, dovrai rimuovere l'utente dal sftponlygruppo equivalente o collegarti utilizzando un utente non limitato a SFTP.

Controlla se /etc/resolv.confè vuoto sul server a cui stai andando ssh. Più volte ho scoperto che ciò era correlato a un /etc/resolv.conffile vuoto

Se non root, puoi semplicemente controllare sul server provando alcuni pingo telnet(80) su un nome host pubblico, ovvero:

root@bananapi ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

Dopo aver aggiunto i record del nameserver a /etc/resolv.conf:

root@bananapi ~ # telnet www.google.com 80
Trying 74.125.195.104...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 302 Found
Location: http://www.google.ro/?gws_rd=cr&ei=8fStVZ-hMIv6UvX6iuAK

Tuttavia, dovresti anche controllare perché /etc/resolv.confera vuoto (di solito è popolato con record nameserver dal client dhcp sul server, se applicabile.

Stavo ricevendo lo stesso messaggio mentre sintonizzavo SSH su Debian. Si è scoperto che il sistema remoto non aveva spazio libero. Dopo aver liberato spazio su disco e riavviato, il tunnel ha iniziato a funzionare.

Ho visto questo errore su Cygwin e questo dovrebbe essere vero anche per Linux e ha funzionato per me. Nel mio caso avevo fatto ssh -ND *: 1234 user@127.0.0.1 e quando ho collegato un browser a quel server comp-socks, ha navigato, ma sul comp dove ho eseguito quel comando ssh ho avuto l'errore che appare su la console con ogni richiesta - almeno per un sito, anche se il browser lo ha recuperato attraverso il proxy o sembrava, almeno nella misura in cui ho visto l'età principale. Ma apportare questa modifica ha eliminato il messaggio non riuscito

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

Un altro scenario è che il servizio a cui stai tentando di accedere non è in esecuzione. Mi sono imbattuto in questo problema l'altro giorno solo per ricordare che l'istanza httpd a cui stavo cercando di connettermi era stata interrotta.

I tuoi passi per risolvere il problema sarebbero iniziare con il più semplice, che sta andando sull'altra macchina e vedendo se riesci a connetterti localmente e poi lavorando di nuovo verso il tuo computer client. Almeno questo ti permetterà di capire a che punto la comunicazione non sta avvenendo. Puoi adottare altri approcci, ma questo ha funzionato per me.

Controlla la protezione del tuo rebinding DNS sul tuo router . Il mio router (pfsense) ha la protezione Rebinding DNS abilitata per impostazione predefinita. Stava causando l'errore "canale aperto: fallito amministrativamente proibito: apertura fallita" con SSH

Ho avuto lo stesso problema e mi sono reso conto che si trattava di DNS. Il traffico è sotto tunnel ma la richiesta DNS n. Prova a modificare manualmente il file degli host DNS e aggiungi il servizio a cui desideri accedere.

Il mio caso:

$ssh -D 8081 localhost >>log1.txt 2>&1 &

----wait for 3 days

$tail -f log1.txt
channel 963: open failed: connect failed: Connection refused
channel 963: open failed: connect failed: Connection refused
channel 971: open failed: connect failed: Connection reset by peer
channel 982: open failed: connect failed: Connection timed out
channel 979: open failed: connect failed: Connection timed out
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed

$ps  axu | grep 8081
root       404  0.0  0.0   4244   592 pts/1    S+   05:44   0:00 grep --color=auto 8081
root       807  0.3  0.6   8596  6192 ?        S    Mar17  76:44 ssh -D 8081 localhost

$lsof -p 807 | grep TCP
ssh     807 root 1013u  sock     0,8      0t0 2076902 protocol: TCP
ssh     807 root 1014u  sock     0,8      0t0 2078751 protocol: TCP
ssh     807 root 1015u  sock     0,8      0t0 2076894 protocol: TCP
.....

$lsof -p 807 | wc -l
1047

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   malcolm-desktop

$ssh localhost
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-53-generic i686)

----after restart ssh -D 8081 localhost
$ lsof -p 1184 | grep TCP
ssh     1184 root    3u  IPv4 2332193      0t0   TCP localhost:37742->localhost:ssh (ESTABLISHED)
ssh     1184 root    4u  IPv6 2332197      0t0   TCP ip6-localhost:tproxy (LISTEN)
ssh     1184 root    5u  IPv4 2332198      0t0   TCP localhost:tproxy (LISTEN)
ssh     1184 root    6u  IPv4 2332215      0t0   TCP localhost:tproxy->localhost:60136 (ESTABLISHED)
ssh     1184 root    7u  IPv4 2336142      0t0   TCP localhost:tproxy->localhost:32928 (CLOSE_WAIT)
ssh     1184 root    8u  IPv4 2336062      0t0   TCP localhost:tproxy->localhost:32880 (CLOSE_WAIT)

Ho ricevuto questo errore durante la scrittura di questa voce nel mio blog :

/etc/ssh/sshd_config aveva qualcosa del tipo:

Match Group SSHTunnel_RemoteAccessGroup
    AllowTcpForwarding yes
    PermitOpen=sshbeyondremote.server.com:22

Ma ~/.ssh/configaveva:

Host remote.server.com
  HostName remote.server.com
  Port 10022
  User useronremote
  IdentityFile ~/.ssh/keys/key1/openssh.keyforremote.priv
  LocalForward 2222 SSHBeyondRemote.server.com:22

Nota la differenza nel caso (maiuscole) tra SSHBeyondRemote.server.com:22 e sshbeyondremote.server.com:22 .

Una volta risolto il caso, non vedevo più il problema.

Stavo usando:

Versione del client OpenSSH:

• OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 marzo 2016

Versione del server OpenSSH:

• OpenSSH_7.6p1 Debian-4, OpenSSL 1.0.2n 7 dic 2017

Altra causa di risoluzione dei nomi: 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.

Il motivo per cui ho avuto quel messaggio non è il più comune, ma vale la pena menzionarlo. Avevo generato da script un elenco di tunnel e, per garantire una presentazione di colonna, avevo stampato l'ultimo byte su due byte. Quando ho provato ad aprire il tunnel forwarding al 192.168.66.08, ha sempre fallito, perché '08' è interpretato da gethostbyaddr come un numero ottale non valido :)

Sembra che ci siano molte possibili cause alla radice per questo messaggio. Nel mio caso era impossibile accedere al telecomando perché non avevo fornito correttamente il file di chiavi .

L' -Lopzione aggiunge un salto SSH implicito (utilizzando efficacemente l'host SSH esplicito come server bastion / jump). Potrebbe essere più semplice eseguire il debug eseguendo il salto in modo esplicito e creando una shell di accesso al computer di destinazione utilizzando "proxycommand".

Una volta che funziona, puoi eseguire il port forwarding in base al computer di destinazione localhost(supponendo che possa accedere a se stesso):

-N -L 1234:localhost:1234