Parfois nous avons besoin transmettre des données via une prise entre différentes machines, comme une connexion Telnet, un téléchargement de fichier FTP, une requête SQL ou tout autre type de transmission.
Ces données transitent brutes à travers le réseau, donc peu sûr, ce qui signifie qu'ils pourraient être interceptés par n'importe quel nœud qui se trouve sur le chemin entre l'origine et la destination, c'est-à-dire volé.
Nous ne pouvons pas empêcher la capture de ces données, mais ce que nous pouvons empêcher, c'est qu'elles soient interprétées et comprises par des tiers, en cryptant la communication.
SSH est l'outil qui nous permet de faire connexions sécurisées entre les machines. Son utilisation la plus courante est de se connecter à distance à un interpréteur de commandes.
Cependant, il offre d'autres possibilités, comme la création tunnels cryptés entre différentes machines.
Supposons que nous voulions effectuer un telnet de host1 à host2:
host1$ telnet host2
Cette communication est totalement ouverte et peut être intercepté. Pour le protéger, nous redirigerons un port choisi arbitrairement (par exemple 5000) sur l'hôte 1 vers le port 23 (telnet) sur l'hôte2.
De cette façon, nous obtiendrons toutes les données envoyées au port 5000 de host1 pour voyager cryptées à travers le tunnel que ssh ouvre via le port 22 de host2 et ensuite être redirigées vers le port 23 de host2, atteignant ainsi sa destination finale.
Pour ce faire, nous devons connaître le nom d'utilisateur et le mot de passe de host2.
Pour ouvrir le tunnel, nous écrivons:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
ou bien:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
Les deux options sont équivalentes. Pour établir la connexion telnet, on ne se réfère plus à host2 mais au port choisi sur host1:
host1$ telnet localhost 5000
Avec cela, nous sécurisons toute communication, que ce soit telnet ou autre. En enquêtant un peu plus, nous verrons que grâce à la puissance de SSH ces redirections peuvent également être effectuées vers des machines tierces, ce qui nous permettrait qu'avec un seul point d'entrée, nous pourrions accéder en toute sécurité d'un LAN entier à un autre LAN.
La théorie semble extrêmement intéressante, mais elle le serait encore plus si nous voyions un cas pratique.
Mais la vérité est que, même si j'étais petit, j'ai adoré l'article.
peut-être en regardant le wiki que vous vous inspirez https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
et la même chose, mais la section autossh https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
En fait, tout ce que vous pouvez envoyer par ssh, qu'il s'agisse de streaming, de connexions à l'hôte. etc. que pour x raison vous voulez les crypter.
et les règles de sécurité
J'utilise parfois SSH à un niveau très basique. Le port par défaut est 22, non?
Donc, si je comprends bien, mon pc est l'hôte 1 et celui auquel je veux me connecter est host2, ce tunnel créerait une connexion entre le port 5000 et son port 23, puis finirait sur le port 22?
Pourquoi les raisons de changer de port? Pouvez-vous créer un tunnel avec le port 22?
Article très intéressant. Comme nano, j'en veux plus!
SSH utilise en effet le port 22 par défaut (bien qu'il puisse être modifié). Ce port est celui qui serait utilisé par la communication réelle entre les deux hôtes. C'est celui que vous devez vous assurer qu'il est ouvert et qu'aucun pare-feu ne le coupe. Mais pour l'utilisateur, c'est totalement transparent. Vous pouvez l'oublier. Dans l'exemple, la redirection se fait entre les ports 5000 et 23. Ces deux sont les seuls dont vous devez vous soucier. L'utilisateur verra que tout ce qu'il envoie au port 5000 de son hôte apparaît à 23 de l'hôte de destination.
Évidemment, chaque utilisateur peut rediriger les ports qu'il juge appropriés.
Merci pour vos commentaires. Ceci est mon premier message et vos opinions aideront à améliorer le prochain.
Cela peut-il également être fait avec VPS?
Ok c'est mon cas, PC1 a accès à un serveur, mais PC2 ne le fait pas, les deux se connectent par ssh, je veux avoir accès en PC2, mais quel port de PC1 dois-je rediriger? si en fait ce que je veux, c'est atteindre le port du serveur depuis PC2 et que les paquets ont PC1 comme IP source. je comprends
Vous vous faites comprendre. Dans ce cas, vous avez besoin de PC1 pour rediriger un port de PC2 vers le port 22 du serveur:
PC2 $ ssh -L 5000: Serveur: 22 utilisateurs PC1 @ PC1
et, en gardant cette connexion ouverte, depuis un autre terminal:
PC2 $ ssh userServer @ localhost -p 5000
et vous êtes déjà à l'intérieur.
Enfin une solution fonctionnelle !! Merci Getafix, vous m'avez offert un monde de possibilités !!
Je suis contente!
Excellent article. Bienvenue à DesdeLinux 😀
Et que faire si nous avons bloqué? LOL ..
Merci elav.
Si vous avez le port 22 bloqué, mmmm, nous devrons chercher une alternative pour pirater le pare-feu XD
Et le pire de tous (hypothétique): qu'il est bloqué par le fournisseur VPS.
Je viens de passer un examen il y a quelques heures avec des questions à ce sujet 😛
Je ne dirais pas ça:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
c'est équivalent à l'autre ligne de commande ... celle avec le -L.
Puisque -R indique que le port ouvert à de nouvelles connexions est du côté distant, c'est-à-dire du côté de votre serveur ssh; tandis que -L ouvre un port côté local, côté client pour recevoir de nouvelles connexions.
La traduction de la ligne:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
Ce serait quelque chose comme ceci: étant sur host1, connectez-vous au serveur ssh (port 22) de host2 avec mon utilisateur userhost2 et transférez les connexions générées sur le port distant 5000 de host2 vers le port 23 sur host1 (mon localhost)
Sinon, corrigez-moi! 😉
-
Par contre ... si un serveur a bloqué l'entrée des connexions sur le port 22, c'est-à-dire que nous ne pouvons pas nous connecter à distance au serveur ssh; ce qui peut être fait est; que depuis le serveur (un administrateur système ami derrière le pare-feu du système hôte2 distant) une ligne de commande est exécutée:
hôte2 $ nohup ssh -fN -R 6000: hôte local: 22 hôte1 utilisateur @ hôte1
-f passe en arrière-plan
-N n'exécute aucune commande sur la télécommande
nohup empêche l'exécution de la commande d'être interrompue lors de la déconnexion
hôte1 $ ssh userhost2 @ localhost -p 6000
De cette façon, à partir de host1, nous générons une connexion à localhost (le même host1) sur le port 6000 qui transmettra la connexion au port 22 du système distant host2, dans lequel nous nous connecterons avec l'utilisateur host2.
Cela permettrait (je ne l'ai pas essayé, mais il semble que cela fonctionne) de se connecter à un serveur ssh bloqué par firewal avec un peu d'aide de l'intérieur! 😀
Ce dernier, j'ai lu une explication faite dans le magazine The Geek Stuff
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
J'aime beaucoup votre publication; Je les lis souvent!
Salutations.
Vous avez raison. Il y a une erreur dans l'article. Les redirections ne sont pas équivalentes. La commande host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 effectue la redirection inverse, c'est-à-dire qu'elle redirige le port distant 5000 vers le 23 local, le contraire de ce que fait la commande avec -L.
Merci pour la correction.