it-swarm.it

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?

210
Neil

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:

  • AllowTCPForwarding non è presente, è commentato o è impostato su yes
  • PermitOpen non è 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_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) .

134
hyperair

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.

55
cobbzilla

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

27
Neil

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 ...

19
jacquesjtheron

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.

11
Matej Kovac

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

Controlla le impostazioni di iptables.

8
Shadur

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]
6
tinlyx

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".

5
lauhub

Questo succede anche quando /etc/sshd_config ha

AllowTcpForwarding no 

impostato. Passalo a yes per consentire TCP inoltro.

4
user578125

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.
3
Marciano

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).
3
Marco Solieri

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)"
3
Mnebuerquo

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.

2
Pieter Van Gorp

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à).

2
Torxed

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.

2

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.

1
Mike

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.

1
SlavaSt

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.

1
Ender

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
0
Zach Pfeffer

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

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 :
[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
0
barlop

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.

0
Brad Dwyer

Il firmware del router Asus RT68U (Merlin Asus) ha un'impostazione che consente il port forwarding SSH, che deve essere abilitato:

enter image description here

Il port forwarding dinamico è stato impostato come descritto in: Risoluzione dei problemi del tunnel dinamico

0
gatorback

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 :)

0

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

0
meffect

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
0
nobar

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)
0
diyism

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.

0
Fjor

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.

0
Data

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.

0
Andre M