Ssh – Comment fonctionne le tunneling Ssh inversé ?

Si j'ai bien compris, les pare-feu (en supposant les paramètres par défaut) refusent tout trafic entrant qui n'a pas de trafic sortant correspondant antérieur.

Basé sur l'inversion d'une connexion ssh et le tunneling SSH simplifié, le tunneling SSH inversé peut être utilisé pour contourner les restrictions de pare-feu embêtantes.

Je souhaite exécuter des commandes shell sur une machine distante. La machine distante possède son propre pare-feu et se trouve derrière un pare-feu supplémentaire (routeur). Il a une adresse IP comme 192.168.1.126 (ou quelque chose de similaire). Je ne suis pas derrière un pare-feu et je connais l'adresse IP de la machine distante telle qu'elle est vue sur Internet (pas l'adresse 192.168.1.126). De plus, je peux demander à quelqu'un d'exécuter ssh (something) en tant que root sur la machine distante en premier.

Quelqu'un pourrait-il m'expliquer, étape par étape, comment fonctionne le tunnel SSH inversé pour contourner les pare-feu (pare-feu des machines locales et distantes et le pare-feu supplémentaire entre eux) ?

Quel est le rôle des interrupteurs (-R , -f , -L , -N ) ?

Réponse acceptée :

J'adore expliquer ce genre de chose par la visualisation. 🙂

Considérez vos connexions SSH comme des tubes. Gros tubes. Normalement, vous accéderez à ces tubes pour exécuter un shell sur un ordinateur distant. Le shell s'exécute dans un terminal virtuel (tty). Mais vous connaissez déjà cette partie.

Considérez 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 gros tube, votre connexion SSH, a commencé avec votre client SSH et se termine sur le serveur SSH auquel vous vous êtes connecté. Tous les tubes plus petits ont les mêmes extrémités, sauf que le rôle de "début" ou "fin" est déterminé si vous avez utilisé -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 en utilisant la traduction d'adresses réseau (NAT). C'est assez important, donc 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 répondra, ainsi qu'une adresse et un port sur lesquels il sera livré. Le -L L'option indique au tunnel de répondre du côté local du tunnel (l'hôte exécutant votre client). Le -R indique au tunnel de répondre du côté distant (le serveur SSH).

Alors… Pour pouvoir utiliser SSH depuis Internet vers une machine derrière un pare-feu, vous avez besoin que la machine en question ouvre une connexion SSH vers le monde extérieur et inclue un -R tunnel dont le point "d'entrée" est le côté "distant" de sa connexion.

Des deux modèles ci-dessus, vous voulez celui de droite.

En relation:Existe-t-il un moyen de travailler avec des CollectionViews imbriqués dans les formulaires Xamarin avec MvvmCross ??

À partir de l'hôte protégé par un 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 à l'extrémité du tunnel atteindra en fait le "port localhost 22", où "localhost" est du point de vue du point de sortie du tunnel (c'est-à-dire votre client ssh).

Les autres options sont :

-f indique à ssh de se mettre en arrière-plan après s'être authentifié, vous n'avez donc pas à rester assis à exécuter quelque chose sur le serveur distant pour que le tunnel reste actif.
-N dit que vous voulez une connexion SSH, mais 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, sauf si vous avez 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é uniquement pour ce tunnel/client/serveur.

Maintenant, depuis votre shell sur votrehôtepublic , établissez une connexion à l'hôte protégé par un pare-feu via le tunnel :

ssh -p 22222 [email protected]

Vous obtiendrez un défi de clé d'hôte, car vous n'avez probablement jamais rencontré cet hôte auparavant. Ensuite, vous obtiendrez un défi de mot de passe pour le username compte (sauf si vous avez configuré des clés pour une connexion sans mot de passe).

Si vous allez 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 pour convenir. Le remoteusername le 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 n'a pas besoin de correspondre à quelque chose de résoluble.

Exposer le point de terminaison inverse sur un hôte non local IP
Conseils d'utilisation de ControlMaster pour entretenir votre tunnel