Come posso effettuare il tunneling di tutto il mio traffico di rete tramite SSH?


117

Ogni volta che utilizzo Internet da una posizione non sicura (come il wifi pubblico), mi piace usare un tunnel ssh ( ssh -D port host) per garantire che il mio traffico non possa essere sniffato. Sfortunatamente, sembrano esserci molte applicazioni che non forniscono un modo per specificare un proxy (Flash è un esempio importante).

Sembra che ci dovrebbe essere un modo per utilizzare un tunnel per tutto il traffico di rete dal mio computer, ma sono completamente ignaro di come farlo. Qualsiasi aiuto sarebbe molto apprezzato.


16
Ovviamente non puoi tunnelizzare letteralmente TUTTO il tuo traffico attraverso ssh, perché ciò significherebbe tunnelizzare ssh attraverso se stesso, ma sapevamo cosa intendevi. :)
CarlF

1
questa è una buona idea ma sei protetto solo tra il tuo computer e il tuo endpoint SSH. successivamente, il tuo traffico è in chiaro (se non diversamente protetto, ad es. SSL). certo, è molto più probabile che si trovi su un filo, ma comunque ... non puoi davvero fidarti di fili che non controlli.
Quack Quixote,

6
Ma quando sei su Internet, hai la sicurezza di essere solo uno dei miliardi di pacchetti, giusto? Quando ti connetti a un Wi-Fi pubblico, sei una delle forse 3 connessioni, puoi essere identificato personalmente, ecc.
endolith

Risposte:


62

Per fare quello che vuoi, ti consiglio sshuttle .

Lo usi in questo modo:

./sshuttle -r username@sshserver 0.0.0.0/0 -vv

Effettuerà automaticamente il tunneling di tutto il traffico TCP per te. Puoi aggiungere l' --dnsargomento per fare in modo che tunnel anche il tuo traffico DNS. Python deve essere installato sul server remoto.

Se vuoi solo tunnelare programmi specifici, consiglierei le proxychain .

Una volta installato, avvia il proxy ssh socks in questo modo:

ssh -fND 127.0.0.1:<local port> username@sshserver

Ciò avvierà un proxy "SOCKS" in ascolto su <porta locale>.

Quindi modifica /etc/proxychains.conf per puntare alla stessa porta di <porta locale>.

Finalmente avvia il tuo programma che vuoi proxy-ed in questo modo:

proxychains <program name>

Dovrebbe solo funzionare. Tuttavia, alcuni programmi avranno problemi a lavorare con le catene proxy. Inoltre, tieni presente che, con Firefox, devi modificare altri elementi in about: config per costringerlo a fare ricerche DNS attraverso il proxy invece di bypassarlo.

Come nota aggiuntiva, sui browser Web. Se supportano i proxy di calzini, non è necessario fare nulla in più per farli usare il tunnel ssh sopra menzionato, basta inserire 127.0.0.1 per il server proxy SOCKS e la <porta locale> per la porta proxy.

MODIFICA 29/03/16

Dal momento che questo post sta ancora vedendo alcuni voti positivi, ho pensato di aggiornarlo. Proxychains è ancora nella maggior parte dei repository Linux e funziona ancora su Linux. Tuttavia, il progetto viene effettivamente abbandonato e non funziona su OSX. Per Linux o OSX, consiglio vivamente di passare a un fork ancora gestito: proxychains-ng: https://github.com/rofl0r/proxychains-ng

Oltre a lavorare sia in Linux che in OSX, è facile da compilare e offre anche un supporto molto migliore per il tunneling DNS.

Dovrei anche menzionare un'altra opzione, che è redsocks. Funziona in modo simile alle proxychains (-ng) ed è anche probabile nel tuo repository dist: https://github.com/darkk/redsocks


Nota per i nuovi sistemi Linux che usano sshuttle: al momento della scrittura c'è un bug del kernel che ti darà la pipe rotta. In tal caso, utilizzare:sshuttle -r root@host -x host 0/0
aggregate1166877

49

man sshdà un esempio di questo esattamente. Un VPN basato su SSH:

SSH-BASED VIRTUAL PRIVATE NETWORKS
     ssh contains support for Virtual Private Network (VPN) tunnelling using
     the tun(4) network pseudo-device, allowing two networks to be joined
     securely.  The sshd_config(5) configuration option PermitTunnel controls
     whether the server supports this, and at what level (layer 2 or 3 traf-
     fic).

     The following example would connect client network 10.0.50.0/24 with
     remote network 10.0.99.0/24, provided that the SSH server running on the
     gateway to the remote network, at 192.168.1.15, allows it:

       # ssh -f -w 0:1 192.168.1.15 true
       # ifconfig tun0 10.0.50.1 10.0.99.1 netmask 255.255.255.252

~~ snip ~~

     Since a SSH-based setup entails a fair amount of overhead, it may be more
     suited to temporary setups, such as for wireless VPNs.  More permanent
     VPNs are better provided by tools such as ipsecctl(8) and isakmpd(8).

Dopo aver attivato quella nuova interfaccia, dovresti solo renderla la route predefinita, che è una domanda diversa.


1
Potresti spiegare un po 'di più? Il comando ifconfig crea una nuova interfaccia chiamata tun0, giusto? O tun0 è stato creato da ssh e ulteriormente configurato da ifconfig? Forse aggiungi un esempio pertinente alla domanda?
Nessuno il

6

Cerca l'opzione "Tunnel" in ssh. Ciò crea un dispositivo tunnel a cui è possibile assegnare un indirizzo IP e quindi si modifica il percorso predefinito per utilizzare quel tunnel.



0

NETWORK PRIVATE VIRTUALI BASATE SU SSH ssh contiene il supporto per il tunneling della rete privata virtuale (VPN) utilizzando lo pseudo-dispositivo di rete tun (4), che consente di unire in modo sicuro due reti. L'opzione di configurazione sshd_config (5) PermitTunnel controlla se il server lo supporta e a quale livello (traffico di livello 2 o 3).

 The following example would connect client network 10.0.50.0/24 with
 remote network 10.0.99.0/24 using a point-to-point connection from
 10.1.1.1 to 10.1.1.2, provided that the SSH server running on the gateway
 to the remote network, at 192.168.1.15, allows it.

 On the client:

       # ssh -f -w 0:1 192.168.1.15 true
       # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
       # route add 10.0.99.0/24 10.1.1.2

 On the server:

       # ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
       # route add 10.0.50.0/24 10.1.1.1

 Client access may be more finely tuned via the /root/.ssh/authorized_keys
 file (see below) and the PermitRootLogin server option.  The following
 entry would permit connections on tun(4) device 1 from user “jane” and on
 tun device 2 from user “john”, if PermitRootLogin is set to
 “forced-commands-only”:

   tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
   tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

 Since an SSH-based setup entails a fair amount of overhead, it may be
 more suited to temporary setups, such as for wireless VPNs.  More perma‐
 nent VPNs are better provided by tools such as ipsecctl(8) and
 isakmpd(8).

1
si prega di aggiungere una fonte per le vostre informazioni. nota: questa è una vecchia domanda.
Lorenzo Von Matterhorn,

-2

Volevo solo chiarire che (ssh -D port host) non è un modo sicuro al 100% per non sniffare il traffico. Aggiungere (ssh -D -c host port blowfish) sarebbe una scelta migliore perché stai almeno aggiungendo la crittografia alla tua sessione. Ci sono altre opzioni che potresti aggiungere ma è abbastanza semplice digitare "man ssh" nel tuo terminale o Google per un elenco completo.

L'opzione che penso che stai cercando è la creazione di una VPN (Virtual Private Network)

Dai un'occhiata a questo articolo per capire la differenza tra i due ( SSH vs. VPN ) o una buona versione riepilogata , prima di affrontare la configurazione della tua VPN. Se decidi di seguire il percorso VPN ti consiglio OpenVPN , è gratuito e offre molta documentazione e supporto.


6
cattivo consiglio. "blowfish" è un codice SSH-1; è veloce, ritenuto sicuro (a partire dal 1999: unixhelp.ed.ac.uk/CGI/man-cgi?ssh+1 ), ma comunque. probabilmente vuoi ssh -2 -C -D [...](forza SSH2, usa la compressione) e rilascia il file -c. secondo il mio sistema, man sshper impostazione predefinita , l'elenco di crittografia in SSH2 è impostato su aes128-cbc,3des-cbc,blowfish-cbc,[etc]. il punto è che, se richiedi -c blowfish, potresti finire con SSH1, che è molto meno sicuro di SSH2.
Quack Quixote,

2
È vero, ma Jeremy aveva l'impressione che la connessione fosse sicura con solo -D 8080, ho semplicemente dichiarato che era meglio di quello che stava usando. Fai un punto valido ed è per questo che menziono il manuale per ulteriori opzioni.
ricbax,

Forse dovresti cambiare la tua risposta, poiché altrimenti è utile.
endolith

Ho dimenticato di averlo chiesto, non utilizzare questo sito regolarmente. Grazie per il chiarimento ... Ho avuto la forte impressione che SSH fosse sicuro per impostazione predefinita.
Jeremy Banks,

9
WTF non è SSH che usa la crittografia di default ??
LatinSuD,

-3

Usa questi esempi:

  • Inoltra la porta 80 da un host remoto a 8888 sul tuo host locale

    ssh -fnN -L8888: localhost: 80 user @ server

    Usalo per accedere ai servizi su un host remoto che sono disponibili solo lì

  • Inoltra la porta 80 da yourlocalhost a 8888 su un host remoto

    ssh -fnN -R8888: localhost: 80 utente @ server

    Utilizzalo per consentire agli utenti di accedere ai tuoi servizi: server web o altro.

Saluti! :)


Buon commento, ma per nulla collegato a ciò di cui stiamo parlando qui. Reverse ssh consente a un SERVER di richiedere che un CLIENTE instrada una porta di traffico verso di esso. Sarebbe necessaria una maggiore configurazione per instradare il traffico su Internet. Dovresti anche impostare un tunnel SSH per ogni porta. E deve essere avviato dal server, non dal client - quale motivo dovresti mai fare a meno che non dovessi?
Beachhouse,
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.