This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

Langer

[TUTO] Sauvegarde Hyper Backup vers un serveur distant rsync avec chiffrement du transfert

Messages recommandés

Sauvegarde Hyper Backup vers un serveur distant rsync avec chiffrement du transfert

 

 

Objectif : Sauvegarde des données automatisée par l’outils Hyper Backup du Syno vers un serveur distant rsync avec chiffrement du transfert

Prérequis :  Synology avec hyperbackup et droits administrateurs

       Serveur distant sous distribution linux avec droits administrateurs

Pour les fins du tutorial, j’utilise mon raspberry pi, mais la méthode marche parfaitement pour des serveurs au-delà du réseau local.

 

 

1. Connexion au serveur distant

On commence par paramétrer le serveur distant. On se logue au serveur distant en SSH, en root ou admin (port 22 par défaut)

1..png

 

En console, on va installer le paquet rsync :

root@SERVEUR-PI:~# apt-get install rsync

Et lancer le service Rsync :

root@SERVEUR-PI:~# service rsync start

 

On vérifie ensuite la configuration de la connexion ssh : 

root@SERVEUR-PI:~# nano /etc/ssh/sshd_config

Dans ce fichier, vous pouvez changer le port de connexion (22 par défaut) pour un plus exotique, désactiver la connexion en ssh avec le root et autoriser l’authentification par clés publiques si on le désire ou non. À modifier selon vos critères.

On sauvegarde le fichier et on recharge la configuration ssh :

root@SERVEUR-PI:~# /etc/init.d/ssh force-reload 

 

On peut alors créer l’utilisateur qui va permettre le transfert, backup pour mon cas :

root@SERVEUR-PI:~# sudo useradd backsyno -m -G users
root@SERVEUR-PI:~# sudo passwd backsyno
root@SERVEUR-PI:~# su - backsyno

 

Puis on va créer le module de connexion ssh permettant d’afficher le serveur dans hyper backup :

$ nano rsyncd.conf
cat /home/backsyno/rsyncd.conf
use chroot = no
max verbosity = 2
log file = /var/log/rsyncd.log
[RASPBERRY-PI]
path = /home/backsyno
auth users = backsyno
secrets file = /home/backsyno/rsyncd.secrets
comment = Synchro fichiers avec le PI
read only = false

Ainsi que le rsyncd.secrets, où sont stockés les mots de passe des auth users.

$ nano rsyncd.secrets
backsyno:motdepasse

Puis on change les droits de ce fichier

$ sudo chmod 600 rsyncd.secrets

Il y a plein de possibilités et de niveaux de sécurité pour le rsyncd.conf, je vous laisse aller consulter cette page pour plus de détails : http://www.delafond.org/traducmanfr/man/man5/rsyncd.conf.5.html

Toutefois, il est nécessaire que ce fichier se retrouve dans le répertoire utilisateur pour que tout fonctionne correctement. De plus le compte rsync et le compte linux n'ont aucun rapport, mais Le Syno a besoin que le login soit le même. 

Finalement, on créé le répertoire .ssh où l'on va stocker la clé d'authentification :

$ mkdir .ssh

 

 

2. Connexion au Synology pour activer l'authentification par clé

Si l'on souhaite faire de l'authentification par clé, il est aussi nécessaire d'autoriser la clé ssh du syno sur le serveur distant, permettant ainsi la protection de l'accès au serveur ssh. Le serveur rsync n'a pas besoin d'être autorisé depuis internet à la base.

On va maintenant ouvrir une nouvelle connexion ssh avec Putty pour se connecter au serveur Synology, et créer les clés d'authentification. Dans le cas où le service ssh est bloqué sur le Synology, se rendre dans le panneau de configuration  :

6.png

 

Se loguer avec le compte admin que vous avez choisi dans le DSM, puis se connecter au compte root :

Cedric@SYNO-NAS:/$ sudo -i
Password:
root@SYNO-NAS:~#

 

Les clés doivent être générées dans le dossier suivant /root/.ssh :

root@SYNO-NAS:/# ssh-keygen -t rsa

On se place dans le dossier des clés et on vérifie que les clés ont bien été créées avec ls -l :

root@SYNO-NAS:/# cd .ssh
root@SYNO-NAS:/# ls -l
total 8
-rw------- 1 root root 668 Jan 20 17:49 id_rsa
-rw-r--r-- 1 root root 605 Jan 20 17:49 id_rsa.pub

 

Dès lors on peut transférer la clé publique id_rsa.pub vers le serveur distant (attention au port de connexion si changé plus tôt) :

root@SYNO-NAS:/# scp -p /root/.ssh/id_rsa.pub backsyno@IP.IP.IP.IP:/home/backsyno/.ssh/

Mettre “yes” en toutes lettres, puis rentrer le mot de passe.

 

 

On retourne sur la console du serveur distant, et on va vérifier que la clé est bien là :

$ cd /home/backsyno/.ssh
$ ls -l
total 4
-rw-r--r-- 1 backsyno backsyno 605 Jan 20 17:49 id_rsa.pub

 

Il est désormais nécessaire de copier le contenant de la clé dans le fichier authorized_keys, toujours dans le répertoire .ssh du serveur distant, puis vérifier que le fichier comporte la clé publique avec un nano : :

$ cat id_rsa.pub >> authorized_keys
$ nano authorized_keys

Si la clé est présente, on peut dès lors supprimer le id_rsa.pub sur le serveur distant :

$ rm id_rsa.pub

 

La clé est bien installé, on va vérifier si la connexion ssh se fait sans mot de passe depuis la console du Synology (Attention au port par défaut) :

root@SYNO-NAS:~/.ssh# ssh -p 22 -i /root/.ssh/id_rsa backsyno@IP.IP.IP.IP

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
$ 

Aucun mot de passe n'a été demandé, la connexion ssh par clé fonctionne bien 🙂

 

Étant donné que Hyper Backup va faire les sauvegardes de fichiers, on va copier les clés dans pour les faire fonctionner avec HyperBackup :

root@SYNO-NAS:~/.ssh# mkdir /var/packages/HyperBackup/target/.ssh/
root@SYNO-NAS:~/.ssh# cp id_rsa /var/packages/HyperBackup/target/.ssh/
root@SYNO-NAS:~/.ssh# cp id_rsa.pub /var/packages/HyperBackup/target/.ssh/
root@SYNO-NAS:~/.ssh# cd /var/packages/HyperBackup/target/.ssh/

il est nécessaire de changer les droits d’accès :

root@SYNO-NAS:/var/packages/HyperBackup/target/.ssh# chown HyperBackup id_rsa
root@SYNO-NAS:/var/packages/HyperBackup/target/.ssh# chmod 600 id_rsa
root@SYNO-NAS:/var/packages/HyperBackup/target/.ssh# chown HyperBackup id_rsa.pub
root@SYNO-NAS:/var/packages/HyperBackup/target/.ssh# chmod 644 id_rsa.pub

 

Puis on change aussi le propriétaire du dossier .ssh :

root@SYNO-NAS:/var/packages/HyperBackup/target/.ssh# cd ..
root@SYNO-NAS:/var/packages/HyperBackup/target# chown HyperBackup .ssh
root@SYNO-NAS:/var/packages/HyperBackup/target# chmod 700 .ssh

 

 

3. Opération avec Hyper Backup sur le Syno

Les manipulations en console sont maintenant terminées, on peut utiliser l'outil Hyper Backup. On va créer une nouvelle tâche de sauvegarde de données, par serveur rsync distant :

2..png

 

On va ensuite rentrer les paramètres de notre serveur distant, qui est compatible rsync :

Attention si vous aviez préalablement changer de port pour l’accès SSH, dans le sshd_config, le chiffrement de transfert se fait par défaut par le port 22, sinon le port 873 pour le mode sans chiffrement.

Les identifiants de l’utilisateur qui a été créé sur le serveur distant.

Le module Rsync créé dans le ficher rsyncd.conf devrait s’afficher dans le champ Module de sauvegarde si tout va bien :).

Le répertoire dans lequel la sauvegarde va se faire sur le serveur distant : /home/backsyno/SYNO-NAS

3..png

 

Ensuite on peut choisir les différentes données et applications que l’on veut sauvegarder, ainsi que de la fréquence. Un mode de fichiers cryptés sur le serveur distant est aussi disponible, ainsi que des paramètres de rotation des anciennes versions.

4.png

 

Voici la tâche de sauvegarde du Synology vers un serveur distant rsync avec Hyper Backup et le chiffrement du transfert.

5.png

 

Merci à Fenrir pour son aide précieuse!

J Enjoy

 

Modifié par Langer

Partager ce message


Lien à poster
Partager sur d’autres sites

Un bon petit tuto qui devrait servir, juste une petite remarque

Il y a 14 heures, Langer a dit :

ssh-keygen -t dsa

dsa est déprécié, il faut choisir rsa ou ed25519

Modifié par Fenrir

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour,

Merci pour ce tuto très instructif.

Je ne suis pas sûr de bien comprendre la démarche pour la création des clés: on génère une clé publique avec le compte admin et on va l'utiliser avec le compte "backsyno" ?

Ai-je bien compris? si c'est bien ça, on ne devrait pas générer la clé depuis le compte "backsyno" ?

La clé publique générée est associée à l'utilisateur ou bien au NAS?

Merci d'avance pour vos retours.

 

 

Modifié par fildar42
ajout de texte

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 2 heures, fildar42 a dit :

La clé publique générée est associée à l'utilisateur ou bien au NAS?

Tu peux créer une paire de clef pour un utilisateur et l'utiliser pour 50, c'est juste un choix d'organisation/sécurité.

Partager ce message


Lien à poster
Partager sur d’autres sites

ok, donc si le propriétaire de ma tache Hyperbackup n'est pas root mais ADMBACKUP, je peux lui générer une clé et la mettre dans Hyperbackup/target/.ssh pour que cela fonctionne, sans utiliser la clé de root. Ca devrait fonctionner?

Partager ce message


Lien à poster
Partager sur d’autres sites

merci pour ce tuto, fonctionne bien avec mon vieux DLink DNS-323 (firmware ALT-F) converti en serveur Rsync sécurisé

 

testé en local, il me reste seulement à le mettre hors-site pour un bon backup sécurisé de mon Syno

Modifié par Garmin

Partager ce message


Lien à poster
Partager sur d’autres sites

Salut,

Merci beaucoup pour ton tuto, un petit détail cependant, en l'état actuel des choses l'utilisateur créé n'a pas accès au fichier de log. Extrait du syslog lors de la connexion du syno

rsync: failed to open log-file /var/log/rsyncd.log: Permission denied (13)

Pour ma part, sur mon serveur distant (debian sur une dedibox) j'ai du créer le fichier et lui donner les droits avec ces commandes

touch /var/log/rsyncd.log

chown backsyno /var/log/rsyncd.log

chmod 664 /var/log/rsyncd.log

A+

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 21/01/2017 à 05:34, Langer a dit :

$ nano rsyncd.conf

cat /home/backsyno/rsyncd.conf
use chroot = no
max verbosity = 2
log file = /var/log/rsyncd.log
[RASPBERRY-PI]
path = /home/backsyno
aut users = backsyno
secrets file = /home/backsyno/rsyncd.secrets
comment = Synchro fichiers avec le PI
read only = false

 

C'est encore moi, suite à quelques erreurs dans mes syslogs, 1 petite chose a modifier dans le fichier de conf rsynd.conf

il faut remplacer "aut users" par "auth users", cela n’empêche pas le fonctionnement mais le démon ne comprenant par l'argument il l'ignore...du coup cela peut créer un problème de sécurité.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour

J'ai bien tout suivi (enfin je pense) mais le syno me demande sans cesse de re-saisir la passphrase associée à ma clef...

Le serveur (un Debian) semble bien configuré vu que depuis mon mac tout ce passe bien (avec la même clef privée)

 

Si vous avez une idée.... je suis preneur

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 2018-03-12 à 16:34, pirvo a dit :

Bonjour

J'ai bien tout suivi (enfin je pense) mais le syno me demande sans cesse de re-saisir la passphrase associée à ma clef...

Le serveur (un Debian) semble bien configuré vu que depuis mon mac tout ce passe bien (avec la même clef privée)

Si vous avez une idée.... je suis preneur

C'est normal, la passphrase est demandée à chaque utilisation de la clé. Pour une clé vouée à une utilisation automatisée, je ne crée pas de passphrase pour celle-ci.

________________

 

[Il se croit intelligent ce système de forum, il tient absolument à ce que mes deux messages soient fusionnés...]

J'ai mis à jour mon Synology à la version 6.1.6-15266 Update 1 et ça semble avoir brisé les backups.

On dirait que la manipulation de créer le dossier "/var/packages/HyperBackup/target/.ssh" doive être refaite à chaque mise à jour système.

Modifié par Bishnubee

Partager ce message


Lien à poster
Partager sur d’autres sites

J'ai bien suivi le tuto, aucun problème pour paramétrer le serveur rsync (étape 1), aucun problème pour la connexion au Synology pour activer l'authentification par clé (étape 2), j'ai bien le test de connexion qui est concluant 

ssh -p 22 -i /root/.ssh/id_rsa backsyno@IP.IP.IP.IP

Par contre, étape 3, message d'erreur du Syno "Echec de l'établissement de la connexion SSH. Assurez-vous que vos identifiants sont corrects, que le service SSH du serveur de destination est normal et que la vérification en 2 étapes n'est pas activée avant de réessayer."

Donc :

  • Assurez-vous que vos identifiants sont corrects -> oui, le test précédent le prouve
  • que le service SSH du serveur de destination est normal -> oui, le test précédent le prouve
  • que la vérification en 2 étapes n'est pas activée -> on parle côté syno (c'est le cas pour mon compte ADMIN) ou côté rsync (rien de ce type côté du serveur distant) ... pourtant mon précédent paramétrage marche bien (mais c'est vrai qu'il me semble que j'ai activé l'auth en 2 étapes après l'avoir paramétré). Quel rapport entre le paramétrage HyperBackup et l'auth 2 étapes ? Si je veux pas faire sauter cette auth en 2 étapes, est-ce que je dois paramétrer un user dédié "backup" sans l'auth à 2 étapes pour pouvoir activer ce backup rsync ??

+ question supplémentaire : en fait, je met en place cette sauvegarde rsync pour remplacer une autre déjà en place (je migre mon serveur distant chez un autre host), est-ce que je peux recopier les data déjà backupées (par la précédente tâche rsync qui sont donc sur le 1er serveur) en sftp vers le 2nd serveur ... pour ne pas repartir de 0 ? (parce que 500 gb en upload depuis chez moi, ça prend des plombes ;-( )

Modifié par jnoel68

Partager ce message


Lien à poster
Partager sur d’autres sites

Je me répond à moi même ... j'ai aussi testé avec un utilisateur qui n'a pas l'authentification en 2 étapes ... même problème.

Est-ce que quelqu'un aurait une idée ?

Merci

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour, merci pour le tuto. J'aimerais savoir l'intérêt de d'authentifier par clé si l'on doit toujours renseigner username et mot de passe des 2 cotes (hyperbackup et secrets file), est-ce que cela fonctionne sans les identifiants ? S'agit il des identifiants ssh ou d'un système propre à rsync ?

Edit: bon, je pense avoir trouvé, ce doit être rsync en mode daemon qui a besoin d'un mot de passe. Si je ne me trompe pas ce mot de passe n'a rien à voir avec l'authentification ssh. Je vais faire des tests et je reviens poster.

Edit 2 : après tests je suis parvenu à mettre en place la sauvegarde. Les identifiants demandés par HyperBackup sont bien les identifiants ssh. Du coup ma question revient : quel intérêt de s'authentifier par clé ?

Modifié par badaz

Partager ce message


Lien à poster
Partager sur d’autres sites

@badaz : le login/pass sert pour rsync, le chiffrement du transfert est fait via un tunnel SSH qui lui utilise une clef.

=>sans le tunnel, tout passe en clair

=>sans le login/pass : tout le monde utilise le même "stockage" distant

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 25/01/2019 à 15:48, jnoel68 a dit :

J'ai bien suivi le tuto, aucun problème pour paramétrer le serveur rsync (étape 1), aucun problème pour la connexion au Synology pour activer l'authentification par clé (étape 2), j'ai bien le test de connexion qui est concluant 


ssh -p 22 -i /root/.ssh/id_rsa backsyno@IP.IP.IP.IP

Par contre, étape 3, message d'erreur du Syno "Echec de l'établissement de la connexion SSH. Assurez-vous que vos identifiants sont corrects, que le service SSH du serveur de destination est normal et que la vérification en 2 étapes n'est pas activée avant de réessayer."

Donc :

  • Assurez-vous que vos identifiants sont corrects -> oui, le test précédent le prouve
  • que le service SSH du serveur de destination est normal -> oui, le test précédent le prouve
  • que la vérification en 2 étapes n'est pas activée -> on parle côté syno (c'est le cas pour mon compte ADMIN) ou côté rsync (rien de ce type côté du serveur distant) ... pourtant mon précédent paramétrage marche bien (mais c'est vrai qu'il me semble que j'ai activé l'auth en 2 étapes après l'avoir paramétré). Quel rapport entre le paramétrage HyperBackup et l'auth 2 étapes ? Si je veux pas faire sauter cette auth en 2 étapes, est-ce que je dois paramétrer un user dédié "backup" sans l'auth à 2 étapes pour pouvoir activer ce backup rsync ??

+ question supplémentaire : en fait, je met en place cette sauvegarde rsync pour remplacer une autre déjà en place (je migre mon serveur distant chez un autre host), est-ce que je peux recopier les data déjà backupées (par la précédente tâche rsync qui sont donc sur le 1er serveur) en sftp vers le 2nd serveur ... pour ne pas repartir de 0 ? (parce que 500 gb en upload depuis chez moi, ça prend des plombes ;-( )

Bonjour,

Je rencontre malheureusement le même problème avec HyperBackup.

Je vais donc m'orienter vers un rsync en ligne de commande, mais il va falloir que je la retape à chaque MAJ de DSM.

Si quelqu'un a une idée je suis bien évidemment preneur 😉

Sinon excellent tuto!! 😄

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 20/04/2019 à 14:46, Fenrir a dit :

@badaz : le login/pass sert pour rsync, le chiffrement du transfert est fait via un tunnel SSH qui lui utilise une clef.

=>sans le tunnel, tout passe en clair

=>sans le login/pass : tout le monde utilise le même "stockage" distant

En fait j'ai tenté de mettre dans secrets des identifiants / mot de passe différents de mes identifiants ssh, puis d'entrer ces identifiants dans la config d'hyperbackup et la connexion était impossible. C'est en cela que j'en ai conclu (peut-être à tort) qu'hyperbackup utilisait ces infos pour la connexion ssh, d'où mes doutes sur l'utilité de la clé.  J'essaierai de retirer la clé ssh du nas pour vérifier mon hypothèse. 

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 21/01/2017 à 05:34, Langer a dit :

Dès lors on peut transférer la clé publique id_rsa.pub vers le serveur distant (attention au port de connexion si changé plus tôt) :


root@SYNO-NAS:/# scp -p /root/.ssh/id_rsa.pub backsyno@IP.IP.IP.IP:/home/backsyno/.ssh/

Mettre “yes” en toutes lettres, puis rentrer le mot de passe.

Bonjour , je suis bloqué a cette étape car j'ai changé le port ssh , est-ce que vous pouvez me dire ou je dois mettre mon - pXXX ?

 

Merci d'avance , Philippe

 

Je me reponds à moi même , il faut ecrire : root@SYNO-NAS:/# scp -p -P6969 /root/.ssh/id_rsa.pub backsyno@IP.IP.IP.IP:/home/backsyno/.ssh/

 

Par contre il ne veux rien "Echec de l'établissement de la connexion SSH. Assurez-vous que vos identifiants sont corrects, que le service SSH du serveur de destination est normal et que la vérification en 2 étapes n'est pas activée avant de réessayer."

Modifié par philserv

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 21/01/2017 à 05:34, Langer a dit :

Ainsi que le rsyncd.secrets, où sont stockés les mots de passe des auth users.


$ nano rsyncd.secrets

backupsyno:motdepasse

Petite mise à jour : Dans le fichiers rsyncd.secrets il y a une erreur , pour ceux qui suivent le tuto à la lettre , ce n'est pas le login "backupsyno" mais "backsyno" .

 

et cela fonctionne c'est moi en DSM 6

 

Merci à vous

 

Bien à vous, Philippe

Partager ce message


Lien à poster
Partager sur d’autres sites

merci pour le tuto,

Je pense que je vais essayer, afin de voir comment ça fonctionne
Au niveau du chiffrement, la connection est chiffrée entre les deux serveurs distants ? j'imagine que le backup aussi peut être chiffré ?

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 17/06/2019 à 13:38, philserv a dit :

Petite mise à jour : Dans le fichiers rsyncd.secrets il y a une erreur , pour ceux qui suivent le tuto à la lettre , ce n'est pas le login "backupsyno" mais "backsyno" .

 

et cela fonctionne c'est moi en DSM 6

 

Merci à vous

 

Bien à vous, Philippe

C'est corrigé merci!

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour,

Super tuto merci beaucoup, j'aimerais savoir qu'elle distribution Linux tu utilises ?

Je ne suis pas arrivé à trouver l'information mais peut-être que tu auras la réponse :

Est-ce qu'il y a une limite à la taille du disque dur pour une raspberry pi 3 ? (j'envisage 6To !!)

 

J'apprécie énormément ce mode de sauvegarde qui prévient des dégâts des eau, du feu, du vol etc ... car on sauvegarde vers un serveur distant et donc qui peut être dans un lieu physique différents.

 

Merci

Partager ce message


Lien à poster
Partager sur d’autres sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.