A volte abbiamo bisogno trasmettere i dati tramite un socket tra macchine diverse, come una connessione Telnet, un download di file FTP, una query SQL o qualsiasi altro tipo di trasmissione.
Quei dati viaggiano grezzi attraverso la rete, quindi pericoloso, il che significa che potrebbero essere intercettati da qualsiasi nodo che si trova sul percorso tra l'origine e la destinazione, cioè Robados.
Non possiamo impedire che questi dati vengano catturati, ma ciò che possiamo impedire è che vengano interpretati e compresi da terzi, crittografando la comunicazione.
SSH è lo strumento che ci permette di fare connessioni sicure tra le macchine. Il suo utilizzo più comune è connettersi in remoto a un interprete di comandi.
Tuttavia, offre altre possibilità, come la creazione tunnel crittografati tra macchine diverse.
Supponiamo di voler telnet da host1 a host2:
host1$ telnet host2
Questa comunicazione è totalmente aperta e può esserlo intercettato. Per proteggerlo, reindirizzeremo una porta scelta arbitrariamente (ad esempio 5000) sull'host 1 alla porta 23 (telnet) sull'host2.
In questo modo faremo in modo che tutti i dati inviati alla porta 5000 di host1 viaggino crittografati attraverso il tunnel che ssh apre attraverso la porta 22 di host2 per poi essere reindirizzati alla porta 23 di host2, raggiungendo così la sua destinazione finale.
Per fare ciò, dobbiamo conoscere il nome utente e la password di host2.
Per aprire il tunnel scriviamo:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
Oh bene:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
Entrambe le opzioni sono equivalenti. Per stabilire la connessione telnet, non facciamo più riferimento a host2 ma alla porta scelta su host1:
host1$ telnet localhost 5000
Con questo rendiamo sicura qualsiasi comunicazione, sia essa telnet o altro. Indagando un po 'di più lo vedremo grazie al potere di SSH Questi reindirizzamenti possono essere effettuati anche su macchine terze, il che ci consentirebbe di accedere in sicurezza da un'intera LAN a un'altra LAN con un unico punto di ingresso.
La teoria sembra estremamente interessante, ma lo sarebbe ancora di più se vedessimo un caso pratico.
Ma la verità è che, anche se ero basso, ho adorato l'articolo.
magari guardando il wiki ti ispiri https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
e lo stesso, ma la sezione autossh https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
In realtà, tutto ciò che puoi inviare tramite ssh, sia esso streaming, connessioni all'host. eccetera. che per x motivo vuoi crittografarli.
e le regole di sicurezza
A volte uso SSH a un livello molto elementare. La porta predefinita è 22, giusto?
Quindi, se ho capito bene, il mio PC è host 1 e quello a cui voglio connettermi è host2, questo tunnel creerebbe una connessione tra la porta 5000 e la sua porta 23, per poi finire sulla porta 22?
Perché i motivi per cambiare porta? Puoi creare un tunnel con la porta 22?
Articolo molto interessante. Come nano, voglio di più!
SSH utilizza effettivamente la porta 22 per impostazione predefinita (sebbene possa essere modificata). Questa porta è quella che verrebbe utilizzata dalla comunicazione effettiva tra i due host. È quello che devi assicurarti che sia aperto e che nessun firewall lo tagli. Ma per l'utente è totalmente trasparente. Puoi dimenticarti di lui. Nell'esempio, il reindirizzamento è tra le porte 5000 e 23. Quelle due sono le uniche di cui ti devi preoccupare. L'utente vedrà che tutto ciò che invia alla porta 5000 del suo host appare alle 23 dell'host di destinazione.
Ovviamente ogni utente può reindirizzare le porte che ritiene appropriate.
Grazie per i tuoi commenti. Questo è il mio primo post e le tue opinioni aiuteranno a migliorare il prossimo.
Può essere fatto anche con VPS?
Ok questo è il mio caso, PC1 ha accesso a un server, ma PC2 no, entrambi si connettono tramite ssh, voglio avere accesso in PC2, ma quale porta di PC1 devo reindirizzare? se effettivamente quello che voglio è raggiungere la porta del server da PC2 e che i pacchetti abbiano PC1 come loro ip sorgente. ho capito?
Ti fai capire. In questo caso è necessario che PC1 reindirizzi una porta di PC2 alla porta 22 del server:
PC2 $ ssh -L 5000: Server: 22 utenti PC1 @ PC1
e, mantenendo aperta questa connessione, da un altro terminale:
PC2 $ ssh userServer @ localhost -p 5000
e sei già dentro.
Finalmente una soluzione funzionale !! Grazie Getafix, mi hai dato un mondo di possibilità !!
Sono contento!
Ottimo articolo. benvenuto a DesdeLinux 😀
E cosa fare se ne abbiamo 22 bloccati? LOL ..
Grazie elav.
Se hai la porta 22 bloccata, mmmm, dovremo cercare un'alternativa per hackerare il firewall XD
E peggio di tutto (ipotetico): che sia bloccato dal provider VPS.
Ho appena fatto un esame poche ore fa con domande a riguardo 😛
Non direi che:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
è equivalente all'altra riga di comando ... quella con -L.
Poiché -R indica che la porta aperta a nuove connessioni si trova sul lato remoto, cioè sul lato del tuo server ssh; mentre -L apre una porta sul lato locale, sul lato client per ricevere nuove connessioni.
La traduzione della linea:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
Sarebbe qualcosa del genere: essendo su host1, connettiti al server ssh (porta 22) di host2 con il mio utente userhost2 e inoltra le connessioni generate sulla porta remota 5000 di host2 alla porta 23 su host1 (il mio host locale)
In caso contrario, correggimi! 😉
-
D'altra parte ... se un server ha bloccato l'ingresso delle connessioni alla porta 22, cioè, non possiamo connetterci da remoto al server ssh; quello che si può fare è; una riga di comando viene eseguita dal server (un amico amministratore di sistema dietro il firewall del sistema host2 remoto):
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f va in background
-N non esegue alcun comando sul telecomando
nohup impedisce che l'esecuzione del comando venga interrotta al logout
host1 $ ssh userhost2 @ localhost -p 6000
In questo modo, da host1 generiamo una connessione a localhost (lo stesso host1) sulla porta 6000 che inoltrerà la connessione alla porta 22 del sistema remoto host2, nella quale ci collegheremo con l'utente host2.
Ciò consentirebbe (non l'ho provato, ma sembra che funzioni) di accedere a un server ssh bloccato da firewal con un piccolo aiuto dall'interno! 😀
Quest'ultimo l'ho letto da una spiegazione fatta nella rivista The Geek Stuff
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
Mi piace molto la tua pubblicazione; Li leggo spesso!
Saluti.
Hai ragione. C'è un errore nell'articolo. I reindirizzamenti non sono equivalenti. Il comando host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 esegue il reindirizzamento inverso, ovvero reindirizza la porta remota 5000 alla 23 local, l'opposto di ciò che fa il comando con -L.
Grazie per la correzione.