Błąd tunelowania SSH: „kanał 1: otwarcie nie powiodło się: administracyjnie zabronione: otwarcie nie powiodło się”

Kiedy otwieram ten tunel ssh:

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

Otrzymuję ten błąd podczas próby uzyskania dostępu do serwera HTTP działającego na localhost: 8984:

channel 1: open failed: administratively prohibited: open failed

Co oznacza ten błąd i na jakim komputerze możesz rozwiązać problem?

kanał 1: otwarcie nie powiodło się: administracyjnie zabronione: otwarcie nie powiodło się

Powyższy komunikat odnosi się do odrzucenia przez serwer SSH żądania klienta SSH dotyczącego otwarcia kanału bocznego. To zazwyczaj pochodzi z -D, -Llub -wjako oddzielne kanały w strumieniu SSH są wymagane do Promowego przekazane dane w poprzek.

Ponieważ używasz -L(dotyczy również -D), istnieją dwie opcje, które powodują, że serwer SSH odrzuca to żądanie:

• AllowTcpForwarding (jak wspomniał Steve Buzonas)
• PermitOpen

Te opcje można znaleźć w /etc/ssh/sshd_config. Powinieneś upewnić się, że:

• AllowTCPForwarding jest albo nieobecny, jest komentowany, albo ustawiony na yes
• PermitOpennie jest obecny, jest skomentowany lub jest ustawiony na any[1]

Dodatkowo, jeśli używasz klucza SSH do połączenia, powinieneś sprawdzić, czy wpis odpowiadający Twojemu kluczowi SSH w ~/.ssh/authorized_keysnie ma instrukcji no-port-forwardinglub permitopeninstrukcji [2].

Opcja nie dotyczy konkretnego polecenia, ale jest również nieco związana z tym tematem, PermitTunneljeśli próbujesz użyć opcji -w.

[1] Pełna składnia na stronie sshd_config(5)podręcznika.

[2] Pełna składnia na stronie authorized_keys(5)podręcznika.

W bardzo dziwnym przypadku wystąpił również ten błąd podczas próby utworzenia lokalnego tunelu. Moje polecenie brzmiało mniej więcej tak:

ssh -L 1234:localhost:1234 user@remote

Problem polegał na tym, że na zdalnym hoście /etc/hostsnie było wpisu „localhost”, więc serwer ssh nie wiedział, jak skonfigurować tunel. Bardzo nieprzyjazny komunikat o błędzie w tym przypadku; Cieszę się, że w końcu to rozgryzłem.

Lekcja: upewnij się, że docelowa nazwa hosta twojego tunelu jest rozpoznawalna przez host zdalny za pośrednictwem DNS lub /etc/hosts.

Przynajmniej jedna odpowiedź jest taka, że ​​„zdalny” komputer jest nieosiągalny z ssh z jakiegoś powodu. Komunikat o błędzie jest po prostu absurdalny.

Jeśli „zdalnego” nie można rozwiązać na serwerze, pojawi się ten błąd. Zastąp adres IP i sprawdź, czy to rozwiąże problem ...

(Zasadniczo taka sama odpowiedź jak u Neila - ale z pewnością uznałem, że to jest mój problem) [Miałem w swoim ~/.ssh/configpliku alias nazwy komputera - a maszyna zdalna nic nie wiedziała o tym aliasie ...

Ten błąd ostatecznie pojawia się, gdy używasz opcji ssh ControlPathi ControlMasterdo współużytkowania jednego połączenia gniazda do ponownego wykorzystania między kilkoma połączeniami klienta (od jednego klienta do tego samego użytkownika @ serwer). Otwarcie zbyt wielu (cokolwiek to znaczy, w moim przypadku ~ 20 połączeń) daje ten komunikat. Zamknięcie wszystkich poprzednich połączeń pozwala mi otworzyć nowsze, ponownie do limitu.

„administracyjnie zabroniony” to konkretna flaga komunikatu ICMP, która sprowadza się do „Administrator wyraźnie chce zablokować to połączenie”.

Sprawdź ustawienia iptables.

Podobny problem

Kolejny możliwy trop

Miałem ten sam problem ~/.ssh/authorized_keysz używaniem permitopen.

Podczas autosshtworzenia tunelu potrzebuję dwóch portów:

• jeden do podłączenia (10000),
• jeden do monitorowania (10001).

Po stronie klienta

Dało mi to podobny problem z portem monitorowania:

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

Miałem tę wiadomość (po 10 minutach):

channel 2: open failed: administratively prohibited: open failed

Po drugiej stronie

Mój /var/log/auth.logzawierał:

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

W mojej ~/.ssh/authorized_keys(odległej stronie) miałem to:

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

Jak to rozwiązać

Rozwiązałem ten problem, zastępując localhostinstancje 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...

Wydaje się, że SSH nie rozumie, że localhostjest to skrót do 127.0.0.1, stąd wiadomość w auth.logi wiadomość zabroniona administracyjnie .

Rozumiem tutaj, że administracyjnie oznacza „ze względu na określoną konfigurację po stronie serwera”.

Dzieje się tak również wtedy, gdy /etc/sshd_configma

AllowTcpForwarding no 

zestaw. Przełącz na, yesaby umożliwić przekazywanie TCP.

W moim przypadku musiałem wymienić localhostze 127.0.0.1w:

ssh -L 1234:localhost:3389 user@remote

aby działało.

Próbowałem postępować rdesktop -L localhost:1234zgodnie z instrukcjami Amazon dotyczącymi łączenia się z AWS EC2 przez tunelowanie SSH . Próbowałem zmienić /etc/ssh/sshd_config(zarówno klient, jak i serwer uruchamiają Ubuntu 16.04 LTS) na najlepiej głosowaną odpowiedź. Sprawdziłem też, że localhostjest /etc/hostspo obu stronach.

Nic nie działało, dopóki nie zmieniłem samego sshpolecenia na:

ssh -L 1234:127.0.0.1:3389 user@remote

Aby znaleźć ostateczną odpowiedź, potrzebne są działania związane z rozwiązywaniem problemów:

• sprawdź, czy przekierowanie portów jest włączone w konfiguracji ssh użytkownika,
• włącz gadatliwość ssh (-v),
• sprawdzaj dzienniki ssh na lokalnym hoście i bezpieczne dzienniki na zdalnym,
• przetestuj inny port zdalny,
• sprawdź ustawienia iptables (jak powiedział Shadur).

Raz dostałem ten błąd za umieszczenie pilota w parametrze -L, również 0.0.0.0 jest redundantne, można go pominąć z takimi samymi wynikami i myślę, że powinieneś dodać -g, aby działał.

Oto linia, której używam do tunelowania: 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.

Może to być również spowodowane brakiem możliwości połączenia z portem po stronie lokalnej.

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

To polecenie próbuje powiązać nasłuchujący port 1234 na komputerze lokalnym, który odwzorowuje na usługę na porcie 5678 na komputerze zdalnym.

Jeśli port 1234 na komputerze lokalnym jest już używany przez inny proces (być może sesję ssh -f w tle), ssh nie będzie w stanie nasłuchiwać na tym porcie i tunel się nie powiedzie.

Problem polega na tym, że ten komunikat o błędzie może oznaczać dowolną z kilku rzeczy, a „zabronione administracyjnie” czasami daje zły pomysł. Dlatego oprócz sprawdzania DNS, zapór ogniowych między lokalnym a zdalnym oraz sshd_config, sprawdź, czy port lokalny jest już używany. Posługiwać się

lsof -ti:1234

aby dowiedzieć się, jaki proces działa na 1234. Może być potrzebne sudo, aby lsof wylistował procesy należące do innych użytkowników. Następnie możesz użyć

ps aux | grep <pid>

aby dowiedzieć się, czym jest ten proces.

Aby uzyskać to wszystko w jednym poleceniu:

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

Miałem tę samą wiadomość podczas próby tunelowania. Wystąpił problem z serwerem dns po stronie zdalnej. Problem został rozwiązany, gdy wrócił do pracy.

Jestem bardzo zaskoczony, że nikt nie wspomniał, że może to być problem z 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)

Może to zostać przedstawione, jeśli remotenie da się go rozwiązać lub wprowadziłeś nieznaną składnię, tak jak zrobiłem to tutaj, gdzie dodałem a user@do logiki przekierowania portów (która nie będzie działać).

W moim przypadku problem polegał na żądaniu tunelu bez dostępu do powłoki, podczas gdy serwer chciał wymusić zmianę hasła na moim koncie. Z powodu braku powłoki nie mogłem tego zobaczyć i tylko otrzymałem błąd

channel 2: open failed: administratively prohibited: open failed  

Moja konfiguracja tunelu była następująca:

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

Błąd pokazywany podczas logowania bezpośrednio na serwer (bez opcji -N -f):

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

Rozwiązałem problem, logując się przy użyciu dostępu do powłoki i zmieniając hasło. Wtedy mógłbym po prostu użyć tuneli bez dostępu do powłoki.

Miałem ten problem, gdy próbowałem połączyć się przez SSH z użytkownikiem, który był upoważniony tylko do łączenia się za pomocą SFTP.

Na przykład było to na serwerze /etc/ssh/sshd_config:

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

W takim przypadku, aby skorzystać z SSH, będziesz musiał albo usunąć użytkownika z równoważnej sftponlygrupy, albo połączyć się przy użyciu użytkownika, który nie jest ograniczony do SFTP.

Sprawdź, czy /etc/resolv.confjest pusty na serwerze, na którym chcesz ssh. Kilka razy stwierdziłem, że jest to związane z pustym /etc/resolv.confplikiem

Jeśli nie jest rootem, możesz po prostu sprawdzić na serwerze, próbując trochę pinglub telnet(80) na publicznej nazwie hosta, tj .:

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

Po dodaniu rekordów serwera nazw do /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

Jednak powinieneś również sprawdzić, dlaczego /etc/resolv.confbył pusty (zwykle jest zapełniany rekordami serwera nazw przez klienta dhcp na serwerze, jeśli dotyczy).

Otrzymywałem tę samą wiadomość podczas tunelowania SSH do Debiana. Okazało się, że zdalny system nie ma wolnego miejsca. Po zwolnieniu miejsca na dysku i ponownym uruchomieniu, tunel zaczął działać.

Widziałem ten błąd na cygwinie i powinno to dotyczyć również Linuksa i działało dla mnie. W moim przypadku zrobiłem ssh -ND *: 1234 użytkownik@127.0.0.1 i kiedy podłączyłem przeglądarkę do tego serwera comp-socks, przeglądał, ale na komputerze, na którym uruchomiłem to polecenie ssh, ten błąd pojawił się na konsolę z każdym żądaniem - przynajmniej dla jednej strony, chociaż przeglądarka pobierała je przez proxy lub wydawało się, przynajmniej w stopniu, w jakim widziałem główny wiek. Ale dokonanie tej zmiany pozbyło się nieudanego komunikatu

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

Innym scenariuszem jest to, że usługa, do której próbujesz uzyskać dostęp, nie jest uruchomiona. Natknąłem się na ten problem innego dnia tylko po to, by pamiętać, że instancja httpd, z którą próbowałem się połączyć, została zatrzymana.

Aby rozwiązać problem, zacznij od najprostszego, czyli przejścia do drugiego komputera i sprawdzenia, czy możesz połączyć się lokalnie, a następnie pracy z powrotem w kierunku komputera klienckiego. Pozwoli to przynajmniej ustalić, w którym momencie komunikacja się nie odbywa. Możesz zastosować inne podejście, ale to zadziałało dla mnie.

Sprawdź, czy router nie ma ochrony przed ponownym połączeniem DNS Mój router (pfsense) ma domyślnie włączoną ochronę ponownego wiązania DNS. Powodował błąd „kanał otwarty: nieudany administracyjnie zabroniony: błąd otwarcia otwarty” z SSH

Miałem ten sam problem i zdałem sobie sprawę, że to DNS. Ruch jest tunelowany, ale żądanie DNS nie. Spróbuj ręcznie edytować plik hostów DNS i dodaj usługę, do której chcesz uzyskać dostęp.

Mój przypadek:

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

Wystąpił ten błąd podczas pisania tego wpisu na moim blogu :

/etc/ssh/sshd_config miał coś takiego:

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

Ale ~/.ssh/configmiał:

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

Zwróć uwagę na różnicę wielkości liter ( wielkość liter) między SSHBeyondRemote.server.com:22 a sshbeyondremote.server.com:22 .

Po naprawieniu sprawy nie widziałem już problemu.

Używałem:

Wersja klienta OpenSSH:

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

Wersja serwera OpenSSH:

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

Inna przyczyna rozpoznawania nazw: Mój / etc / hosts miał błędny adres IP dla nazwy serwera (nie dla localhost), na przykład:

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 literalnego adresu IP hosta lokalnego dla tunelu. Distro: Ubuntu 16.04 LTS.

Powód, dla którego miałem tę wiadomość, nie jest najczęstszy, ale warto o tym wspomnieć. Wygenerowałem przez skrypt listę tuneli i aby zapewnić prezentację kolumny, wydrukowałem każdy ostatni bajt na dwóch bajtach. Kiedy próbowałem otworzyć przekierowanie do tunelu na 192.168.66.08, zawsze się nie udawało, ponieważ „08” jest interpretowane przez gethostbyaddr jako niepoprawna liczba ósemkowa :)

Wydaje się, że istnieje wiele możliwych przyczyn tego komunikatu. W moim przypadku była to niemożność dostępu do pilota, ponieważ nie podałem poprawnie pliku klucza .

-LOpcja dodaje niejawny skok ssh (efektywnie przy użyciu wyraźnej hosta jako serwer SSH / skoku bastion). Debugowanie tego może być łatwiejsze, wykonując skok jawnie i tworząc powłokę logowania na maszynie docelowej za pomocą polecenia „proxy”.

Gdy to zadziała, możesz wykonać przekierowanie portu na podstawie komputera docelowego localhost(zakładając, że może on zalogować się do siebie):

-N -L 1234:localhost:1234