Comment puis-je SSH à la machine A via B en une seule commande?

Oui, en utilisant ProxyCommand dans votre configuration SSH.

Créez un fichier de configuration SSH dans votre répertoire personnel (sauf si vous souhaitez que cela soit à l’échelle du système), ~/.ssh/config :

Host unibroker          # Machine B definition (the broker)
Hostname 12.34.45.56    # Change this IP address to the address of the broker
User myusername         # Change this default user accordingly 
                        # ('[email protected]' can overwrite it)

Host internalmachine    # Machine A definition (the target host)
ProxyCommand ssh -q unibroker nc -q0 hostname.or.IP.address.internal.machine 22

Vous pouvez maintenant accéder directement à la machine A en utilisant

ssh [email protected]

Notez également que vous disposez désormais d’un seul nom de cible d’hôte SSH, vous pouvez également l’utiliser dans d’autres applications. Par exemple:

• SCP pour copier des fichiers.

  scp somefile [email protected]:~/
  

• Dans vos applications GUI:

  utilisez sftp://[email protected]/ comme emplacement pour naviguer sur la machine.

  basé sur KDE (Dolphin): utilisez fish://[email protected]/

Notes

Remplacez hostname.or.IP.address.internal.machine et le port ( 22 ) par la machine que vous souhaitez atteindre comme si vous utilisiez la machine unibroker .

Selon les versions de netcat sur l'hôte unibroker, l'option -q0 doit être omise. Concernant l'authentification vous configurez essentiellement deux connexions SSH à partir de votre poste de travail. Cela signifie que l'hôte unibroker et l'hôte machine interne sont vérifiés / authentifiés l'un après l'autre (à la fois pour la vérification de la paire de clés / mot de passe et de la clé d'hôte).

Explication

Cette approche de l’utilisation de ProxyCommand et de 'netcat' n’est qu’une façon de procéder. J'aime cela, car mon client SSH parle directement à la machine cible pour que je puisse vérifier la clé hôte depuis mon client et que je peux utiliser mon authentification par clé publique sans utiliser une autre clé sur le courtier.

Chaque Host définit le début d'une nouvelle section hôte. Hostname est le nom d'hôte ou l'adresse IP cible de cet hôte. User est ce que vous fourniriez en tant que partie utilisateur dans ssh [email protected] .

ProxyCommand sera utilisé comme canal vers la machine cible. En utilisant SSH sur la première machine et en définissant directement un simple 'netcat' ( nc ) sur la cible à partir de là, il ne s'agit en fait que d'un simple transfert de texte vers la machine interne. Les options -q permettent de faire taire toute sortie (uniquement une préférence personnelle).

Assurez-vous que netcat est installé sur le courtier (généralement disponible par défaut sur Ubuntu) - netcat-openbsd < img src="https://hostmar.co/software-small"> ou netcat-traditionnel < img src="https://hostmar.co/software-small"> .

Notez que vous utilisez toujours SSH avec le cryptage deux fois ici. Bien que le canal netcat soit en clair, votre client SSH sur votre PC configurera un autre canal crypté avec l’ordinateur cible final.

Hop in one go

Une alternative évidente à l’approche ProxyCommand fournie dans mon autre réponse serait de "sauter" directement sur la machine cible. :

ssh -t [email protected] ssh [email protected]

Notez le -t sur la première commande ssh . Sans elle, cela échouera:

Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Permission denied, please try again.
[...]

Cela va forcer un vrai TTY à être alloué

En contrepartie, la configuration, la vérification et l’authentification se font maintenant à la machine B, ce que je n’aime vraiment pas dans ma situation pour des raisons de sécurité. J'aime ma paire de clés sur mon propre PC et authentifie et vérifie la machine cible finale à partir de mon propre PC. De plus, vous ne pouvez utiliser que le shell interactif pour SSH, ce qui ne permet pas d'utiliser d'autres outils tels que SCP ou votre gestionnaire de fichiers GUI.

Pour toutes les raisons mentionnées ci-dessus, je recommande fortement l’approche ProxyCommand , mais pour une connexion rapide, cela fonctionne très bien.

Essayez d'utiliser

Host <visible hostname alias>
        Controlmaster auto
        User <user>
        hostname <visible hostname>
        port <port>
        IdentityFile ~/.ssh/<id file>

Host <private LAN hostname alias>
     ProxyCommand ssh -q -W <private LAN hostname>:<private LAN port> <visible hostname alias>

dans votre ~ / .ssh / config et faites tout en une seule fois avec des clés résidant uniquement sur votre ordinateur.

Vous pouvez utiliser l’option de ligne de commande -J :

ssh -J [email protected] [email protected]

De man ssh :

-J [[email protected]]host[:port]
     Connect to the target host by first making a ssh connection to
     the jump host and then establishing a TCP forwarding to the
     ultimate destination from there.  Multiple jump hops may be
     specified separated by comma characters.  This is a shortcut to
     specify a ProxyJump configuration directive.

Il a été introduit dans OpenSSH version 7.3 (publié en août 2016). Il est disponible dans Ubuntu 16.10 et versions ultérieures.

ProxyCommand est une solution propre pour un cas où vous autorisez l’accès au shell dans les deux systèmes. Nous voulions donner aux utilisateurs distants un accès à une machine interne (A) via un courtier (B), mais sans permettre à l'utilisateur d'accéder à B pour améliorer la sécurité. Cela a fonctionné:

Remplacez le shell de connexion

Remplacez le shell de connexion (utilisez chsh ) pour extuser sur le courtier par le script suivant (stocké dans un fichier):

#!/bin/sh   # this is essential to avoid Exec format error
ssh [email protected]

Si aucun mot de passe de connexion n’a été défini dans extuser @ B pour l’utilisateur distant et dans interneuser @ A pour extuser @ B, alors l’exécution de la commande suivante amènera directement l’utilisateur distant à A

ssh [email protected]

Astuce : créez la configuration de password_conservée nécessaire sans mot de passe dans extuser @ B avant de passer au shell de connexion personnalisé. Après le changement, puisque ce compte est inaccessible à quiconque via un shell, seul un sudoer @ B peut apporter des modifications au fichier authorized_keys en le modifiant directement.

sudo vi ~extuser/.ssh/authorized_keys
sudo touch ~extuser/.hushlogin

La dernière ligne consiste à supprimer l'affichage de la bannière de connexion de B, afin que l'utilisateur distant ait un accès transparent à A.

C'est une suggestion très utile. Après avoir déconné pendant des heures, j'ai trouvé cette note, & amp; a confirmé que cela fonctionne exactement comme documenté. Pour se connecter via MachineA à MachineB, à partir de machineC distant:

eg: [xuser @ machineC ~] ssh -t MachineA ssh MachineB

Le "-t" est critique, ssh échoue s’il n’est pas présent. Vous serez invité deux fois, d'abord pour le mot de passe sur MachineA, puis la deuxième fois pour MachineB. Notez également que cela suppose que l'utilisateur "xuser" soit défini sur tous trois machines. Sinon, utilisez simplement la syntaxe ssh: "yuser @ MachineA ...". Notez également que si vous le souhaitez, vous pouvez utiliser les adresses IP brutes en quad. Ceci est utile si vous reliez via un réseau local privé qui utilise des adresses IP non exposées au monde - c.-à-d. pas dedans votre fichier hôte local ou tout DNS. Pour obtenir un fichier de MachineB, sur un ordinateur distant, Vous pouvez passer de MachineB à MachineA, puis de MachineA à un ordinateur distant. (Par exemple, le machineC distante peut envoyer une requête ping à MachineA, mais pas à MachineB.) Mise en garde: J'ai testé avec Fedora et WindowsXP, MachineA est une boîte exécutant ICS (Internet Connection Sharing), tandis que MachineB et machineC distant sont des boîtiers Fedora-Linux. Cette suggestion a résolu un problème clé pour moi - c.-à-d. accès à distance limité et surveillé au réseau local de mon site distant. Notez également que lorsque vous vous déconnectez de MachineB, vous devriez voir deux "Connection à xxx.xxx.xxx.xxx fermé". messages.