it-swarm-tr.com

SSH tünelleme hatası: "kanal 1: açık başarısız oldu: idari olarak yasaklandı: açık başarısız oldu"

Bu ssh tünelini açtığımda:

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

Localhost üzerinde çalışan HTTP sunucusuna erişmeye çalışırken bu hatayı alıyorum: 8984:

channel 1: open failed: administratively prohibited: open failed

Bu hata ne anlama geliyor ve sorunu hangi makinede çözebilirsiniz?

210
Neil

kanal 1: açık başarısız oldu: idari olarak yasaklandı: açık başarısız oldu

Yukarıdaki mesaj, SSH sunucunuzun SSH istemcinizin bir yan kanal açma talebini reddettiğini gösterir. SSH akışındaki ayrı kanallar iletilen verileri feribot etmek için gerekli olduğundan, bu genellikle -D, -L Veya -w 'Dan gelir.

-L (-D İçin de geçerlidir) kullandığınızdan, söz konusu SSH sunucunuzun bu isteği reddetmesine neden olan iki seçenek vardır:

  • AllowTcpForwarding (Steve Buzonas'ın belirttiği gibi)
  • PermitOpen

Bu seçenekler /etc/ssh/sshd_config İçinde bulunabilir. Şunlardan emin olmalısınız:

  • AllowTCPForwarding mevcut değil, yorum yapılmamış veya yes olarak ayarlanmış
  • PermitOpen mevcut değil, yorum yapılmamış veya any [1] olarak ayarlanmış

Ayrıca, bağlanmak için bir SSH anahtarı kullanıyorsanız, ~/.ssh/authorized_keys İçindeki SSH anahtarınıza karşılık gelen girdinin no-port-forwarding Veya permitopen ifadesine [2] sahip olmadığını kontrol etmelisiniz. .

-W seçeneğini kullanmaya çalışıyorsanız, kendi komutunuzla ilgili olmayan, ancak bu konuyla da ilgili olan PermitTunnel seçeneğidir.

[1] sshd_config(5) kılavuzundaki tam sözdizimi.

[2] authorized_keys(5) kılavuzundaki tam sözdizimi.

134
hyperair

Çok garip bir durumda, yerel bir tünel oluşturmaya çalışırken de bu hatayı yaşadım. Komutum şöyle bir şeydi:

ssh -L 1234:localhost:1234 [email protected]

Sorun, uzak Ana Makinede /etc/hosts "localhost" için hiçbir girdi yoktu, bu yüzden ssh sunucusu tünelin nasıl kurulacağını bilmiyordu. Bu dava için çok düşmanca bir hata mesajı; nihayet anladım sevindim.

Ders: tünelinizin hedef ana bilgisayar adının, uzak Ana Bilgisayar tarafından DNS veya /etc/hosts.

55
cobbzilla

En az bir cevap, makine "uzaktan" herhangi bir nedenle ssh ile ulaşılamıyor olmasıdır. Hata mesajı sadece saçma.

27
Neil

Eğer 'uzak' sunucuda çözülemezse bu hatayı alırsınız. Bir IP adresiyle değiştirin ve bunun sorununuzu çözüp çözmediğine bakın ...

(Temelde Neil ile aynı cevap - ama kesinlikle yanımda sorun olduğunu buldum) [~/.ssh/config Dosyamda makine adı için bir takma adım vardı - ve uzak makine bu takma addan hiçbir şey bilmiyordu ...

19
jacquesjtheron

Bu hata, birkaç istemci bağlantısı arasında (bir istemciden aynı user @ server'a) yeniden kullanılacak bir soket bağlantısını paylaşmak için ControlPath ve ControlMaster ssh seçeneklerini kullandığınızda ortaya çıkar. Çok fazla açmak (ne olursa olsun, benim durumumda ~ 20 bağlantı) bu mesajı verir. Önceki bağlantıları kapatmak, yeniden sınıra kadar yeni olanları açmama izin verir.

11
Matej Kovac

"yönetimsel olarak yasaklanmış", "Yönetici bu bağlantının açıkça engellenmesini istiyor" seçeneğine kadar giden belirli bir ICMP ileti işaretidir.

Iptables ayarlarınızı kontrol edin.

8
Shadur

Benim durumumda, localhost yerine 127.0.0.1 içinde:

ssh -L 1234:localhost:3389 [email protected]

çalışması için.

Deniyordum rdesktop -L localhost:1234 Amazon'un ardından SSH tüneli üzerinden AWS EC2'ye bağlanma talimatları . /etc/ssh/sshd_config (hem istemci hem de sunucu, Ubuntu 16.04 LTS'yi çalıştırır) en yüksek oy verilen cevap başına). Ayrıca localhost öğesinin /etc/hosts iki tarafta da.

ssh komutunun kendisini şu şekilde değiştirene kadar hiçbir şey işe yaramadı:

ssh -L 1234:127.0.0.1:3389 [email protected]
6
tinlyx

Benzer bir problem

Başka bir olası satış

permitopen ile ~/.ssh/authorized_keys Kullanarak aynı sorunu yaşadım.

Bir tünel oluşturmak için autossh kullandığım için iki bağlantı noktasına ihtiyacım var:

  • biri bağlantı için (10000),
  • biri izleme için (10001).

Müşteri tarafında

Bu, izleme portunda bana benzer bir sorun verdi:

autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60  -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa [email protected]

Bu mesajı aldım (10 dakika sonra):

channel 2: open failed: administratively prohibited: open failed

Uzak tarafta

/var/log/auth.log Dosyamda şunlar vardı:

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

Benim ~/.ssh/authorized_keys (Uzak taraf) bu vardı:

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

Nasıl çözeceksin

localhost örneklerini 127.0.0.1 İle değiştirerek bunu çözdüm:

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

SSH'nin localhost ifadesinin 127.0.0.1 İçin bir kısayol olduğunu anlamadığı anlaşılıyor, bu nedenle auth.log Ve yönetimsel olarak yasaklanmıştır mesajı.

Burada ne anlamak idari olarak "sunucu tarafında belirli bir yapılandırma nedeniyle" anlamına gelir.

5
lauhub

Bu, /etc/sshd_config vardır

AllowTcpForwarding no 

ayarlamak. TCP iletmeye) izin vermek için yes olarak değiştirin.

4
user578125

Uzaktan kumandayı -L parametresine koymak için bir kez bu hatayı aldım, ayrıca 0.0.0.0 da aynı sonuçlarla atlayabilirsiniz ve bence çalışmak için -g eklemeniz gerekir.

Tünel açma için kullandığım hat: 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

Kesin bir cevap bulmak için bazı sorun giderme faaliyetlerine ihtiyaç vardır:

  • kullanıcının ssh yapılandırmasında port yönlendirmenin etkin olup olmadığını kontrol edin,
  • ssh (-v) ayrıntı düzeyini etkinleştir,
  • yerel Host'daki ssh günlüklerini kontrol edin ve uzaktaki bir bilgisayarda güvenli günlükleri kontrol edin
  • farklı uzak bağlantı noktasını test edin,
  • iptables ayarlarınızı kontrol edin (Shadur'un dediği gibi).
3
Marco Solieri

Bunun nedeni yerel taraftaki bağlantı noktasına bağlanamaması olabilir.

ssh -Nn -L 1234:remote:5678 [email protected]

Bu komut, yerel makinedeki bir dinleme bağlantı noktasını (1234) uzak bir makinedeki bağlantı noktası 5678'deki bir hizmetle eşleştirmeye çalışıyor.

Yerel makinedeki 1234 numaralı bağlantı noktası zaten başka bir işlem tarafından kullanılıyorsa (belki arka plan ssh -f oturumu), ssh bu bağlantı noktasını dinleyemez ve tünel başarısız olur.

Sorun şu ki, bu hata mesajı birkaç şeyden herhangi biri anlamına gelebilir ve "idari olarak yasaklanmış" bazen yanlış fikir verir. Bu nedenle DNS'yi, yerel ve uzak arasındaki güvenlik duvarlarını ve sshd_config'yi kontrol etmenin yanı sıra, yerel bağlantı noktasının zaten kullanılıp kullanılmadığını kontrol edin. kullanım

lsof -ti:1234

diğer kullanıcıların sahip olduğu işlemleri listelemek için Sudo'ya ihtiyacınız olabilir. Sonra kullanabilirsiniz

ps aux | grep <pid>

bu sürecin ne olduğunu bulmak için.

Tüm bunları tek bir komutta almak için:

ps aux | grep "$(Sudo lsof -ti:1234)"
3
Mnebuerquo

Benim durumumda, sorun Shell'in erişimi olmayan bir tünel istemekten kaynaklanıyordu, ancak sunucu hesabımda bir şifre değişikliğini zorlamayı amaçladı. Bir Kabuk eksikliğinden dolayı, bunu göremedim ve sadece hatayı aldım

channel 2: open failed: administratively prohibited: open failed  

Tünel yapılandırmam şöyleydi:

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

Doğrudan sunucuya giriş yapılırken hata oluştu (-N -f olmadan):

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

Shell erişimi ile giriş yapıp şifreyi değiştirerek sorunu çözdüm. Sonra tekrar Shell erişimi olmayan tünelleri kullanabilirdim.

2
Pieter Van Gorp

Kimsenin bunun bir DNS sorunu olabileceğinden bahsetmemesine son derece şaşırdım.

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)

Eğer remote çözülemezse veya burada yaptığım gibi bilinmeyen bir sözdizimi girerseniz, bu bağlantı noktası yönlendirme mantığına [email protected] t).

2
Torxed

Tünel açmaya çalışırken aynı mesajı aldım. Uzak tarafta dns sunucusu ile ilgili bir sorun vardı. Sorun işe geri döndüğünde çözüldü.

2

Yalnızca SFTP kullanarak bağlanma yetkisi olan bir kullanıcıyla SSH üzerinden bağlanmaya çalışırken bu sorunu yaşadım.

Örneğin, bu sunucunun /etc/ssh/sshd_config:

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

Bu nedenle, SSH'yi kullanmak için kullanıcıyı eşdeğer sftponly grubundan kaldırmanız veya SFTP ile sınırlı olmayan bir kullanıcı kullanarak bağlanmanız gerekecektir.

1
Mike

Aynı mesajı SSH Debian'a tünel açarken alıyordum. Uzaktaki sistemin boş alanı olmadığı ortaya çıktı. Biraz disk alanı boşalttıktan ve yeniden başlattıktan sonra tünel çalışmaya başladı.

1
SlavaSt

Kontrol eğer /etc/resolv.conf, ssh- olduğunuz sunucuda boş. Birkaç kez bunun boş bir /etc/resolv.conf dosya

Kök değilse, genel bir ana bilgisayar adında ping veya telnet (80) deneyerek sunucuyu kontrol edebilirsiniz, yani:

[email protected] ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

Ad sunucusu kayıtlarını /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

Ancak, neden /etc/resolv.conf boştu (bu genellikle sunucudaki dhcp istemcisi tarafından ad sunucusu kayıtlarıyla doldurulur.

1
Ender

Yazarken bu hatayı aldım bu girdi içinde blogum :

/etc/ssh/sshd_config gibi bir şey vardı:

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

Fakat ~/.ssh/config vardı:

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

case (büyük harf kullanımı) SSHBeyondRemote.server.com:22 ve sshbeyondremote.server.com:22.

Davayı düzelttikten sonra artık sorunu görmedim.

Kullanıyordum:

OpenSSH istemcisinin sürümü:

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

OpenSSH sunucusunun sürümü:

  • OpenSSH_7.6p1 Debian-4, OpenSSL 1.0.2n 7 Ara 2017
0
Zach Pfeffer

Cygwin'de bu hatayı gördüm ve bu da linux için geçerli olmalı ve benim için çalıştı. Benim durumumda ssh -ND *: 1234 [email protected] yaptım ve bu comp-socks sunucusuna bir tarayıcı bağladığımda, göz attı, ancak bu ssh komutunu çalıştırdığım comp'te görünen hatayı aldım Her istekle birlikte konsol - en azından bir site için, tarayıcı proxy üzerinden aldı veya en azından ana yaşı gördüğüm ölçüde görünüyordu. Ancak bu değişikliği yapmak başarısız mesajdan kurtuldu

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

Yukarıdaki yorumlardan birine hafif bir ekleme: "Bir DNS çözümlemesi hatası bu hataya neden olabilir" - ayrıca ana makine adınızı doğru yazdığınızdan emin olun.

Tüm ssh ayarlarında hata ayıklamaya çalışırken bir saatten fazla zaman harcadım ve yukarıdaki DNS çözümleme hatası notuna eşdeğer olan komutta amazonaws yanlış yazmıştım.

0
Brad Dwyer

Asus RT68U yönlendiricisinin ürün yazılımı (Merlin Asus), SSH bağlantı noktası yönlendirmesine izin veren ve etkinleştirilmesi gereken bir ayara sahiptir:

enter image description here

Dinamik bağlantı noktası iletme, şu şekilde açıklandığı gibi ayarlandı: Dyamic tünel sorunlarını giderme

0
gatorback

Bu mesajı almamın nedeni en yaygın olanı değil, ama belirtmeye değer. Komut dosyası tarafından bir tünel listesi oluşturdum ve bir sütun sunumu sağlamak için her son baytı iki bayta yazdırdım. 192.168.66.08'e tünel yönlendirme açmaya çalıştığımda, her zaman başarısız oldu, çünkü '08' gethostbyaddr tarafından geçersiz bir sekizli sayı olarak yorumlanıyor :)

0

Yönlendiricinizde DNS Yeniden Bağlama koruması olup olmadığını kontrol edin. Yönlendiricimde (pfsense) varsayılan olarak DNS Yeniden Bağlama Koruması etkin. SSH ile 'kanal açık: başarısız yönetimsel olarak yasaklandı: açık başarısız' hatasına neden oluyordu

0
meffect

Bu mesaj için birçok olası kök neden var gibi görünüyor. Benim durumumda keyfile doğru vermedim çünkü uzaktan erişim için bir yetersizlik oldu.

-L seçeneği, örtük bir SSH atlama ekler (etkin SSH Ana Bilgisayarını bastion/atlama sunucusu olarak etkin bir şekilde kullanarak). Atlamayı açıkça gerçekleştirerek ve "proxycommand" kullanarak hedef makineye bir oturum açma Kabuğu oluşturarak hata ayıklamak daha kolay olabilir.

Bu çalıştıktan sonra, hedef makinenin localhost (kendi kendine giriş yapabileceği varsayılarak) bağlantı noktasını ileriye doğru yapabilirsiniz:

-N -L 1234:localhost:1234
0
nobar

Benim olayım:

$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

Diğer ad çözümlemesi nedeni:/etc/hosts bilgisayarlarım sunucunun adı için hatalı bir IP adresine sahipti (localhost için değil), şöyle:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Ancak yapılandırılan sunucu IP'si (ve Host/Dig komutlarıyla çözülen DNS adı) 192.168.2.47 idi. Önceki bir IP yeniden yapılandırmasının neden olduğu basit bir yazım hatası./Etc/hosts sabitlendikten sonra tünel bağlantısı kusursuz bir şekilde çalıştı:

ssh [email protected] -L 3456:127.0.0.1:5901

Tünel için localhost değişmez IP'sini kullanırken gerçek IP'nin hataya neden olması garip. Dağıtım: Ubuntu 16.04 LTS.

0
Fjor

Aynı sorunu yaşadım ve DNS olduğunu anladım. Trafik tünellenmiş ancak DNS istek no. DNS ana bilgisayarlar dosyanızı elle düzenlemeye ve erişmek istediğiniz hizmeti eklemeye çalışın.

0
Data

Diğer bir senaryo, erişmeye çalıştığınız hizmetin çalışmıyor olmasıdır. Geçen gün sadece bu konuya bağlanmaya çalıştığım httpd örneğinin durduğunu hatırlamak için karşılaştım.

Sorunu çözmek için attığınız adımlar, diğer makineye gidip yerel olarak bağlanıp bağlanamayacağınızı görmek ve daha sonra kendinizi istemci bilgisayarınıza doğru çalıştırabilmek. En azından bu, iletişimin hangi noktada gerçekleşmediğini çözmenizi sağlayacaktır. Başka yaklaşımlar da kullanabilirsiniz, ama bu benim için işe yarayan yaklaşımdı.

0
Andre M