SSH tünel hatası: “kanal 1: açılmadı: yönetimsel olarak yasaklandı: açılmadı”

Bu ssh tüneli 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 hatanın anlamı nedir ve sorunu hangi makinede çözebilirsiniz?

kanal 1: başarısız oldu: idari olarak yasak: açılmadı

Yukarıdaki mesaj, SSH sunucunuzun SSH istemcinizin yan kanal açma isteğini reddettiği anlamına gelir. Bu tipik olarak, gelen -D, -Lya da -wSSH akışında ayrı kanal üzerinde iletilen veriler feribot gerekli olduğu gibi.

Kullandığınızdan -L(ayrıca uygulanabilir -D), söz konusu SSH sunucunuzun bu isteği reddetmesine neden olan iki seçenek vardır:

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

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

• AllowTCPForwarding ya mevcut değil, yorumlanmamış ya da olarak ayarlanmış yes
• PermitOpenya mevcut değil, yorumlanmamış veya any[1] olarak ayarlanmış

Ayrıca, bağlanmak için bir SSH anahtarı kullanıyorsanız, SSH anahtarınıza karşılık gelen girişin veya deyimi ~/.ssh/authorized_keysolmadığını kontrol etmelisiniz [2].no-port-forwardingpermitopen

Özel komutunuzla ilgili değil, ancak bu konuyla da biraz ilgili PermitTunnel, -w seçeneğini kullanmaya çalışıyorsanız seçenek olabilir.

[1] sshd_config(5)Manpage’de tam sözdizimi .

[2] authorized_keys(5)Manpage’de tam sözdizimi .

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

ssh -L 1234:localhost:1234 user@remote

Sorun, uzak ana bilgisayarda /etc/hosts"localhost" için bir giriş olmamasıydı , bu yüzden ssh sunucusu tünelin nasıl kurulacağını bilmiyordu. Bu dava için çok düşmanca bir hata mesajı; Sonunda anladım sevindim.

Ders: Tünelinizin hedef ana bilgisayar adının, uzak ana bilgisayar tarafından DNS veya üzerinden çözülebilir olduğundan emin olun /etc/hosts.

En azından bir cevap, makinenin "uzak" bir nedenden dolayı ssh ile erişilemez olmasıdır. Hata mesajı çok saçma.

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

(Temel olarak Neil ile aynı cevap - ama kesinlikle benim tarafımdaki sorun olarak buldum) [Dosyamda makine adı için bir takma ad vardı ~/.ssh/config- ve uzaktaki makine bu takma adın hiçbir şeyini bilmiyordu ...

Bu hata, ssh seçeneklerini kullandığınızda ControlPathve ControlMasterbirkaç istemci bağlantısı arasında yeniden kullanılmak üzere bir soket bağlantısını paylaşırken (bir istemciden aynı kullanıcıya @ sunucuya) kesinlikle açılır . Çok fazla açmak (ne anlama gelirse, benim durumumda ~ 20 bağlantı) bu mesajı verir. Önceki bağlantıların kapatılması, tekrar sınırına kadar daha yeni açmamı sağlar.

"idari olarak yasaklanmış", "Yönetici açıkça bu bağlantının engellenmesini istiyor" ifadesine kadar düşen belirli bir ICMP ileti bayrağıdır.

İptables ayarlarınızı kontrol edin.

Benzer bir sorun

Başka bir olası lider

Ben kullanarak aynı problem vardı ~/.ssh/authorized_keysile permitopen.

autosshBir tünel oluşturmak için kullandığım için iki porta ihtiyacım var:

• bağlantı için bir tane (10000),
• İzleme için bir tane (10001).

Müşteri tarafında

Bu bana izleme limanında da benzer bir sorun yarattı:

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

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

channel 2: open failed: administratively prohibited: open failed

Uzak tarafında

Benim /var/log/auth.logiçeriğim:

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

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

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

Nasıl çözeceksin

Bunu localhostörnekleri ile değiştirerek çözdüm 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...

Görünüşe göre SSH bunun mesaja ve idari olarak yasaklanmış mesaja localhostgiden bir kısayol olduğunu anlamıyor .127.0.0.1auth.log

Burada anladığım şey, idari olarak "sunucu tarafında belirli bir yapılandırma nedeniyle" anlamına geliyor.

Zaman da gerçekleşir /etc/sshd_configvardır

AllowTcpForwarding no 

Ayarlamak. yesTCP yönlendirmesine izin vermek için bunu değiştirin .

Benim durumumda, ben yerine zorunda localhostile 127.0.0.1de:

ssh -L 1234:localhost:3389 user@remote

çalışması için.

rdesktop -L localhost:1234Amazon'un AWS EC2'ye bağlanma konusundaki talimatlarını SSH tüneli üzerinden izlemeye çalışıyordum . /etc/ssh/sshd_configEn yüksek oyu alan cevaba göre değiştirmeye çalıştım (hem istemci hem de sunucu Ubuntu 16.04 LTS'yi çalıştırdı). Ayrıca o işaretli localhostolduğu /etc/hostsher iki tarafta.

sshKomutun kendisini değiştirene kadar hiçbir şey işe yaramadı :

ssh -L 1234:127.0.0.1:3389 user@remote

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

• Kullanıcının ssh yapılandırmasında bağlantı noktası iletmenin etkin olup olmadığını kontrol edin,
• ssh (-v) ayrıntılarını etkinleştir,
• Yerel ana bilgisayarda ssh günlüklerini kontrol et
• farklı uzak bağlantı noktalarını sınama,
• iptables ayarlarınızı kontrol edin (Shadur'un dediği gibi).

Uzaktan kumandayı -L parametresine koymak için bir kez bu hatayı aldım, 0.0.0.0 da aynı sonuçlarla atlayabileceğiniz gereksiz ve bence çalışması için -g'yi eklemelisiniz.

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

Bu ayrıca yerel taraftaki limana bağlanamamaktan da kaynaklanabilir.

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

Bu komut uzaktaki bir makinedeki 5678 numaralı bağlantı noktasındaki bir servise eşleyen yerel makinedeki bir dinleme bağlantı noktasını 1234 bağlamaya ç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, bu hata mesajının birkaç şeyden herhangi biri anlamına gelebilmesi ve “idari olarak yasaklanmanın” bazen yanlış fikir vermesidir. Bu nedenle, DNS'yi kontrol etmenin yanı sıra, yerel ile uzak arasındaki güvenlik duvarları ve sshd_config'in yanı sıra, yerel bağlantı noktasının zaten kullanılmış olup olmadığını kontrol edin. kullanım

lsof -ti:1234

1234'te hangi sürecin çalıştığını bulmak için. Diğer kullanıcıların sahip olduğu işlemleri listelemek için ludo'ya ihtiyacınız olabilir. Sonra kullanabilirsiniz

ps aux | grep <pid>

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

Bunları tek bir komutta almak için:

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

Tünelde çalışırken aynı mesajı aldım. Uzak tarafta dns sunucusunda bir sorun vardı. İşe geri döndüğünde sorun çözüldü.

Bunun bir DNS sorunu olabileceğinden kimsenin bahsetmediğinden 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 user@example.com: unknown host (Name or service not known)

Bu remote, çözülemez durumdaysa veya burada yaptığım gibi bilinmeyen bir sözdizimine giriyorsanız, burada user@ileriye dönük bağlantı mantığına (işe yaramazsa) ekleyebilirim.

Benim durumumda, sorun hesabımda bir şifre değişikliğini zorlamayı hedeflerken, kabuk erişimine sahip olmayan bir tünel talep etmekti. Bir kabuğun olmaması nedeniyle bunu göremedim ve yalnızca hatayı aldım

channel 2: open failed: administratively prohibited: open failed  

Tünel konfigürasyonum aşağıdaki gibiydi:

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

Doğrudan sunucuya giriş yaparken hata gösterildi (-N -f olmadan):

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

Bu sorunu kabuk erişimine giriş yaparak ve şifreyi değiştirerek çözdüm. Sonra tekrar kabuk erişimi olmayan tünelleri kullanabilirim.

SSH ile yalnızca SFTP kullanarak bağlanmaya yetkili bir kullanıcıyla bağlanmaya çalışırken bu sorunu yaşadım.

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

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

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

/etc/resolv.confGittiğiniz sunucuda boş olup olmadığını kontrol edin ssh. Birkaç kez bunun boş bir /etc/resolv.confdosyayla ilişkili olduğunu buldum

Sigara kökü, sadece bazı deneyerek sunucuda kontrol edebilirsiniz pingveya telnetbir kamu hostname yani üzerinde (80):

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

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

Bununla birlikte, neden /etc/resolv.confboş olduğunu da kontrol etmelisiniz (bu, genellikle sunucudaki dhcp istemcisi tarafından ad sunucusu kayıtları ile doldurulur).

Aynı mesajı SSH’nın Debian’a yapmasıyla da alıyordum. Uzak sistemin boş alanı olmadığı ortaya çıktı. Disk alanını boşalttıktan ve yeniden başlattıktan sonra, tünel çalışmaya başladı.

Bu hatayı cygwin'de gördüm ve bu linux için de geçerli olmalı ve benim için çalıştı. Benim durumumda ssh -ND *: 1234 user@127.0.0.1 'i yaptım ve bu comp-socks sunucusuna bir tarayıcı bağladığımda göz attı, ancak o ssh komutunu koştuğum comp üzerinde şu hatayı göründüğünü gördüm. Her isteği içeren konsol - en azından bir site için, tarayıcı proxy üzerinden alınmış olsa da, en azından ana yaşı gördüğüm kadarıyla göründü. 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 :
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

Diğer bir senaryo, erişmeye çalıştığınız servisin çalışmıyor olmasıdır. Geçen gün bu sorunla karşılaştım, yalnızca bağlanmaya çalıştığım httpd örneğini hatırlamak için durduruldum.

Sorunu çözme adımlarınız, diğer makineye giden ve yerel olarak bağlanıp bağlanamayacağınızı görmek ve daha sonra kendinize istemci bilgisayarınıza doğru çalışıp çalışamayacağınızı görmek en basitinden başlamak olacaktır. En azından bu, iletişimin gerçekleşmediği noktada çalışmanıza olanak sağlayacaktır. Başka yaklaşımlar alabilirsin, ama bu benim için işe yaradı.

Yönlendiricinizi DNS Yeniden Bağlama koruması için kontrol edin . Yönlendiricim (pfsense), varsayılan olarak DNS Yeniden Bağlanma Koruması Özelliğine Sahiptir. SSH'de 'kanal açık: idari olarak yasaklandı: açık başarısız oldu' hatasına neden oldu

Aynı sorunu yaşadım ve bunun DNS olduğunu anladım. Trafik tünellenmiş ancak DNS istek no. DNS ana bilgisayarlarınızı el ile düzenlemeyi deneyin ve erişmek istediğiniz hizmeti ekleyin.

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)

Yazarken bu hata var bu girdiyi de blogumda :

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

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

Ancak ~/.ssh/configvardı:

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

Farkı dikkat durumda arasında (büyük harf) SSHBeyondRemote.server.com:22 ve sshbeyondremote.server.com:22 .

Davayı çözdüğümde 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

Diğer ad çözümleme nedeni: My / etc / hosts dosyalarının sunucunun adı (localhost için değil) için hatalı bir IP adresi vardı, şöyle:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Ancak yapılandırılmış sunucu IP'si (ve ana bilgisayar / dig komutlarıyla çözülen DNS adı) 192.168.2.47 idi. Önceki bir IP yapılandırmasından kaynaklanan basit bir yazım hatası. / Etc / hosts dosyasını tamir ettikten sonra tünel bağlantısı sorunsuz şekilde çalıştı:

ssh user@server.domain.com -L 3456:127.0.0.1:5901

Tünel için yerel ana bilgisayar IP'sini kullanırken gerçek IP'nin başarısızlığa neden olması garip. Dağıtım: Ubuntu 16.04 LTS.

Bu mesajı almamın nedeni en yaygın olanı değil, ama söylemeye değer. Bir tünel listesi komut dosyası tarafından oluşturulmuş ve bir sütun sunumu sağlamak için, her son baytı iki bayta yazdırmıştım. 192.168.66.08'e yönlendiren tüneli 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 :)

Bu mesaj için bir çok olası kök nedeni var gibi görünüyor. Benim durumumda, uzaktan kumandayı kullanamadım, çünkü anahtar dosyayı doğru bir şekilde vermedim .

Bu -Lseçenek, kapalı bir SSH atlama ekler (açık SSH ana bilgisayarını bir bastion / jump sunucusu olarak etkin bir şekilde kullanarak). Bu atlamayı açıkça gerçekleştirerek ve "proxycommand" kullanarak hedef makineye bir giriş kabuğu oluşturarak bunu ayıklamak daha kolay olabilir.

Bu işe yaradığında, hedef makineye göre bağlantı noktasını ileriye doğru localhostyapabilirsiniz (kendi kendine oturum açabileceğini varsayarak):

-N -L 1234:localhost:1234