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 in genere proviene da -D, -L O -w, Poiché sono necessari canali separati nel flusso SSH per trasferire i dati inoltrati.
Dato che stai usando -L (Applicabile anche a -D), Ci sono due opzioni in questione che fanno sì che il tuo server SSH respinga questa richiesta:
AllowTcpForwarding(come menzionato Steve Buzonas)PermitOpen
Queste opzioni sono disponibili in /etc/ssh/sshd_config. È necessario assicurarsi che:
AllowTCPForwardingnon è presente, è commentato o è impostato suyesPermitOpennon è presente, è commentato o è impostato suany[1]
Inoltre, se si utilizza una chiave SSH per connettersi, è necessario verificare che la voce corrispondente alla chiave SSH in ~/.ssh/authorized_keys Non abbia no-port-forwarding O permitopen istruzioni [2] .
Non rilevante per il tuo particolare comando, ma in qualche modo rilevante anche per questo argomento, è l'opzione PermitTunnel se stai tentando di usare l'opzione -w.
[1] Sintassi completa nella manpage sshd_config(5) .
[2] Sintassi completa nella manpage authorized_keys(5) .
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 [email protected]
Il problema era, sull'host remoto, /etc/hosts non aveva 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 quella di Neil - ma certamente ho scoperto che quello è il problema dalla mia parte) [Avevo un alias per il nome della macchina nel mio ~/.ssh/config file - e la macchina remota non sapeva nulla di quell'alias ...
Questo errore viene visualizzato definitivamente quando si utilizzano le opzioni ssh ControlPath e ControlMaster per condividere 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. La chiusura di eventuali 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.
Nel mio caso, ho dovuto sostituire localhost con 127.0.0.1 in:
ssh -L 1234:localhost:3389 [email protected]
per farlo funzionare.
Stavo cercando di rdesktop -L localhost:1234 seguendo Amazon istruzioni per la connessione ad AWS EC2 tramite tunneling SSH . Avevo provato a cambiare /etc/ssh/sshd_config (sia client che server eseguono Ubuntu 16.04 LTS) per la risposta più votata. Ho anche verificato che localhost sia in /etc/hosts su entrambi i lati.
Nulla ha funzionato fino a quando non ho cambiato il comando ssh in:
ssh -L 1234:127.0.0.1:3389 [email protected]
Un problema simile
Un altro possibile vantaggio
Ho avuto lo stesso problema usando ~/.ssh/authorized_keys con permitopen.
Poiché utilizzo autossh per 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 [email protected]
Ho ricevuto quel messaggio (dopo 10 minuti):
channel 2: open failed: administratively prohibited: open failed
Sul lato remoto
Mio /var/log/auth.log conteneva:
Received request to connect to Host 127.0.0.1 port 10001, but the request was denied.
Nel mio ~/.ssh/authorized_keys (lato remoto) Ho avuto 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 localhost istanze 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 in auth.log e il messaggio amministrativamente vietato.
Quello che ho capito qui è che amministrativamente significa "a causa di una configurazione specifica sul lato server".
Questo succede anche quando /etc/sshd_config ha
AllowTcpForwarding no
impostato. Passalo a yes per consentire TCP inoltro.
Ho ricevuto questo errore una volta per aver inserito il telecomando nel parametro -L, anche 0.0.0.0 è ridondante, puoi ometterlo con gli stessi risultati e penso che dovresti aggiungere -g affinché funzioni.
Questa è la linea che uso per il tunneling: ssh -L 8983:locahost:8984 [email protected] -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.
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).
Ciò può anche essere causato dall'incapacità di collegarsi alla porta sul lato locale.
ssh -Nn -L 1234:remote:5678 [email protected]
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, 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)"
Nel mio caso, il problema era dovuto alla richiesta di un tunnel senza accesso 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 accesso Shell e cambiando la password. Quindi potrei semplicemente utilizzare nuovamente i tunnel senza accesso Shell.
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 [email protected]: unknown Host (Name or service not known)
Questo potrebbe essere presentato se remote non è risolvibile o hai inserito una sintassi sconosciuta come ho fatto qui dove ho aggiunto un [email protected] alla logica port-forward (che non funzionerà).
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.
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 /etc/ssh/sshd_config Del server:
Match group sftponly
ForceCommand internal-sftp
ChrootDirectory /usr/chroot/%u
[...]
Match
Quindi, in questo caso, per usare SSH, dovrai rimuovere l'utente dal gruppo sftponly equivalente o collegarti usando un utente non limitato a SFTP.
Stavo ricevendo lo stesso messaggio durante il tunneling 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.
Controlla se /etc/resolv.conf È vuoto sul server a cui stai ssh. Più volte ho scoperto che ciò era correlato a un file /etc/resolv.conf Vuoto
Se non root, puoi semplicemente controllare sul server provando alcuni ping o telnet (80) su un nome host pubblico, ad es .:
[email protected] ~ # 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:
[email protected] ~ # 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.conf Era vuoto (di solito è popolato da record nameserver dal client dhcp sul server, se applicabile.
Ho ricevuto questo errore durante la scrittura di questa voce in il mio blog :
/etc/ssh/sshd_config aveva qualcosa del tipo:
Match Group SSHTunnel_RemoteAccessGroup
AllowTcpForwarding yes
PermitOpen=sshbeyondremote.server.com:22
Ma ~/.ssh/config aveva:
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 in case (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
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 [email protected] 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
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 :
[email protected]:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
[email protected]:~# service ssh restart
or
[email protected]:~# /etc/init.d/ssh restart
Una leggera aggiunta a uno dei commenti sopra: "Un errore di risoluzione DNS può causare questo errore" - assicurati anche di scrivere correttamente il tuo nome host.
Ho trascorso più di un'ora a cercare di eseguire il debug di tutte le impostazioni ssh e risulta che avevo appena scritto erroneamente amazonaws nel comando, che equivale alla nota di errore della risoluzione DNS sopra.
Il firmware del router Asus RT68U (Merlin Asus) ha un'impostazione che consente il port forwarding SSH, che deve essere abilitato:
Il port forwarding dinamico è stato impostato come descritto in: Risoluzione dei problemi del tunnel dinamico
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 :)
Controlla la protezione del tuo router DNS Rebinding . 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
Sembra che ci siano molte possibili cause alla radice per questo messaggio. Nel mio caso è stato impossibile accedere al telecomando perché non avevo fornito correttamente keyfile .
Il -L L'opzione 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 localhost della macchina target (supponendo che possa accedere a se stesso):
-N -L 1234:localhost:1234
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)
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 [email protected] -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.
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.
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 tornando al 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.