Trafic SSH direct via une machine du milieu

110

La tunnelisation SSH m’embrouille énormément. Je me demande si je peux le faire sous Linux.

J'ai 3 machines ..

A. My local machine at home.
B. Machine at work that I can SSH into (middle man).
C. My desktop at work that I can only SSH into from machine B.

Donc, je peux SSH de A -> B et de B -> C, mais pas de A -> C.

Existe-t-il un moyen de configurer un tunnel SSH de A à B afin que, lorsque j'exécute d'autres commandes SSH, elles fonctionnent uniquement à partir de la machine locale A? J'essaie essentiellement de cloner un dépôt Git du travail à la maison (et je ne peux pas installer Git sur la machine B).

En outre, une fois l'installation .. Comment puis-je le désactiver aussi?

command-line bash ssh git tunnel
la source
Je crois qu’il ya une question en double quelque part mais mon search-fu est faible aujourd’hui.
Quack Quichotte
2
ce serait le mien: superuser.com/questions/96489/ssh-tunnel-via-multiple-hops
Mala
2
Double possible d' un tunnel SSH via plusieurs bonds
Geza Kerecsenyi
Si vous utilisez Linux sur la machine A, utilisez un outil appelé sshuttle, qui vous permet de transférer de manière sélective tout le trafic de C via le tunnel A-> B (en supposant que C est visible depuis B).
Joat

Réponses:

128

Placez ceci dans votre .ssh/configfichier sur hostA (voir man 5 ssh_config pour plus de détails):

# .ssh/config on hostA:
Host hostC
    ProxyCommand ssh hostB -W %h:%p

Maintenant, la commande suivante va automatiquement tunneler à travers hostB

hostA:~$ ssh hostC

Vous voudrez peut-être ajouter des options telles que -oCiphers=arcfouret -oClearAllForwardings=yespour accélérer les choses, car le wrapping à l' sshintérieur sshcoûte plus cher en calcul et que l'effort supplémentaire nécessaire pour le wrapper n'a pas besoin d'être aussi sécurisé lorsqu'il tunnelise du trafic déjà chiffré.

Si vous utilisez OpenSSH avant la version 5.3, l' -Woption n'est pas disponible. Dans ce cas, vous pouvez implémenter ce qui précède en utilisant netcat ( nc):

ProxyCommand ssh hostB nc %h %p  # or netcat or whatever you have on hostB
éphémère
la source
1
C'est génial! Je vous remercie. Cela résout un problème qui me mange depuis 2 jours: hostC est assis derrière un pare-feu et contient les données auxquelles je souhaite accéder depuis hostA, un ordinateur portable qui peut être n'importe où dans le monde. hostB est également derrière le même pare-feu avec hostC, mais il possède un port SSH ouvert sur le monde. Ainsi, je peux ssh depuis hostC -> hostB. J'ai configuré un tunnel SSH inversé entre hostC et hostB, ce qui me permet également de faire ssh depuis hostB -> hostC (transféré via localhost). Avec votre astuce, je peux passer de hostA -> hostC! Cela fonctionne de manière transparente avec SCP & Fugu sur OSX! Je vous remercie!
AndyL
L' -Woption doit être utilisée à la place de l' ncoption.
vy32
Quel SSH doit prendre en charge -W, uniquement celui sur hostA (l'origine) ou également celui sur hostB (la machine intermédiaire)?
Gioele
Pour information, si vous avez plusieurs hôtes que vous devez atteindre via le même système hostB, il est possible de déclarer plusieurs Host hostClignes au-dessus, ProxyCommandce qui facilite grandement l'accès à plusieurs hôtes via le serveur intermédiaire.
Fduff
7

Edit: Ceci est la mauvaise approche. Voir la réponse de l'éphémient à la place. Cette réponse fonctionnera, mais est potentiellement moins sécurisée et certainement moins impressionnante.

Il semble que vous souhaitiez une solution semblable à celle-ci:

ssh -L localhost:22:machinec:22 machineb

Cela vous donnera un shell machineb. Laisse ça tranquille; minimiser la fenêtre du terminal.

Maintenant, chaque fois que vous établissez une connexion ssh avec localhost, vous serez réellement connecté à machinectravers machineb. Lorsque vous avez terminé avec le tunnel, fermez simplement le terminal dans lequel vous avez exécuté la commande ci-dessus.

Notez que vous aurez besoin des privilèges de superutilisateur pour exécuter la commande.

Wesley
la source
+1 Merci Wesley. C’est la vraie réponse par tunnel ssh. Voici un article à ce sujet: securityfocus.com/infocus/1816
Larry K
3
Dans l’ensemble, c’est tout à fait mal… mais j’ai dû le faire avec des versions anciennes d’OpenSSH ou d’autres clients ssh. Vous pouvez choisir un port élevé comme 8022: de cette façon, il n’interférera avec aucun service ssh sur localhost, et ne nécessite pas d’exécution en tant que root. Ajoutez juste -p 8022à vos commandes ssh. Et c'est facile avec git: utilisez l'URI ssh://localhost:8022/path/to/repo.git.
éphémère
3

On dirait que vous voulez un alias de shell sur A qui provoque l'apparition de ssh sur C

  1. Je suppose que sur A, vous pouvez taper ssh moi @ b "ssh moi @ c nomhôte" et récupérer "C"
  2. Créez un alias sshc qui étend sshc foo en ssh me @ b "ssh me @ c foo"
  3. Pour connaître la syntaxe exacte de création de l’alias, consultez superuser.com.
Larry K
la source
1
Vous devrez peut-être ajouter -tdes options à l'extérieur de ssh si vous voulez un shell interactif, car sshsuppose -Tqu'il est donné une commande.
éphémère
1

Pour un shell interactif, vous pouvez utiliser cette commande simple:

ssh -J <user>@<hostB> <user>@<hostC>

Les options -J sont pour sauter .

ssasa
la source
0

Si votre employeur fournit un VPN, je vous conseillerais plutôt de l’utiliser.

De cette façon, vous n’aurez à configurer aucune application spécialement (même ssh), et vous pourrez voir n’importe quelle machine derrière le pare-feu. De plus, tout votre trafic sera crypté par le logiciel VPN, ce qui renforcera la sécurité de tout trafic accidentellement ou délibérément non crypté.

Andrew Wagner
la source
6
Parfois, c’est le VPN qui fait que nous avons besoin de ces astuces ...
Louis
0

YASS encore une autre solution simple

ssh -f -L 2222:HostC_IP_or_Name:22 userOnB@hostB sleep 10 &&
    ssh -o HostKeyAlias=HostC -p 2222 userOnC@localhost
  • La première commande ouvre une connexion ssh à HostB et dit à HostB de transférer les connexions de localhost: 2222 à HostC: 22 .
  • le -fparamètre dit à SSH d'aller en arrière-plan une fois la connexion établie
  • La deuxième commande ouvre simplement une connexion client à localhost: 2222
  • Les options HostKeyAlias ne sont pas obligatoires, mais pourraient aider à empêcher la connexion à un hôte incorrect.
  • Nota: les commandes sleep 10sont nécessaires pour maintenir la connexion jusqu'à ce que la seconde commande ssh utilise le port transféré. Ensuite, le premier ssh se ferme lorsque le second ssh quitte le port transféré.

vous pouvez maintenant exécuter les sessions ssh suivantes:

ssh -o HostKeyAlias=HostC -p 2222 userOnC@localhost

Une variante:

ssh -f -L 2222:HostC_IP_or_Name:22 userOnB@hostB sleep 10 &&
    ssh -M -S ~/.ssh/ssh_HostC22userOnC.sock -o HostKeyAlias=HostC -p 2222 userOnC@localhost

les sessions ssh suivantes peuvent être ouvertes en exécutant:

ssh -S ~/.ssh/ssh_HostC22userOnC.sock userOnC@localhost

Le principal avantage de l'utilisation des paramètres -M et -S est qu'une seule connexion est ouverte d'HostA à HostC. La session suivante ne s'authentifiera pas et ne sera pas exécutée beaucoup plus rapidement.

F. Hauri
la source
0

Cas particulier, plates-formes nix mixtes:

  hostA (linux) -> HostB (solaris) -> HostC (linux)

Si besoin d'une application X sur hostC, et que le saut intermédiaire est sur la boîte Solaris ... dans ce cas, j'ai trouvé le netcat (nc) nécessaire sur la commande de proxy, comme suit:

hostA: ~ $ vi .ssh / config:

Hôte hostC
    ProxyCommand ssh hostB nc% h% p # où nc est netcat

Puis le tunneling automatique fonctionne:

hostA: ~ $ ssh hostC

nsysdcw
la source