J'aime expliquer ce genre de chose à travers la visualisation. :-)
Pensez à vos connexions SSH en tant que tubes. Gros tubes. Normalement, à travers ces tubes, vous exécuterez un shell sur un ordinateur distant. Le shell s'exécute dans un terminal virtuel (tty). Mais vous connaissez déjà cette partie.
Pensez à votre tunnel comme un tube dans un tube. Vous avez toujours la grande connexion SSH, mais l'option -L ou -R vous permet de configurer un tube plus petit à l'intérieur.
Chaque tube a un début et une fin. Le grand tube, votre connexion SSH, a commencé avec votre client SSH et se termine sur le serveur SSH auquel vous êtes connecté. Tous les tubes plus petits ont les mêmes extrémités, sauf que le rôle de "début" ou de "fin" est déterminé par leur utilisation -L
ou -R
(respectivement) pour les créer.
(Vous ne l'avez pas dit, mais je vais supposer que la machine "distante" que vous avez mentionnée, celle derrière le pare-feu, peut accéder à Internet à l'aide de la traduction d'adresses réseau (NAT). C'est assez important, alors veuillez corriger cette hypothèse si elle est fausse.)
Lorsque vous créez un tunnel, vous spécifiez une adresse et un port sur lesquels il va répondre, ainsi qu'une adresse et un port sur lesquels il sera livré. L' -L
option indique au tunnel de répondre du côté local du tunnel (l'hôte exécutant votre client). L' -R
option indique au tunnel de répondre du côté distant (le serveur SSH).
Donc ... Pour pouvoir passer de SSH à partir d’Internet dans une machine derrière un pare-feu, vous avez besoin que la machine en question ouvre une connexion SSH au monde extérieur et inclue un -R
tunnel dont le point "entrée" est le côté "distant" de sa connexion.
Parmi les deux modèles présentés ci-dessus, vous voulez celui de droite.
Depuis l'hôte avec pare-feu:
ssh -f -N -T -R22222:localhost:22 yourpublichost.example.com
Cela indique à votre client d'établir un tunnel avec un -R
point d'entrée emote. Tout ce qui se connecte au port 22222 situé à l'extrémité distante du tunnel atteindra en réalité "le port localhost 22", où "localhost" se situe du point de vue du point de sortie du tunnel (votre client ssh).
Les autres options sont:
-f
indique à ssh de se fonder après son authentification pour ne pas avoir à exécuter quelque chose sur le serveur distant pour que le tunnel reste en vie.
-N
indique que vous voulez une connexion SSH, mais que vous ne voulez pas exécuter de commandes à distance. Si tout ce que vous créez est un tunnel, l'inclusion de cette option permet d'économiser des ressources.
-T
désactive l'allocation de pseudo-tty, ce qui est approprié car vous n'essayez pas de créer un shell interactif.
Il y aura un défi de mot de passe à moins que vous n'ayez configuré des clés DSA ou RSA pour une connexion sans mot de passe.
Notez qu'il est FORTEMENT recommandé d'utiliser un compte jetable (et non votre propre identifiant) que vous avez configuré pour ce tunnel / client / serveur uniquement.
Maintenant, à partir de votre shell sur votre publication , établissez une connexion à l'hôte avec pare-feu via le tunnel:
ssh -p 22222 username@localhost
Vous aurez un défi clé d'hôte, car vous n'avez probablement jamais touché cet hôte auparavant. Ensuite, vous obtiendrez un défi de mot de passe pour le username
compte (sauf si vous avez configuré les clés pour une connexion sans mot de passe).
Si vous souhaitez accéder régulièrement à cet hôte, vous pouvez également simplifier l'accès en ajoutant quelques lignes à votre ~/.ssh/config
fichier:
host remotehostname
User remoteusername
Hostname localhost
Port 22222
Ajustez remotehostname
et remoteusername
en fonction. Le remoteusername
champ doit correspondre à votre nom d'utilisateur sur le serveur distant, mais remotehostname
peut être n'importe quel nom d'hôte qui vous convient, il ne doit correspondre à rien qui puisse être résolu.
(Pour exposer le point de terminaison inversé sur une adresse IP autre que l' hôte local , consultez ce post )