ssh tunnel - bind: impossibile assegnare l'indirizzo richiesto


26

Cercando di creare un tunnel ssh socks (-D) - Linux box to Linux box (entrambi i centesimi):

sshd in esecuzione sul lato remoto ok.

Dalla macchina locale facciamo / vediamo questo:

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

(dove 8.8.8.8 è in realtà l'IP del mio server e "user" è il mio vero nome utente)

Sono collegato al lato remoto in questa finestra del terminale. Posso verificare che la porta locale non sia stata utilizzata prima di questo comando e quindi utilizzata da un processo ssh, dopo il comando, tramite:

netstat -lnp | grep 1080

Quindi, a differenza della maggior parte delle risposte su Google con questo errore, il problema non sembrerebbe essere l'assegnazione dell'interfaccia di loopback. Se provo a utilizzare questo tunnel con un client di posta, il lato locale consente il tentativo (nessun errore "proxy non riuscito"), ma non vengono restituiti dati / risposte.

Sul lato remoto, ho "PermitTunnel yes" nel mio sshd_config (anche se 'yes' dovrebbe essere l'impostazione predefinita, comunque).

Idee o indizi?

Ecco l'output di debug rilevante

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

Altro indizio: se eseguo una Virtual Box sul client che esegue Windows, apro un tunnel con stucco in quella casella, quel tunnel, sullo stesso server remoto, funziona.

Stranger Still "Se uso Putty (per Linux) in esecuzione direttamente sul client Linux, NON funziona, anche se le impostazioni sono un duplicato esatto delle impostazioni di putty che FUNZIONANO in Putty in esecuzione su Windows in una scatola virtuale sullo stesso Client Machine ?? C'è qualcosa di sospetto ... sto ancora provando esperimenti per capire di cosa si tratta.


Cosa succede se provi a forzarlo a utilizzare ipv4? (proprio come un test iniziale di risoluzione dei problemi). Ad esempio ssh -4 -D 1080 user@8.8.8.8
Fred Clausen,

Puoi provare un numero di porta più alto, 4000?
jwbensley,

Grazie per gli input. Ho capito che funziona con: ssh -4 -D 8081 user@8.8.8.8
JosephK

Risposte:


41

La chiusura del loop qui. La risposta, in questo caso, è stata quella di forzare il client ssh a usare ipv4. Per esempio

ssh -4 -D 8081 user@8.8.8.8

Quindi penso, tranne che posso selezionare 'force ip4' in putty (in esecuzione su Linux) senza successo. Anche IPV6 è disabilitato su questa macchina, quindi teoricamente non avrebbe dovuto essere in gioco. I risultati completamente incoerenti che provo ancora con diverse permutazioni di questa cosa mi lasciano grattarmi la testa. In ogni caso, la tua risposta mi ha aiutato a farlo funzionare e forse ha scoperto qualcosa di strano su come funziona questa versione di CentOS o Linux Kernel o qualcosa del genere - Grazie.
JosephK,

Una possibilità, ma forse la disattivazione della risoluzione DNS SSH sul server, "UseDNS no" in sshd_config, potrebbe risolverlo. Forse una strana risoluzione DNS sta funzionando sul server causando problemi di bind.
Fred Clausen,

1
Grazie mille, la -4 era anche la soluzione per Ubuntu 11.04.
Sander,

Ho iniziato ad avere questo problema dopo l'aggiornamento a Ubuntu 13.04, e questa era la soluzione.
Nick

1
Invece di dover specificare -4 ogni volta, supponendo che tutte le connessioni ssh debbano essere fatte solo con IPv4, aggiungi "AddressFamily inet" al tuo file ssh_config - per utente in $ {HOME} /. Ssh / ssh_config, oppure a livello di sistema per tutti gli utenti in / etc / ssh / ssh_config
JG Miller
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.