ssh et rsync pour sauvegarde sur NAS

Bonjour à tous,

Je souhaite faire des sauvegardes depuis un poste Linux Debian Squeeze vers un NAS Synology.

Sur ce NAS j'ai un compte admin et un compte utilisateur chris. Pour ce compte chris, j'ai un dossier partagé CHRIS, sur lequel je souhaite faire les backups avec rsync. Le chemin vers ce dossier est /volume1/CHRIS.

Le serveur ssh est activé sur le NAS.

Pour me connecter au NAS avec une console, je fais : ssh root@192.168.1.28 (adresse du NAS), on me demande le mot de passe et je suis connecté, donc pas de problème.

Comme il est conseillé de ne pas utiliser le compte root avec rsync, j'ai souhaité vérifier la connexion avec mon compte chris (non admin).

La commande : ssh chris@192.168.1.28 me dit que l'accès est refusé.

A cause de ce refus de connexion, il m'était impossible d'utiliser rsync, d'autant plus que je souhaiterais automatiser cette tâche de sauvegarde.

J'ai donc suivi un tutoriel très détaillé me permettant d'avoir, d'une part l'accès ssh au serveur NAS pour le compte chris et d'autre part la mise en place d'un couple clé privée/clé publique pour le chriffrement ssh.

Le tuto se trouve ici : https://techarea.fr/tuto-ssh-cle-nas...?cn-reloaded=1

A présent (i.e. après application de ce tutoriel), la commande ssh chris@192.168.1.28 me connecte au NAS en ssh, directement dans le dossier /volume1/homes/chris, sans avoir à saisir mon mot de passe.
Donc très bien de ce côté.

En revanche, je repère quelque chose qui me semble annormal du côté de rsync, je m'explique :

Pour effectuer mon test, j'ai créé les dossiers suivants :

- sur mon poste local Linux Debian : /home/chris/TEST_RSYNC

- sur le serveur NAS : /volume1/CHRIS/TEST_RSYNC

Je lance alors la commande : rsync -av -e ssh /home/chris/TEST_RSYNC/ chris@192.168.1.28:/volume1/CHRIS/TEST_RSYNC

Résultat : Les fichiers présents dans le dossier local /home/chris/TEST_RSYNC/ sont bien copiés dans le dossier distant /volume1/CHRIS/TEST_RSYNC sur le NAS.

Là encore tout semble normal.

LE PROBLEME :

La commande : rsync -av /home/chris/TEST_RSYNC/ chris@192.168.1.28:/volume1/CHRIS/TEST_RSYNC

me donne le même résultat, sans avoir à saisir le mot de passe, alors que je n'ai pas invoqué 'ssh' dans la commande.

Je précise que le service TELNET est bien désactivé sur le NAS.

Est-ce que le protocole ssh pourrait étre implicite dans une commande rsync ? Car je ne comprends plus trop.

En fait je me demande si la copie ne s'effectuerait pas sans chiffrement et sans mot de passe ? Autrement dit en clair.


Merci d'avance à tous ceux qui pourront m'éclairer sur ce point.

Krys006

Bonsoir,

Je n'ai jamais joué avec rsync de cette manière,

Citation:

---

Envoyé par Krys006

Est-ce que le protocole ssh pourrait étre implicite dans une commande rsync ? Car je ne comprends plus trop.

---

cependant la lecture du man est intéressante. Extraits :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

GENERAL There are two different ways for rsync to contact a remote system: using a remote-shell program as the transport (such as ssh or rsh) or contacting an rsync daemon directly via TCP. The remote-shell transport is used whenever the source or destination path contains a single colon (:) separator after a host specification.   SETUP Once installed, you can use rsync to any machine that you can access via a remote shell (as well as some that you can access using the rsync daemon-mode protocol). For remote transfers, a modern rsync uses ssh for its communications, but it may have been configured to use a different remote shell by default, such as rsh or remsh. [...]   Typically, rsync is configured to use ssh by default [...]

---

Le double-point dont il est question dans la section GENERAL a l'air d'être là, après "28" :
rsync -av /home/chris/TEST_RSYNC/ chris@192.168.1.28:/volume1/CHRIS/TEST_RSYNC.

On pourrait donc répondre "oui" à ta première question ci-dessus.

Citation:

---

Envoyé par Krys006

En fait je me demande si la copie ne s'effectuerait pas sans chiffrement et sans mot de passe ? Autrement dit en clair.

---

Je ne sais pas, et je n'ai pas trouvé l'info.

Merci beaucoup Jipété, ça m'éclaire un peu. Je vais donc creuser la doc de ma version de rsync.

Si ce n'est pas trop indiscret, aurais-tu un exemple illustrant la manière avec laquelle tu joues avec rsync ?

Merci.

Bonjour,

je n'ai jamais explicitement invoqué ssh pour utiliser rsync, et, sans export de clé, ce dernier me demande mon mot de passe.
j'en ai déduis qu'il passe implicitement par ssh !

Yop !

Citation:

---

Envoyé par Krys006

Si ce n'est pas trop indiscret, aurais-tu un exemple illustrant la manière avec laquelle tu joues avec rsync ?

---

pour des sauvegardes rapides en interne d'un disque sur l'autre :
rsync -lEauR --delete --inplace source_avec_slash/ destination_sans_slash et lorsqu'un dd externe sur usb est branché et détecté, rappel de la même commande qui va utiliser comme source la destination précédente.

Notes : la première lettre des options est un "elle"
La source_avec_slash/ est en fait issue d'un fichier ini contenant une liste de dossiers, et la commande est appelée autant de fois que nécessaire.

rsync utilise ssh. l'option -e ssh sert en cas de besoin de spécification du port (utilisation de port ssh non par défaut).

Citation:

---

rsync -lEauR --delete --inplace source_avec_slash/ destination_sans_slash

---

Merci Jipété pour ces précisions, je vais étudier de plus près l'utilisation de tous ces paramètres passés en ligne de commande.

Citation:

---

Envoyé par N_BaH

je n'ai jamais explicitement invoqué ssh pour utiliser rsync, et, sans export de clé, ce dernier me demande mon mot de passe.
j'en ai déduis qu'il passe implicitement par ssh !

---

Merci N_BaH, c'est aussi ce que j'étais tenté de conclure. Mais, dans tous les exemples que je trouvais sur les forums, à chaque fois était rajoutée à la commande rsync la partie "-e ssh", d'où mon doute.

Citation:

---

Envoyé par chrtophe

rsync utilise ssh. l'option -e ssh sert en cas de besoin de spécification du port (utilisation de port ssh non par défaut).

---

Merci chrtophe,

Un extrait de tuto que l'on peut trouver ici : http://www.xenetis.org/linux_debian_...shell_usb.html donne :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Utilisation de rsync en réseau Le point intéressant avec rsync, est de pouvoir sauvegarder sur une machine distante, pour cela il faut spécifier notre serveur cible, pour cet exemple : 123.123.123.123 avec utilisateur root dans le dossier /home/backup : rsync -Haurov /var/www/xenetis.org/ root@123.123.123.132:/home/backup/ Cette sauvegarde passe par ssh, rsync vous demandera donc le mot de passe de l'utilisateur distant pour effectuer sa sauvegarde. Utilisation des clés publique / privée pour la sauvegarde par ssh Si vous vous voulez utiliser une paire de clé publique / privée pour effectuer votre sauvegarde, vous pouvez vous référer au tutoriel présent sur ce site : Sauvegarde par ssh avec la commande scp avec clé publique - clé privée Puis une fois les clés installées utilisez cette commande pour la sauvegarde rsync -Haurov -e "ssh -i /root/.ssh/id_dsa" /var/www/xenetis.org/ root@123.123.123.132:/home/backup/ Cela vous permettra de lancer votre commande en tache planifier crontab par exemple. Utilisation d'un port ssh différent de celui d'origine Si le serveur recevant les sauvegardes dispose d'un port ssh n'était pas celui d'origine (22) mais par exemple 2222, utilisez la commande suivante : rsync -Haurov -e "ssh -p 2222" /var/www/xenetis.org/ root@123.123.123.132:/home/backup/

---

Je ne comprends pas pourquoi il faut mentionner la clé de chiffrement dans ce cas :

rsync -Haurov -e "ssh -i /root/.ssh/id_dsa" /var/www/xenetis.org/ root@123.123.123.132:/home/backup/

et pas dans celui-ci :

rsync -Haurov -e "ssh -p 2222" /var/www/xenetis.org/ root@123.123.123.132:/home/backup/

Quel est l'intérêt de mettre en place un système clé publique/clé privée si c'est pour avoir à préciser cette clé dans la commande ?

En revanche, pour préciser un port qui n'est pas le port par défaut, ça prend tout son sens.

Encore merci pour vos réponses. Je conclue que ssh est utilisé implicitement par défaut lors d'une connexion distante.
Krys006

Bonjour :coucou:

Citation:

---

Envoyé par Krys006

Je ne comprends pas pourquoi il faut mentionner la clé de chiffrement dans ce cas :

rsync -Haurov -e "ssh -i /root/.ssh/id_dsa" /var/www/xenetis.org/ root@123.123.123.132:/home/backup/

et pas dans celui-ci :

rsync -Haurov -e "ssh -p 2222" /var/www/xenetis.org/ root@123.123.123.132:/home/backup/

---

La réponse est dans la question.
La deuxième commande demandera un mot de passe avec une connexion sur port non standard.
Alors que la première ne demandera pas de mot de passe pour une connexion sur port standard.
N'est-ce pas ?

Citation:

---

Envoyé par Krys006

Quel est l'intérêt de mettre en place un système clé publique/clé privée si c'est pour avoir à préciser cette clé dans la commande ?

---

Tu n'es identifié :

• ni par ton adresse IP
• ni par ton adresse mac
• ni par ton pseudo.
• ni par ton shell.

Ce qui t'identifie est la clé privée.
Ce n'est pas un mécanisme de transmission sécurisée des données mais un mécanisme de signature.
La clé n'est pas transmise sur le réseau :lol:. Elle est utilisée en local pour attester que tu es bien la bonne personne auprès du serveur ssh (qui, lui, a la clé publique correspondante).

Est-ce plus clair ?

Citation:

---

Envoyé par Flodelarab

Ce qui t'identifie est la clé privée.
Ce n'est pas un mécanisme de transmission sécurisée des données mais un mécanisme de signature.
La clé n'est pas transmise sur le réseau :lol:. Elle est utilisée en local pour attester que tu es bien la bonne personne auprès du serveur ssh (qui, lui, a la clé publique correspondante).

Est-ce plus clair ?

---

Merci pour ta réponse Flodelarab. Désolé de te dire que ce n'est pas plus clair...
Je ne comprends pas bien le distinguo que tu fais entre "mécanisme de transmission sécurisée des données" et "mécanisme de signature".

Pour moi, d'après ce que je crois comprendre, "tes" deux mécanismes sont présents dans ssh. Il y a bien un algorithme d’identification à la fois du client et du serveur de façon cryptée.
MAIS, il y a aussi un algorithme de cryptage de tous les échanges effectués entre les deux machines une fois la communication établie.

Je ne sais pas très bien ce que tu voulais dire par : "Ce n'est pas un mécanisme de transmission sécurisée des données".

Parce que c'est pourtant bien le cas. Lors d'une session ssh, toutes les données échangées sont cryptées si j'ai bien compris ce qui est dit ici :

https://formation-debian.viarezo.fr/ssh.html

https://www.hostinger.fr/tutoriels/ssh-linux/

Cordialement.

Oui, lors d'une session ssh, les données échangées sont cryptées. Tu es authentifié avec la clé login/mot de passe demandé, soit avec celle-ci lue depuis ton poste. Cela permet une authentification transparente pour toi ou un script. Authentification transparente ne veut pas dire qu'il n'y a pas authentification.

Oui ssh est une connexion sécurisée.
Mais il ne faut pas mettre tous les oeufs dans la même charrue des boeufs qui ménagent leur tonsure.

Si tu indiques une clé, ce n'est pas pour chiffrer mais pour t'identifier. Le chiffrement se fera avec d'autres clés.

[Rappel]
Dans un système à clés asymétriques, ce que fait une clé, l'autre le défait. (Au moins avec RSA)
Il découle 2 possibilités:

• Soit tu chiffres avec la clé privée et tu déchiffres avec la clé publique.
  Dans ce cas, tout le monde peut déchiffrer, mais une seule personne a pu chiffrer le message: C'est un mécanisme de signature.
• Soit tu chiffres avec la clé publique et tu déchiffres avec la clé privée
  Dans ce cas, tout le monde peut écrire un message secret, mais une seule personne peut comprendre les messages. C'est un mécanisme de transmission sécurisée des données
  Si tu veux que l'on t'écrive un e-mail confidentiel, il faut que tu donnes ta clé publique à l'expéditeur.

On est d'ailleurs obligé de légèrement décaler les procédés car si tu chiffrais et signais un courrier avec la même paire de clés, tu te retrouverais au final avec le courrier en clair !!! (croyant signer alors que tu déchiffres ... c'est balot :lol: )
[/Rappel]

Bref. Je ne suis pas aller vérifier la doc mais tu va chiffrer un message avec ta clé privée pour le serveur qui utilisera la clé publique correspondante pour être sûr que tu es bien la personne que tu prétends être. Ouf. Et la connexion sécurisée va pouvoir être autorisée.

Merci pour toutes ces infos précieuses qui m'aident à mieux comprendre le fonctionnement de ce protocole sécurisé qu'est ssh.

Je voudrais juste préciser que je n'ai jamais douté de l'authentification de ssh lors d'une connexion, qu'elle soit transparente ou non, ni du chiffrement des données échangées.

Ma question de départ portait en fait uniquement sur la relation entre rsync et ssh. Je vais me répéter, mais comme tous les exemples trouvés dans les tutoriels mentionnaient la liaison entre rsync et ssh au sein de la ligne de commande, et que j'obtenais les mêmes résultats sans invoquer ssh dans la commande rsync, j'ai supposé que dans ce dernier cas, peut-être rsync transférait les données en clair, en tout débutant que je suis dans ce domaine.

Mai j'ai lu dans la doc (§ MISE EN PLACE) que rsync utilisait par défaut ssh, sauf si on le forçait à utiliser un autre shell par le biais de la variable d'environnement RSYNC_RSH, ce qui n'est pas le cas en ce qui me concerne.

(voir la doc ici : http://www.delafond.org/traducmanfr/...1/rsync.1.html)

Vos explications m'ont convaincu que non.

Avant de clore cette discussion, une petit question à Jipété concernant les paramètres de rsync :

- je ne trouve pas dans la doc à quoi correspond le paramètre -E

- je ne comprends pas l'utilisation du paramètre -u

- je ne saisis pas bien non plus le --inplace

Citation:

---

Envoyé par Krys006

Avant de clore cette discussion, une petit question à Jipété concernant les paramètres de rsync :
- je ne trouve pas dans la doc à quoi correspond le paramètre -E
- je ne comprends pas l'utilisation du paramètre -u
- je ne saisis pas bien non plus le --inplace

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

-E, --executability preserve executability -u, --update skip files that are newer on the receiver (ne devrait pas arriver [= pourrait être supprimé]) --inplace This option changes how rsync transfers a file when its data needs to be updated: instead of the default method of creating a new copy of the file and moving it into place when it is complete, rsync instead writes the updated data directly to the destination file.   This has several effects:   o Hard links are not broken. This means the new data will be visible through other hard links to the destination file. Moreover, attempts to copy differing source files onto a multiply-linked destination file will result in a "tug of war" with the destina‐ tion data changing back and forth.   o In-use binaries cannot be updated (either the OS will prevent this from happening, or binaries that attempt to swap-in their data will misbehave or crash).   o The file’s data will be in an inconsistent state during the transfer and will be left that way if the transfer is interrupted or if an update fails.   o A file that rsync cannot write to cannot be updated. While a super user can update any file, a normal user needs to be granted write permission for the open of the file for writing to be successful.   o The efficiency of rsync’s delta-transfer algorithm may be reduced if some data in the destination file is overwritten before it can be copied to a position later in the file. This does not apply if you use --backup, since rsync is smart enough to use the backup file as the basis file for the transfer.     WARNING: you should not use this option to update files that are being accessed by others, so be careful when choosing to use this for a copy.   This option is useful for transferring large files with block-based changes or appended data, and also on systems that are disk bound, not network bound. It can also help keep a copy-on-write filesystem snapshot from diverging the entire contents of a file that only has minor changes.   The option implies --partial (since an interrupted transfer does not delete the file), but conflicts with --partial-dir and --delay-updates. Prior to rsync 2.6.4 --inplace was also incompatible with --compare-dest and --link-dest.

---

--inplace : un jour j'ai fait le test suivant (avec des fichiers et machines virtuels)
Soit un disque de 30 Mo contenant un fichier de 25 Mo (et donc un espace libre de 5 Mo).
Si j'exécute rsync sur ce disque, il va recopier le gros fichier vers un disque neuf de sauvegarde, ok.
Si ensuite je modifie le fichier-source de 25 Mo, la prochaine exécution de rsync va échouer car le fonctionnement normal est de d'abord recopier le nouveau fichier avec un nom temporaire vers la destination puis ensuite y supprimer l'ancien et renommer le temporaire en original, et comme il n'y a pas assez de place pour deux fichiers de 25 Mo sur un disque de 30, ben paf ! :aie:
En cas d'incident (coupure électrique, plantage...) pendant le transfert, on se retrouvera avec la sauvegarde intacte + le fichier temporaire, à charge pour l'admin de faire le ménage.

Avec --inplace le comportement est différent : le nouveau fichier va écraser l'ancien, donc au final tout rentre, et s'il y a un incident pendant le transfert, le fichier mal sauvegardé sera inutile, encore une fois l'admin devra mettre les mains dans le cambouis, mais ça fait partie de son taf, :mouarf:

C'est beaucoup plus clair comme ça.

Merci Jipété, et à vous tous.

Krys006