Je souhaite copier un fichier de ma machine A sur le serveur C, mais je n'ai accès au serveur C que par le biais du serveur B.
Au lieu de transférer d'abord sur le serveur B, connectez-vous puis transférez-le sur le serveur C, est-il possible de transférer le fichier directement avec SCP ou des programmes similaires?
(Emacs tramp-mode a cette fonctionnalité pour éditer des fichiers à distance).
Réponses:
Vous pouvez ajouter des -ooptions à la scpplace de .ssh/config.
scp -o ProxyCommand="ssh $jump_host nc $host 22" $local_path $host:$destination_path
$jump_host est votre "serveur B" dans ce cas.
En supposant OpenSSH, ajoutez-le à votre configuration SSH dans .ssh / config
Host distant
ProxyCommand ssh near nc distant 22
Cela permettra à SSH de se connecter "directement" à la machine nommée distante en effectuant un proxy via la machine nommée proche. Il peut ensuite utiliser des applications telles que scp et sftp sur la machine distante.
Pour que cela fonctionne, vous devez disposer de 'nc', autrement dit netcat, sur la machine nommée à proximité. Mais beaucoup de systèmes modernes l'auront déjà.
La solution tar de towo est plus efficace pour les problèmes ponctuels, à condition que vous ayez mémorisé la syntaxe et les règles de fonctionnement de tar.
nearest différent de celui indiqué distant, l'utilisateur proche s'en va ProxyCommand ssh nearuser@near...et l'utilisateur distant se connecte sur une User distantuserligne distincte .
Avec les versions plus récentes de ssh sur le serveur près de la machine (B), les opérations suivantes fonctionneront sans netcat:
Host distant
ProxyCommand ssh near -W distant:22
Toutefois, AllowTcpForwarding doit être défini sur yes (valeur par défaut) sur la machine proche (B).
edit: nécessite OpenSSH 5.4+ sur B
Vous pouvez ssh sur le serveur B en utilisant quelque chose comme
ssh -L 5022:<server C IP>:22 <user_serverB>@<server B IP>
Ensuite, vous pouvez ssh au serveur C en utilisant
ssh -p 5022 <user_serverC>@localhost
De même scp fonctionnerait en utilisant
scp -P 5022 foo.txt <user_serverc>@localhost:
N'oubliez pas d'utiliser le cas correct de p avec scp et ssh
C'est possible et relativement facile, même lorsque vous devez utiliser des certificats pour l'authentification (typique dans les environnements AWS).
La commande ci - dessous copie des fichiers d'un remotePathsur server2directement dans votre machine à localPath. En interne, la requête scp est proxy via server1.
scp -i user2-cert.pem -o ProxyCommand="ssh -i user1-cert.pem -W %h:%p user1@server1" user2@server2:/<remotePath> <localpath>
L’inverse fonctionne également (fichier à télécharger):
scp -i user2-cert.pem -o ProxyCommand="ssh -i user1-cert.pem -W %h:%p user1@server1" <localpath> user2@server2:/<remotePath>
Si vous utilisez plutôt l’authentification par mot de passe, essayez avec
scp -o ProxyCommand="ssh -W %h:%p user1@server1" user2@server2:/<remotePath> <localpath>
Si vous utilisez les mêmes informations d'identification d'utilisateur sur les deux serveurs:
scp -o ProxyCommand="ssh -W %h:%p commonuser@server1" commonuser@server2:/<remotePath> <localpath>
Si vous voulez être vraiment méchant, vous pouvez enchaîner ssh et tar, par exemple tar c mydir | ssh server "ssh otherserver | tar x", mais cela peut se heurter à toutes sortes de problèmes.
Le moyen le plus simple serait simplement de configurer un tunnel SSH avec les méthodes intégrées de SSH; Regardez le -Dcommutateur dans la page de manuel et transférez simplement un port sur le port ssh de l'autre serveur.
Vous pouvez également le faire à l’inverse et peut-être plus facilement.
Supposons qu'une session ssh soit ouverte avec la machine à laquelle vous voulez envoyer le fichier. Ce PC le plus éloigné, nous l'appellerons hop2. Votre hôte "proxy" sera hop1. Le PC qui est l’origine du fichier, nous appellerons cette origine.
origin:~/asdf.txt --> hop1 --> hop2:~/asdf.txt
Vous pouvez créer des tunnels rendant un port local disponible sur un PC distant. Nous définissons ainsi un port à ouvrir sur le PC distant, qui sera une redirection vers le port que vous avez intercepté lors de la construction du tunnel.
Sur hop2:
ssh -R 5555:127.0.0.1:22 <hop1_user>@<hop1_IP>
#this has the effect of building a tunnel from hop2 to hop1, making hop2's port 22 available on hop1 as port 5555
Maintenant, dans cette session de tunnel ouverte, vous pouvez faire la même chose de hop1 à file_origin.
Sur hop1:
ssh -R 6666:127.0.0.1:5555 <origin_user>@<origin_IP>
#this has the effect of building a tunnel from hop1 to origin while also pulling the active tunnel with it, making hop1's port 5555 (hop2's port 22) available on origin as port 6666.
Vous êtes maintenant tunnelé de hop2 à hop1 et à l’origine. Par coïncidence, les ports 5555 et 6666 sont maintenant ouverts sur leur origine, ce qui redirige vers le port 22 de hop2. Dans cette session, les deux suivants sont des itinéraires scp valides vers hop2:
Sur l'origine:
scp -P 6666 ~/asdf.txt <hop2_user>@<127.0.0.1>:~/asdf.txt
De cette façon, vous pouvez avoir un nombre arbitraire de sauts entre les deux et il est plus facile de travailler avec une chaîne de plus de deux sauts.
Essayez d’adapter l’exemple suivant openssh config pour une configuration pouvant être utilisée par plusieurs hôtes:
Host uat-*
ProxyCommand ssh bastion-uat nc %h %p
Cela suppose un ensemble de serveurs commençant par "uat-" qui ne sont accessibles que via le serveur de passerelle / passerelle "bastion-uat". Vous voudrez probablement aussi ajouter ForwardAgent yessi vous utilisez une clé pour vous connecter.
ForwardAgent yespour cela. Le transfert d'agent n'est pas nécessaire dans ce cas car aucun client ssh ne s'exécutera sur le bastion et le transfert d'un agent lorsqu'il n'en a pas besoin va simplement réduire la sécurité. Et je pense qu'il sshmanque à votre commande. Si sshvous n'avez pas besoin d' une version récente nc, vous pouvez taper à la ssh -W %h:%p bastion-uatplace.
Ce n'est pas scp (ce que l'OP a demandé), mais je l'ai trouvé super simple à utiliser rsyncpour copier d'un local à un autre sur un seul saut avec:
rsync -v -e 'ssh -A -t user@jumpserver ssh -A -t user@destinationserver' /path/to/sourcefile :/path/to/destination
Source: http://mjbright.blogspot.com/2012/09/using-rsync-over-multi-hop-ssh.html
J'avais essayé la suggestion -o ProxyPass ci-dessus et je ne voulais pas changer de configuration pour mes besoins changeants. Comme l'indique l'auteur du lien ci-dessus, le fichier de destination précédant le signe deux-points (:) est important pour indiquer que le chemin spécifié est sur le serveur de destination. De plus, en utilisant rsync, vous avez les options de comparaison de date, de synchronisation de dossier, etc. J'espère que cela aidera quelqu'un!