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

[Langer]

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)

 

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  :

 

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 :

 

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

 

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.

 

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

 

Merci à Fenrir pour son aide précieuse!

J Enjoy

 

Modifié le 2 septembre 2019 par Langer

[Fenrir]

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é le 21 janvier 2017 par Fenrir

[fildar42]

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é le 23 janvier 2017 par fildar42
ajout de texte

[Fenrir]

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é.

[fildar42]

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?

[Fenrir]

Tu peux mettre la même clef partout si besoin, les clefs ne sont pas liées à un login particulier.

[Garmin]

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é le 14 juin 2017 par Garmin

[vrolland]

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+

 

[vrolland]

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é.

 

[pirvo]

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

 

 

[Bishnubee]

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é le 29 avril 2018 par Bishnubee

[jnoel68]

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é le 25 janvier 2019 par jnoel68

[jnoel68]

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

[badaz]

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é le 17 avril 2019 par badaz

[Fenrir]

@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

[Lusitanio]

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!! 😄

[badaz]

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. 

[philserv]

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é le 16 juin 2019 par philserv

[philserv]

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

[Dimebag Darrell]

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é ?

 

[Dimebag Darrell]

Est-il préférable ce mode de back-up
Qui est plus sécure qu'un snapshot je suppose?

[Langer]

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!

[Biereblonde]

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

[Aurel94450]

Hello,

Merci pour ce super tuto, j'avais mis en place ce backup en début d'année sur un linux distant mais quand de chance mon linux a crashé.

J'ai du en réinstaller un nouveau et j'ai voulu re mettre en place cette solution de backup mais j'ai un erreur lors de la mise en place de hyper backup : "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."

 

Pourriez vous m'aider 

 

Cordialement

[Langer]

Le 26/07/2020 à 00:01, Aurel94450 a dit :

Hello,

Merci pour ce super tuto, j'avais mis en place ce backup en début d'année sur un linux distant mais quand de chance mon linux a crashé.

J'ai du en réinstaller un nouveau et j'ai voulu re mettre en place cette solution de backup mais j'ai un erreur lors de la mise en place de hyper backup : "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."

 

Pourriez vous m'aider 

 

Cordialement

Salut,

Tes clés de ton NAS vers ton serveur distant ne doivent plus fonctionner.

Il faut refaire la liaison, faire un test et copier les clés dans le dossier de ton Nas suivant

/var/packages/HyperBackup/target/.ssh/

Je viens de refaire le tuto, après avoir réinstaller mon serveur distant, j'ai du refaire mes clés ssh 🙂