Comment puis-je SSH à la machine A via B en une seule commande?
Je souhaite accéder à un ordinateur, par exemple machine A, qui est basé sur le réseau de mon université. Cependant, cet ordinateur n’est accessible que via le réseau interne de l’université, je ne peux donc pas utiliser SSH directement sur cet ordinateur depuis chez moi.
Voici ce que je fais maintenant:
Connectez-vous à une autre machine universitaire, par exemple machine B
(Cette machine B est accessible via SSH à partir de mon ordinateur personnel.)
Utilisez SSH sur B pour vous connecter à A.
Y a-t-il un moyen de le faire plus rapidement? Utiliser une seule commande ssh.
Oui, en utilisant ProxyCommand dans votre configuration SSH.
Créez un fichier de configuration SSH dans votre répertoire de base (à moins que vous ne souhaitiez modifier l’ensemble 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
# (`user@unibroker` 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 user@internalmachine
Notez également que vous disposez désormais d'un nom de cible d'hôte SSH unique, que vous pouvez également utiliser dans d'autres applications. Par exemple.:
SCP pour copier des fichiers.
scp somefile user@internalmachine:~/Dans vos applications graphiques:
utilisez
sftp://user@internalmachine/comme emplacement pour naviguer sur la machine.Basé sur KDE (Dolphin): utilisez
fish://user@internalmachine/
Remarques
Remplacez hostname.or.IP.address.internal.machine et le port (22) par l’ordinateur auquel vous souhaitez accéder, comme si vous le vouliez depuis l’ordinateur unibroker.
Selon les versions de netcat sur l'hôte unibroker, l'option -q0 doit être omise. En ce qui concerne 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 internalmachine sont vérifiés/authentifiés l'un après l'autre (pour la vérification de la paire de clés/mot de passe et la clé de l'hôte).
Explication
Cette approche de l'utilisation de ProxyCommand et de 'netcat' n'est qu'un moyen de le faire. J'aime cela, car mon client SSH parle directement à la machine cible pour que je puisse vérifier la clé de l'hôte auprès de mon client et que je puisse utiliser l'authentification de ma clé publique sans utiliser une autre clé sur le courtier.
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 comme partie utilisateur dans ssh user@hostname.
ProxyCommand sera utilisé comme canal de transmission vers la machine cible. En utilisant SSH sur la première machine et en configurant directement un simple 'netcat' (nc) sur la cible à partir de là, il s’agit essentiellement d’un texte en clair transmis à la machine interne par le courtier entre ceux-ci. Les options -q permettent de désactiver toute sortie (juste une préférence personnelle).
Assurez-vous que Netcat est installé sur le courtier (généralement disponible par défaut sur Ubuntu) - soit netcat-openbsd ou netcat-traditional
.
Notez que vous utilisez toujours SSH avec le cryptage deux fois ici. Alors que le canal netcat est en texte clair, votre client SSH sur votre PC configurera un autre canal crypté avec la machine cible finale.
Hop d'un coup
Une alternative évidente à l'approche ProxyCommand que j'ai fournie dans mon autre réponse serait de "sauter" directement sur la machine cible:
ssh -t user@machineB ssh user@machineA
Notez le -t sur la première commande ssh. Sans cela, il é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.
[...]
Il va obliger à attribuer un vrai TTY
L'inconvénient est que toute la configuration, la vérification et l'authentification ont maintenant lieu sur la machine B, ce que je n'aime pas du tout dans ma situation pour des raisons de sécurité. J'aime mon clavier 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, de sorte que cela ne traitera pas d'autres outils tels que SCP ou l'utilisation de votre gestionnaire de fichiers GUI.
Pour toutes les raisons susmentionnées, je recommande fortement approche ProxyCommand , mais pour une connexion rapide, cela fonctionne bien.
Vous pouvez utiliser l'option de ligne de commande -J:
ssh -J user@machineB user@machineA
De man ssh :
-J [user@]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.
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 un avec les touches uniquement sur votre ordinateur.
Vous voulez dire que vous avez besoin de plusieurs cavaliers :)
Récemment, j'ai rencontré ce problème avec jumper1 jumper2 et ma dernière machine, comme pour mon sol
script local:
#!/bin/bash
sshpass -p jumper1Passwd ssh -t jumper1@jumper1IP ./Y00.sh
puis sur le 1er cavalier (qui est mon routeur), j'ai placé un script nommé Y00.sh:
ssh -tt jumper2@jumper2 -i ~/.ssh/id_rsa sshpass -p finalPassWord ssh -tt final@final
Vous pouvez les remplacer par votre adresse IP et vos mots de passe, bonne chance!
ProxyCommand est une solution propre pour un cas où vous autorisez l'accès Shell à deux systèmes. Nous voulions donner aux utilisateurs distants l'accès à une machine interne (A) via un courtier (B), mais sans permettre à l'utilisateur de Shell d'accéder à B pour améliorer la sécurité. Cela a fonctionné:
Remplacer 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 internaluser@A
Si aucun mot de passe de connexion n'a été défini dans extuser @ B pour l'utilisateur distant et dans internaluser @ A pour extuser @ B, l'exécution de la commande suivante mènera directement l'utilisateur distant à A
ssh extuser@B
Astuce: Créez le nom de domaine sans mot de passe nécessaire, configurez l'installation dans extuser @ B avant d'utiliser le shell de connexion personnalisé. Après la modification, ce compte étant inaccessible à quiconque via un shell, seul un sudoer @ b peut modifier le fichier allowed_keys en le modifiant directement.
Sudo vi ~extuser/.ssh/authorized_keys
Sudo touch ~extuser/.hushlogin
La dernière ligne est de 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 des heures de travail, j'ai trouvé cette note et confirmé que cela fonctionnait exactement comme indiqué. Pour vous connecter via MachineA à MachineB, à partir de la machine distante:
par exemple: [xuser @ machineC ~] ssh -t MachineA ssh MachineB
Le "-t" est critique, ssh échoue s'il n'est pas présent. Vous serez invité à deux reprises, un mot de passe sur MachineA, puis une seconde fois sur MachineB. Notez également que cela suppose que l'utilisateur "xuser" soit défini sur les trois ordinateurs. Sinon, utilisez simplement la syntaxe ssh: "yuser @ MachineA ...". Notez également que vous pouvez utiliser des adresses IP brutes quadruples en pointillés, si vous le souhaitez. Ceci est utile si vous vous connectez à un réseau local privé qui utilise des adresses IP non exposées au monde - c'est-à-dire. pas dans votre fichier hôte local, ni dans aucun DNS. Pour obtenir un fichier de MachineB, vers une machine distante, vous pouvez passer de MachineB à MachineA, puis de MachineA vers une machineC distante. (Par exemple, la machineC distante peut envoyer un ping à MachineA, mais pas à MachineB.) Avertissement: j'ai testé avec Fedora et Windows XP, MachineA est un XP-Box exécutant ICS (partage de connexion Internet), alors que MachineB et la machine distante sont Les boîtes Fedora-Linux. Cette suggestion a résolu un problème clé pour moi - c'est-à-dire. accès à distance restreint et surveillé à mon réseau distant. Notez également que lorsque vous vous "déconnectez" de MachineB, vous devez voir deux "Connexion à xxx.xxx.xxx.xxx fermée". messages.