ssh tunnel - bind: Nie można przypisać żądanego adresu

Próba utworzenia tunelowego ssh (-D) tunelu ssh - Linux box do Linux box (oba centos):

sshd działa po stronie zdalnej ok.

Z lokalnego komputera robimy / widzimy to:

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

(gdzie 8.8.8.8 to tak naprawdę adres IP mojego serwera, a „użytkownik” to moja prawdziwa nazwa użytkownika)

Jestem zalogowany do odległej strony w tym oknie terminala. Mogę sprawdzić, czy port lokalny był nieużywany przed tą komendą, a następnie używany przez proces ssh, po komendzie, poprzez:

netstat -lnp | grep 1080

Tak więc, w przeciwieństwie do większości odpowiedzi Google z tym błędem, problemem nie wydaje się być przypisanie interfejsu sprzężenia zwrotnego. Jeśli spróbuję użyć tego tunelu z klientem poczty, strona lokalna zezwala na próbę (nie występuje błąd „błąd serwera proxy”), ale dane / odpowiedź nie są zwracane.

Po drugiej stronie mam „PermitTunnel yes” w moim sshd_config (choć „tak” powinno być i tak domyślne).

Pomysły czy wskazówki?

Oto odpowiedni wynik debugowania

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

Inna wskazówka: jeśli uruchomię Virtual Box na kliencie z systemem Windows, otwórz tunel z kitem w tym polu, ten tunel, na tym samym zdalnym serwerze, działa.

Stranger Still ”Jeśli używam Putty (dla systemu Linux) działającego bezpośrednio na kliencie Linux, NIE działa, nawet jeśli ustawienia są dokładną kopią ustawień putty, które DZIAŁAJĄ w Putty działającym w systemie Windows w wirtualnym pudełku na tym samym Client Machine? Jest coś podejrzanego ... wciąż próbuję eksperymentów, aby dowiedzieć się, co to jest.

linux ssh tunnel

— JosephK
źródło

Co jeśli spróbujesz zmusić go do używania ipv4? (tylko jako wstępny test rozwiązywania problemów). Eg ssh -4 -D 1080 user@8.8.8.8

— Fred Clausen

Czy możesz wypróbować wyższy numer portu, 4000?

— jwbensley

Dzięki za wkład. Mam go do pracy z: ssh -4 -D 8081 użytkownik@8.8.8.8

— JosephK

Zamknij pętlę tutaj. W tym przypadku odpowiedzią było zmuszenie klienta ssh do użycia ipv4. Na przykład

ssh -4 -D 8081 user@8.8.8.8

— Fred Clausen
źródło

Pomyślałbym, poza tym, że bez powodzenia mogę wybrać opcję „force ip4” w putty (działającą w systemie Linux). Również IPV6 jest wyłączony na tym komputerze, więc teoretycznie nie powinien być w grze. Całkowicie niespójne wyniki, w których wciąż próbuję różnych permutacji tej rzeczy, powodują, że drapię się po głowie. W każdym razie twoja odpowiedź pomogła mi ją uruchomić i być może odkryłem coś dziwnego w tym, jak działa ta wersja jądra CentOS lub Linux lub coś w tym stylu - dzięki.

— JosephK,

Długie ujęcie, ale być może wyłączenie rozdzielczości SSH DNS na serwerze „UseDNS no” w sshd_config, może go rozwiązać. Być może na serwerze dzieje się dziwne rozwiązanie DNS, które powoduje problemy z wiązaniem.

— Fred Clausen

Wielkie dzięki, -4 było również rozwiązaniem dla Ubuntu 11.04.

— Sander,

Zacząłem mieć ten problem po aktualizacji do Ubuntu 13.04 i to była poprawka.

— Nick

Zamiast konieczności podawania -4 za każdym razem, zakładając, że wszystkie połączenia ssh będą nawiązywane tylko za pomocą IPv4, dodaj „AddressFamily inet” do pliku ssh_config - na użytkownika w $ {HOME} /. Ssh / ssh_config, lub dla całego systemu dla wszyscy użytkownicy w / etc / ssh / ssh_config

— JG Miller