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


185

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?


Mungkin saya kehilangan sesuatu, tetapi mengapa Anda mencoba mengakses server web menggunakan klien ssh?
Faheem Mitha

Mengapa Anda meneruskan X11 (opsi -X) di sini? Jika Anda hanya ingin meneruskan HTTP, ini tidak perlu. Dan sebagai catatan samping IMHO ssh mungkin solusi yang salah untuk membuat Webserver tersedia di banyak port.
Marcel G

29
Saya menemukan ini berarti "Tidak dapat menyelesaikan nama host remote" dalam kasus saya.
RobM

3
Seperti yang dapat Anda lihat dari selusin jawaban di bawah ini, pesan kesalahan, meskipun tampak sangat spesifik, harus dipahami sebagai kesalahan umum. Secara umum, solusinya adalah membuka shell di remote dan coba koneksi yang sama, untuk melihat penyebab sebenarnya. Anda akan menemukan jawaban di bawah ini sebagai penyebab aktual paling umum.
Stéphane Gourichon

Kegagalan resolusi DNS dapat menyebabkan kesalahan ini plus koneksi mungkin membeku sampai habis waktu: superuser.com/a/700677
user423430

Jawaban:


122

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.


Di sini apa yang saya tambahkan secara khusus di sshd_config untuk membuatnya berfungsi: TCPKeepAlive ya AllowTCPForwarding ya PermitOpen apa pun yang saya punya beberapa "buka gagal" tetapi tampaknya hal yang normal. Segalanya bekerja dengan sangat baik.
Pierre Thibault

4
Kasing sudut yang perlu diperhatikan: Anda bisa mendapatkan kesalahan ini ketika mencoba membuat perangkat tap / tun dengan SSH dan SSH memungkinkannya, tetapi kernel tidak. Ini dapat terjadi dalam wadah LXC. Lihat blog.felixbrucker.com/2015/10/10/01/... untuk detail yang tepat, tetapi dalam hal ini Anda mungkin ingin menambahkan lxc.cgroup.devices.allow = c 10:200 rwmke konfigurasi wadah Anda, dan memastikan bahwa jika /dev/net/tuntidak ada, mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tundijalankan saat boot dalam wadah.
Azendale

@ Azendale, itu menarik, terima kasih. Apakah ini menghasilkan pesan kesalahan yang sama persis, atau sesuatu yang sedikit berbeda?
hyperair

1
@ St.Antario, AllowTcpForwardingmemungkinkan Anda untuk meneruskan port TCP melalui SSH, yang merupakan -L 0.0.0.0:8984:remote:8983parameter yang diminta. Jika AllowTcpForwardingdiatur ke no, SSH akan menolak permintaan penerusan port, menyebabkan Anda melihat kesalahan itu.
hyperair

2
Mencoba mengedit huruf besar dari AllowTCPForwardingto AllowTcpForwarding, tetapi SE ingin setidaknya 6 karakter diubah. Jadi, hanya mencatat bahwa case yang benar adalah Tcpversi, seperti yang digunakan dengan benar pertama kali.
dbreaux

51

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.


2
Terima kasih, ini masalah buat saya. Saya membuat nama host untuk IP secara lokal tetapi tidak pada server ssh jarak jauh.
dev_feed

2
"nama host target terowongan Anda" agak sulit untuk diuraikan. Bisakah Anda memberikan contoh nyata yang memungkinkan saya untuk mengambil contoh dan mengganti "nama host target" dalam contoh Anda dengan nama host target saya (setelah saya mengerti apa yang Anda maksud dengan itu) dan memiliki karya ini?
Terrence Brannon

1
Saya bahkan tidak yakin komentar Anda masuk akal. Anda mengatakan bahwa mesin jarak jauh tidak memiliki entri untuk localhost. Tetapi kemudian katakan bahwa host jarak jauh harus menyelesaikan nama host target bukan nama host lokal. Sekali lagi contoh konkret yang lengkap dari situasi sebelum dan sesudah akan sangat membantu.
Terrence Brannon

1
@TerrenceBrannon pada perintah di atas, "localhost" adalah nama host target terowongan . Saat membuat terowongan SSH, perintah ssh pertama-tama masuk ke sistem jarak jauh ( user@remote), kemudian dari ujung jarak jauh, ia menyiapkan terowongan ke host target yang terdaftar (dalam perintah di atas ini adalah localhost). Saat melakukan ini, ia menggunakan skema resolusi nama host pada host jarak jauh . Jadi jika mesin yang Anda masuki SSH tidak dapat menyelesaikannya localhost, Anda akan mendapatkan pesan kesalahan ini.
cobbzilla

1
Dalam kasus saya, sesederhana telah salah ketik nama host target, jadi tentu saja itu tidak menyelesaikan, tetapi mata saya rindu melihat kesalahan ketik terlalu lama.
Randall

25

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


2
Bukan itu; Saya menggunakan icmp-admin-terlarang sebagai flag tolak dalam konfigurasi firewall sepanjang waktu.
Shadur

9
+1, Pesan yang dilarang secara administratif akan membuat orang percaya bahwa itu adalah penyumbatan firewall, namun Anda menerima pesan yang sama ketika tidak ada penyumbatan firewall tetapi pembukaan gagal karena tidak ada rute ke host jarak jauh.
Steve Buzonas

1
Saya baru saja menghabiskan beberapa menit berburu masalah ini, yang pesannya tidak masuk akal dalam konteks saya ke bawah. Untungnya cukup jelas setelah memeriksa file log stasiun tengah.
yaccz

Memang jika "jarak jauh" tidak dapat dijangkau - karena tidak aktif, offline, tidak ada, nama host tidak menyelesaikan - maka Anda akan melihat pesan kesalahan ini.
Michael Martinez

18

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


Anda juga dapat melihat kesalahan yang sama saat menggunakan -D(DynamicForward) sebagai proxy SOCKS di browser. Yaitu mencoba mengakses situs web yang tidak dapat diselesaikan oleh host terowongan.
timss

10

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.


Saya datang ke sini mencari tempat untuk menetapkan batas multipleks ControlMaster ini. Jika ada yang tahu, mereka dipersilakan untuk berbagi.
clacke

1
clacke: sesuai dengan bugs.debian.org/cgi-bin/bugreport.cgi?bug=546854 Anda dapat menambahkan parameter MaxSession di file / etc / ssh / sshd_config untuk mengatur ini. Menurut halaman manual, ini diatur ke 10 secara default.
oliver

@oliver: mengonfirmasi, MaxSession berfungsi, terima kasih. menabrak 64 di buku kerja saya.
Matej Kovac

2
Hati-hati, ini bukan MaxSessiontapi MaxSessions. Meskipun ada beberapa perlindungan, jangan hancurkan konfigurasi server ssh Anda ...
Stéphane Gourichon

8

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

Periksa pengaturan iptables Anda.


5
Belum tentu. Pesan dihasilkan ketika tuan rumah tidak dapat melayani permintaan. Kasus ini umumnya karena admin telah memblokir koneksi, tetapi bisa juga karena tidak diblokir secara eksplisit tetapi tidak ada rute ke host yang diinginkan. AFAIK sshtidak memiliki logika untuk menentukan mengapa koneksi gagal, itu hanya mengasumsikan bahwa jika Anda mencoba untuk terhubung, maka itu ada, dan jika Anda tidak bisa sampai di sana, koneksi harus diblokir dengan sengaja.
Steve Buzonas

2
Eh, tidak. Ada perbedaan yang jelas antara jenis respons ICMP yang mengatakan "tidak ada rute untuk menjadi tuan rumah" dan yang mengatakan "dilarang secara administratif", dan kecuali jika seseorang dengan sengaja salah mengonfigurasi perute, yang terakhir berarti persis seperti yang dikatakan di kaleng.
Shadur

1
Saya baru saja 'dilarang secara administratif' saat menggunakan nama host yang tidak menyelesaikan, jadi sepertinya cukup menarik. Mungkin ssh melakukan terjemahan?
Ganesh Sittampalam

5

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


localhost kemungkinan dipetakan ke :: 1 (ipv6) dan Anda tidak mendengarkannya karena alasan tertentu
Jo Rhett

4

Ini juga terjadi ketika /etc/sshd_configsudah

AllowTcpForwarding no 

set. Alihkan ke yesuntuk memungkinkan penerusan TCP.


4

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

Terima kasih banyak!
Thibaut Barrère

3

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

3

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.

3

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

2

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


2

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


2

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.


1

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.


1

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.


1

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.


0

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

Penerowongan AFAIK diaktifkan secara default karena penonaktifan tidak menambah lapisan keamanan apa pun, terutama hanya ketidaknyamanan menambahkan terowongan pihak ke-3. Saya mengalami masalah yang sama dengan mencoba proxy ke server internal dari lokasi luar dan tunneling diaktifkan + iptables memerah dengan aksi default ACCEPT.
Steve Buzonas

@SteveBuzonas Saya melihat ini di / etc / sshd_config jadi a) tidak menonaktifkan tunneling b) mengenai jawaban saya, solusinya mungkin tidak ada ide yang baik. Inilah yang dikatakan sshd_config tentang opsi itu # Untuk menonaktifkan kata sandi teks yang disetel, ubah menjadi tidak ada di sini! #PermitTunnel no
barlop

@SteveBuzonas periksa yang Anda mungkin disetel ke tidak dan Anda dapat tunnel karena memang tunneling diaktifkan secara default.
barlop

Saya sedang memikirkan AllowTCPForwarding, Komentar yang Anda bicarakan # To disable tunneled clear textadalah sehubungan dengan PasswordAuthenticationdisetel ke tidak, PermitTunneladalah pengaturan untuk mengizinkan terowongan jaringan layer 2 atau layer 3 melalui tun / tap dan default ke no. Opsi L, R, dan D menggunakan penerusan TCP dan bukan perangkat untuk penerowongan.
Steve Buzonas

0

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.


Tip umum yang bermanfaat tetapi bukan jawaban untuk pertanyaan yang diajukan.
Kyle Jones

0

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


0

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.


0

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)

0

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

1
Jika Anda akan menautkan, mempromosikan, mengutip dari atau merujuk sesuatu yang berafiliasi dengan Anda, Anda harus secara eksplisit mengungkapkan afiliasi itu. Mengatakan '' sambil mengumpulkan (tautan) '' tidak cukup (karena saya tidak mengerti apa artinya sampai setelah saya mengetahui bahwa Anda menautkan ke blog Anda sendiri); memiliki URL yang cocok dengan nama pengguna Stack Exchange Anda tidak cukup. Referensi: Bagaimana tidak menjadi spammer ,  Hindari promosi diri yang terang-terangan , ... (Lanjutkan)
Scott

(Lanjutkan) ... dan Kapan kami harus menegakkan persyaratan afiliasi?    Anda bebas menyebutkan blog Anda, perusahaan Anda, semua perangkat lunak terkenal yang Anda kembangkan, buku apa pun yang telah Anda tulis, proyek apa pun yang Anda atau telah terafiliasi, dll., Di halaman profil pengguna Anda .
Scott

0

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.


0

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


0

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
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.