ssh tunnel - bind: Tidak dapat menetapkan alamat yang diminta


26

Mencoba membuat ssh tunnel (-D) - kotak Linux ke kotak Linux (keduanya centos):

sshd berjalan di sisi yang jauh ok.

Dari mesin lokal kami / melihat ini:

ssh -D 1080 user@8.8.8.8.
user@8.8.8.8's password: 
bind: Cannot assign requested address

(di mana 8.8.8.8 adalah IP server saya dan 'pengguna' adalah nama pengguna saya yang sebenarnya)

Saya masuk ke sisi jarak jauh di jendela terminal ini. Saya dapat memverifikasi bahwa port lokal tidak digunakan sebelum perintah ini, dan kemudian digunakan oleh proses ssh, setelah perintah, melalui:

netstat -lnp | grep 1080

Jadi, tidak seperti kebanyakan respons yang googled dengan kesalahan ini, masalahnya tidak akan menjadi tugas antarmuka loopback. Jika saya mencoba menggunakan terowongan ini dengan klien email, pihak lokal mengizinkan upaya (tidak ada kesalahan 'proxy-gagal'), tetapi tidak ada data / balasan dikembalikan.

Di sisi jarak jauh, saya punya "PermitTunnel ya" di sshd_config saya (walaupun 'ya' harus menjadi default, sih).

Gagasan atau Petunjuk?

Berikut ini adalah hasil debug yang relevan

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *

....

debug1: Authentication succeeded (password).
debug1: Local connections to LOCALHOST:1080 forwarded to remote address socks:0
debug1: Local forwarding listening on 127.0.0.1 port 1080.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on ::1 port 1080.
bind: Cannot assign requested address
debug1: channel 1: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.utf8

Petunjuk lain: Jika saya menjalankan Kotak Virtual pada klien yang menjalankan Windows, buka sebuah terowongan dengan dempul di dalam kotak itu, terowongan itu, ke server jarak jauh yang sama, berfungsi.

Asing Masih "Jika saya menggunakan Putty (untuk linux) berjalan langsung pada Klien Linux, itu TIDAK bekerja, bahkan jika pengaturannya adalah duplikat yang tepat dari pengaturan dempul yang BEKERJA di Putty berjalan pada Windows dalam Kotak Virtual pada saat yang sama Mesin Klien ?? Ada sesuatu yang mencurigakan ... masih mencoba eksperimen untuk mencari tahu apa itu.


Bagaimana jika Anda mencoba dan memaksanya untuk menggunakan ipv4? (Sama seperti tes pemecahan masalah awal). Misalnya ssh -4 -D 1080 user@8.8.8.8
Fred Clausen

Bisakah Anda mencoba nomor port yang lebih tinggi, 4000?
jwbensley

Terima kasih atas masukannya. Saya mulai bekerja dengan: ssh -4 -D 8081 user@8.8.8.8
JosephK

Jawaban:


41

Tutup loop di sini. Jawabannya, dalam hal ini, adalah untuk memaksa klien ssh untuk menggunakan ipv4. Misalnya

ssh -4 -D 8081 user@8.8.8.8

Jadi saya akan berpikir, kecuali bahwa saya dapat memilih 'force ip4' di dempul (berjalan di Linux) tanpa hasil. Juga IPV6 dinonaktifkan pada mesin ini, jadi secara teori seharusnya tidak dimainkan. Hasil yang sama sekali tidak konsisten saya masih bisa mencoba permutasi yang berbeda dari hal ini membuat saya menggaruk-garuk kepala. Bagaimanapun, jawaban Anda membantu saya membuatnya berfungsi, dan mungkin telah menemukan sesuatu yang aneh tentang bagaimana versi CentOS atau Kernel Linux ini beroperasi - Terima kasih.
JosephK

Sebuah tembakan panjang tapi mungkin mematikan resolusi DNS SSH di server, "UseDNS no" di sshd_config, mungkin menyelesaikannya. Mungkin beberapa resolusi DNS aneh terjadi di server yang menyebabkan masalah mengikat.
Fred Clausen

1
Terima kasih banyak, -4 juga merupakan solusi untuk Ubuntu 11.04.
Sander

Saya mulai mengalami masalah ini setelah memutakhirkan ke Ubuntu 13.04, dan ini adalah perbaikannya.
Nick

1
Daripada harus menentukan -4 setiap kali, dengan asumsi semua koneksi ssh dibuat hanya dengan IPv4, tambahkan "inet AddressFamily" ke file ssh_config Anda - per pengguna dalam $ {HOME} /. Ssh / ssh_config, atau sistem untuk semua pengguna di / etc / ssh / ssh_config
JG Miller
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.