Galat penerowongan SSH: “saluran 1: buka gagal: dilarang secara administratif: buka gagal”

Ketika saya membuka terowongan ssh ini:

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

Saya mendapatkan kesalahan ini ketika mencoba mengakses server HTTP yang berjalan di localhost: 8984:

channel 1: open failed: administratively prohibited: open failed

Apa artinya kesalahan ini, dan di mesin mana Anda dapat memperbaiki masalahnya?

saluran 1: terbuka gagal: dilarang secara administratif: terbuka gagal

Pesan di atas merujuk pada server SSH Anda yang menolak permintaan klien SSH Anda untuk membuka saluran samping. Ini biasanya berasal dari -D, -Latau -w, karena saluran terpisah dalam aliran SSH diperlukan untuk mengangkut data yang diteruskan ke seberang.

Karena Anda menggunakan -L(juga berlaku untuk -D), ada dua opsi yang menyebabkan server SSH Anda menolak permintaan ini:

• AllowTcpForwarding (seperti yang disebutkan Steve Buzonas)
• PermitOpen

Opsi ini dapat ditemukan di /etc/ssh/sshd_config. Anda harus memastikan bahwa:

• AllowTCPForwarding tidak ada, dikomentari, atau diatur ke yes
• PermitOpentidak ada, dikomentari, atau diatur ke any[1]

Selain itu, jika Anda menggunakan kunci SSH untuk menghubungkan, Anda harus memeriksa apakah entri yang terkait dengan kunci SSH Anda ~/.ssh/authorized_keystidak ada no-port-forwardingatau permitopenpernyataan [2].

Tidak relevan dengan perintah khusus Anda, tetapi agak relevan dengan topik ini juga, adalah PermitTunnelopsi jika Anda mencoba menggunakan opsi -w.

[1] Sintaksis lengkap di halaman sshd_config(5)manual.

[2] Sintaksis penuh di halaman authorized_keys(5)manual.

Dalam kasus yang sangat aneh, saya juga mengalami kesalahan ini ketika mencoba membuat terowongan lokal. Perintah saya adalah seperti ini:

ssh -L 1234:localhost:1234 user@remote

Masalahnya adalah, pada host jarak jauh, /etc/hoststidak memiliki entri untuk "localhost" sehingga server ssh tidak tahu cara mengatur terowongan. Pesan kesalahan yang sangat tidak ramah untuk kasus ini; senang saya akhirnya menemukan jawabannya.

Pelajaran: pastikan hostname target terowongan Anda dapat diatasi oleh host jarak jauh, baik melalui DNS atau /etc/hosts.

Setidaknya satu jawaban adalah bahwa mesin "jarak jauh" tidak dapat dijangkau dengan ssh karena suatu alasan. Pesan kesalahan itu tidak masuk akal.

Jika 'jarak jauh' tidak dapat diselesaikan di server Anda akan mendapatkan kesalahan itu. Ganti dengan alamat IP dan lihat apakah itu menyelesaikan masalah Anda ...

(Pada dasarnya jawaban yang sama dengan Neil - tapi saya pasti menemukan bahwa menjadi masalah di pihak saya) [Saya memiliki alias untuk nama mesin di ~/.ssh/configfile saya - dan mesin jarak jauh tidak tahu apa-apa tentang itu alias ...

Kesalahan ini secara pasti muncul ketika Anda menggunakan opsi ssh ControlPathdan ControlMasteruntuk berbagi satu koneksi soket untuk digunakan kembali di antara beberapa koneksi klien (dari satu klien ke pengguna yang sama @ server). Membuka terlalu banyak (apa pun artinya, dalam kasus saya ~ 20 koneksi) menghasilkan pesan ini. Menutup koneksi sebelumnya memungkinkan saya membuka yang lebih baru, lagi hingga batasnya.

"Dilarang secara administratif" adalah tanda pesan ICMP khusus yang bermuara pada "Administrator secara eksplisit ingin koneksi ini diblokir".

Periksa pengaturan iptables Anda.

Masalah serupa

Kemungkinan memimpin lainnya

Saya memiliki masalah yang sama ~/.ssh/authorized_keysdengan menggunakan permitopen.

Seperti yang saya gunakan autosshuntuk membuat terowongan, saya membutuhkan dua port:

• satu untuk koneksi (10000),
• satu untuk pemantauan (10001).

Di sisi klien

Ini memberi saya masalah yang sama dengan port pemantauan:

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

Saya mendapat pesan itu (setelah 10 menit):

channel 2: open failed: administratively prohibited: open failed

Di sisi yang jauh

/var/log/auth.logBerisi saya :

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

Di ~/.ssh/authorized_keys(sisi jauh) saya, saya punya ini:

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

Bagaimana mengatasinya

Saya memecahkan ini dengan mengganti localhostinstance dengan 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...

Tampaknya SSH tidak mengerti bahwa itu localhostadalah jalan pintas ke 127.0.0.1, karenanya pesan masuk auth.logdan pesan yang dilarang secara administratif .

Apa yang saya pahami di sini adalah bahwa secara administratif berarti "karena konfigurasi khusus di sisi server".

Ini juga terjadi ketika /etc/sshd_configsudah

AllowTcpForwarding no 

set. Alihkan ke yesuntuk memungkinkan penerusan TCP.

Dalam kasus saya, saya harus mengganti localhostdengan 127.0.0.1di:

ssh -L 1234:localhost:3389 user@remote

untuk membuatnya bekerja.

Saya mencoba rdesktop -L localhost:1234mengikuti instruksi Amazon tentang cara menghubungkan ke AWS EC2 melalui tunneling SSH . Saya telah mencoba mengubah /etc/ssh/sshd_config(baik klien dan server menjalankan Ubuntu 16.04 LTS) per jawaban suara tertinggi. Saya juga memeriksa yang localhostada di /etc/hostskedua sisi.

Tidak ada yang berhasil sampai saya mengubah sshperintah itu sendiri menjadi:

ssh -L 1234:127.0.0.1:3389 user@remote

Beberapa aktivitas pemecahan masalah diperlukan untuk menemukan jawaban yang pasti:

• periksa apakah penerusan port diaktifkan dalam konfigurasi ssh pengguna,
• aktifkan verbosity of ssh (-v),
• periksa ssh log pada host lokal dan log aman di remote,
• menguji port jarak jauh yang berbeda,
• periksa pengaturan iptables Anda (seperti yang dikatakan Shadur).

Saya mendapat kesalahan ini sekali untuk meletakkan remote di parameter -L, juga 0.0.0.0 yang berlebihan Anda dapat menghilangkannya dengan hasil yang sama, dan saya pikir Anda harus menambahkan -g agar berfungsi.

Ini adalah garis yang saya gunakan untuk penerowongan: 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.

Ini juga dapat disebabkan karena tidak dapat mengikat ke port di sisi lokal.

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

Perintah ini mencoba mengikat port mendengarkan 1234 pada mesin lokal, yang memetakan ke layanan pada port 5678 pada mesin jarak jauh.

Jika port 1234 pada mesin lokal sudah digunakan oleh proses lain, (mungkin sesi ssh -f latar belakang), maka ssh tidak akan dapat mendengarkan pada port itu dan terowongan akan gagal.

Masalahnya adalah bahwa pesan kesalahan ini dapat berarti beberapa hal, dan "dilarang secara administratif" terkadang memberikan gagasan yang salah. Jadi selain memeriksa DNS, firewall antara lokal dan jarak jauh, dan sshd_config, periksa untuk melihat apakah port lokal sudah digunakan. Menggunakan

lsof -ti:1234

untuk mengetahui proses apa yang sedang berjalan pada 1234. Anda mungkin perlu sudo agar lsof mendaftar proses yang dimiliki oleh pengguna lain. Maka Anda bisa menggunakannya

ps aux | grep <pid>

untuk mengetahui apa proses itu.

Untuk mendapatkan ini semua dalam satu perintah:

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

Saya memiliki pesan yang sama ketika mencoba melakukan tunnel. Ada masalah dengan server dns di sisi jarak jauh. Masalahnya terpecahkan ketika kembali bekerja.

Saya sangat terkejut bahwa tidak ada yang menyebutkan bahwa ini mungkin masalah 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)

Ini mungkin disajikan jika remotetidak dapat diatasi atau Anda telah memasukkan sintaks yang tidak diketahui seperti yang saya lakukan di sini di mana saya telah menambahkan user@logika port-forward (yang tidak akan berfungsi).

Dalam kasus saya, masalahnya adalah karena meminta terowongan tanpa akses shell sementara server bertujuan untuk memaksa perubahan kata sandi di akun saya. Karena kurangnya shell, saya tidak bisa melihat itu dan hanya menerima kesalahan

channel 2: open failed: administratively prohibited: open failed  

Konfigurasi terowongan saya adalah sebagai berikut:

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

Kesalahan ditampilkan saat masuk langsung ke server (tanpa -N -f):

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

Saya menyelesaikan masalah dengan masuk dengan akses shell dan mengubah kata sandi. Maka saya bisa menggunakan terowongan tanpa akses shell lagi.

Saya mengalami masalah ini ketika mencoba terhubung melalui SSH dengan pengguna yang hanya diizinkan terhubung menggunakan SFTP.

Misalnya, ini ada di server /etc/ssh/sshd_config:

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

Jadi dalam hal ini, untuk menggunakan SSH, Anda harus menghapus pengguna dari sftponlygrup yang setara atau terhubung menggunakan pengguna yang tidak terbatas pada SFTP.

Periksa apakah /etc/resolv.confkosong di server yang Anda tuju ssh. Beberapa kali saya menemukan ini terkait dengan /etc/resolv.conffile kosong

Jika bukan root, Anda bisa mengecek server dengan mencoba beberapa pingatau telnet(80) nama host publik, yaitu:

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

Setelah menambahkan catatan server nama ke /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

Namun, Anda juga harus memeriksa mengapa /etc/resolv.confitu kosong (ini biasanya diisi dengan catatan server nama oleh klien dhcp di server, jika berlaku.

Saya mendapatkan pesan yang sama saat SSH menyetel ke Debian. Ternyata sistem jarak jauh tidak memiliki ruang kosong. Setelah membebaskan beberapa ruang disk dan mem-boot ulang, terowongan mulai berfungsi.

Saya melihat kesalahan ini pada cygwin dan ini juga berlaku untuk linux dan bekerja untuk saya. Dalam kasus saya, saya telah melakukan ssh -ND *: 1234 user@127.0.0.1 dan ketika saya menghubungkan browser ke server comp-socks itu, browser tersebut meramban, tetapi pada komputer tempat saya menjalankan perintah ssh tersebut, saya mendapatkan kesalahan yang muncul pada konsol dengan setiap permintaan - setidaknya untuk satu situs, meskipun browser mengambilnya melalui proxy atau sepertinya, setidaknya sejauh saya melihat usia utama. Tetapi melakukan perubahan ini menghilangkan pesan yang gagal

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

Satu skenario lain adalah bahwa layanan yang Anda coba akses tidak berjalan. Saya mengalami masalah ini beberapa hari yang lalu hanya untuk mengingat contoh httpd yang saya coba hubungkan telah dihentikan.

Langkah-langkah Anda untuk menyelesaikan masalah akan dimulai dengan yang paling sederhana, yaitu pergi ke mesin lain dan melihat apakah Anda dapat terhubung secara lokal dan kemudian bekerja sendiri kembali ke komputer klien Anda. Setidaknya ini akan memungkinkan Anda untuk bekerja pada titik apa komunikasi tidak terjadi. Anda dapat mengambil pendekatan lain, tetapi ini yang berhasil bagi saya.

Periksa router Anda untuk perlindungan DNS Rebinding . Router saya (pfsense) memiliki Perlindungan Rebinding DNS Diaktifkan secara default. Itu menyebabkan kesalahan 'saluran terbuka: gagal secara administratif dilarang: buka gagal' dengan SSH

Saya memiliki masalah yang sama dan saya menyadari bahwa itu adalah DNS. Lalu lintas disalurkan tetapi DNS meminta no. Cobalah untuk mengedit file host DNS Anda secara manual dan tambahkan layanan yang ingin Anda akses.

Kasus saya:

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

Saya mendapatkan kesalahan ini saat menulis entri ini di blog saya :

/etc/ssh/sshd_config punya sesuatu seperti:

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

Tapi ~/.ssh/configpunya:

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

Perhatikan perbedaan huruf besar-kecil ( huruf besar ) antara SSHBeyondRemote.server.com:22 dan sshbeyondremote.server.com:22 .

Setelah saya memperbaiki kasus ini, saya tidak lagi melihat masalahnya.

Saya menggunakan:

Versi klien OpenSSH:

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

Versi server OpenSSH:

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

Penyebab resolusi nama lainnya: My / etc / hosts memiliki alamat IP yang salah untuk nama server (bukan untuk localhost), seperti ini:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Tetapi IP server yang dikonfigurasi (dan nama DNS diselesaikan dengan perintah host / dig) adalah 192.168.2.47. Kesalahan ketik sederhana yang disebabkan oleh konfigurasi ulang IP sebelumnya. Setelah memperbaiki / etc / hosts, koneksi terowongan bekerja dengan sempurna:

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

Sungguh aneh bahwa IP asli menyebabkan kegagalan ketika saya menggunakan IP localhost literal untuk terowongan. Distro: Ubuntu 16.04 LTS.

Alasan mengapa saya memiliki pesan itu bukanlah yang paling umum, tetapi perlu disebutkan. Saya telah membuat skrip daftar terowongan, dan untuk memastikan presentasi kolom, saya telah mencetak setiap byte terakhir pada dua byte. Ketika saya mencoba untuk membuka penerusan terowongan ke 192.168.66.08, selalu gagal, karena '08' ditafsirkan oleh gethostbyaddr sebagai angka oktal yang tidak valid :)

Tampaknya ada banyak kemungkinan akar penyebab untuk pesan ini. Dalam kasus saya itu adalah ketidakmampuan untuk mengakses remote karena saya tidak menyediakan keyfile dengan benar.

The -Lpilihan menambahkan SSH melompat implisit (efektif menggunakan host SSH eksplisit sebagai benteng / melompat server). Mungkin lebih mudah untuk men-debug ini dengan melakukan lompatan secara eksplisit dan membuat shell login ke mesin target menggunakan "proxycommand".

Setelah ini berfungsi, Anda dapat melakukan port forward berdasarkan mesin target localhost(dengan asumsi ia bisa masuk sendiri):

-N -L 1234:localhost:1234