J'ai toujours eu l'habitude d'utiliser la commande suivante pour copier à partir d'un serveur :
rsync --progress -avze ssh user@host:/path/to/files ./hereCependant, un de mes amis m'a montré que je peux tout simplement le faire :
rsync --progress -avz user@host:/path/to/files ./hereDonc la question est, si vous n'avez pas besoin -e ssh pourquoi est-elle là de toute façon ?
Chaque fois que vous avez besoin d'options supplémentaires pour la commande ssh en dehors de l'utilisateur et de l'hôte, vous avez besoin de l'option -e. Peut-être que le serveur auquel vous vous connectez a mis ssh à l'écoute sur le port 2222.
rsync -e 'ssh -p 2222' /source usr@host:/destPour contourner ce problème, il existe deux fichiers que vous pouvez utiliser. /etc/ssh/ssh_config o ~/.ssh/config
Le fichier de configuration utilise le même format que ssh_config . Il est simplement possible de le configurer pour chaque utilisateur !
Légèrement hors sujet, mais y a-t-il une raison d'utiliser /etc/ssh/ssh_config au lieu de ~/.ssh/config ? Pour autant que je sache, les fichiers etc sont des paramètres par défaut/système, qui sont copiés dans les paramètres utilisateur s'ils n'existent pas. Je crains que la modification du fichier etc original ne cause des problèmes lors des mises à jour, par exemple. Prendre une sauvegarde des paramètres de l'utilisateur lors de la migration d'une machine à l'autre sera également plus facile.
Bien sûr, il est parfois très pratique d'avoir des paramètres de configuration pour tous les utilisateurs de votre organisation. Peut-être voulez-vous que tous vos hôtes de saut soient facilement accessibles à tous vos utilisateurs. /etc/ssh/ssh_config est un moyen simple de le gérer. Il y a une nouvelle fonctionnalité dans ssh qui vous permet maintenant de include un autre fichier dans votre config donc ssh_config est moins nécessaire aujourd'hui, mais il a toujours son utilité.
Vous n'avez pas besoin de -e ssh pour utiliser ssh. En fait, si vous spécifiez la cible comme user@host:/path/to/files, vous utilisez ssh par défaut. Cette option est laissée a) pour des raisons de compatibilité et b) dans les cas marginaux où vous pourriez avoir une combinaison d'hôtes rsyncd et ssh.
Vous aurez également besoin de -e si vous utilisez un emplacement de clé privée autre que celui par défaut, c'est-à-dire si vous spécifiez la clé privée par l'intermédiaire de l'option -e 'ssh -i /path/to/private/key/file.pem' . Il en va de même pour les ports d'écoute par défaut de sshd. En fait, il faut utiliser -e si l'on utilise seulement ssh user@host ne fonctionne pas.
Est -i une option pour ssh ou rsync dans votre exemple ? Et si c'est pour ssh, cela fonctionne-t-il sans les guillemets simples autour de la commande ?
@Izkata -i définit le fichier d'identité pour une session ssh. Cela n'a rien à voir avec rsync, en soi. Vous pouvez également changer la commande utilisée dans git, par exemple, en utilisant $GIT_SSH_COMMAND mais il est généralement préférable de configurer ssh comme expliqué dans la réponse ci-dessus.
Cela dépend de ce qui a été spécifié pour le --with-rsh au moment de la compilation. La valeur par défaut est désormais ssh si cette option n'a pas été spécifiée. C'était rsh à un moment donné dans le passé, mais même si c'est rsh, ce n'est peut-être pas nécessaire car ssh peut être l'implémentation par défaut de rsh sur de nombreuses machines. Sur toutes mes machines, par exemple readlink -f $(which rsh) montre que rsh n'est en fait qu'un lien symbolique pointant vers /usr/sbin/ssh
READ IT -> i looked this konweledge and after many expirence i get awareWHOAH :
un point important : rsync prépare les listes de fichiers "LOCAL" sur le destin et la source en utilisant une connexion ssh comme s'il était présent sur la machine,
NFS demande tous les fichiers entre le destin "NETWORK" et la source, ce qui rend le processus très lent si le serveur est éloigné.
même quelques ms font sens en utilisant rsync entre deux serveurs avec une clé rsa gen que des fichiers nfs,
NFS est également coupé par le centre de données pour ces ports, que 22 ports ssh sont plus rapides.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
