Hyper Backup - Sauvegarde Syno -> Serveur rsync avec chiffrement transfert

[sadmin91]

Bonsoir,

Avec Hyper Backup, je souhaite mettre en place une sauvegarde distante de mon NAS Synology vers un serveur rsync (hébergé sur un raspberry pi).

J'ai réussi à la mettre en œuvre mais sans le chiffrement du transfert.

Si j'active cette option, le logiciel Hyper Backup m'indique que la machine distante est déconnectée lors de l'exécution des sauvegardes.

Est-ce que l'un d'entre vous aurais réussi à activer ce type de sauvegarde ?

Si oui, avec quelle configuration ?

Dans l'attente de vos retours.

[Langer]

Salut, 

Je remonte le sujet étant confronté au même problème :

Dans les paramètres de DSM, je n'ai réussi qu'à faire marcher le chiffrement en me connectant en root vers mon serveur distant (Kimsufi)

En temps normal, je bloque la connexion à mon serveur distant et change le port de connexion ssh dans ssh_config.

J'ai donc créer un nouveau user pour me connecter au serveur distant, mais impossible de cocher l'option de chiffrement, l'erreur en pièce jointe apparaît.

Seul la connexion sans chiffrement est possible avec le nouveau user.

 

Avez vous des idées d'où ça coince sur sur serveur distant ? Voici mon rsyncd.conf, assez basique pour l'instant pour vérifier le fonctionnement du rsync  :

Citation

uid = user
gid = user
max connections = 4
[TITRE DU SERVEUR DISTANT]
path = /home/user
comment = Synchro fichiers avec le NAS
read only = false

Merci de votre aide :)

 

 

 

[Amaustan]

Bonsoir, je rencontre exactement le même problème. Personne n'a d'idée ?

En faisant un tail -f sur les logs on voit que la connexion ssh est ouverte puis refermée...

Merci

Amaustan

Envoyé de mon SM-A510F en utilisant Tapatalk

[Fenrir]

Faites le test en installant une clef ssh.

@Langer : il y a plusieurs manière d'utiliser rsync, dans ton exemple tu as utilisé le serveur rsync, mais tu peux aussi le faire sans le serveur, via ssh (la syntaxe est légèrement différente (: vs ::) différente mais l'adressage aussi (port 22 pour ssh, port 873 our rsyncd)

[Langer]

Salut Fenrir,

Je ne comprends pas trop ce que tu veux faire. Veux tu que je fasse mon rsync en ligne de commande ?

Sans le rsyncd.conf, je ne peux pas trouver le serveur distant dans Hyper Backup...

[Amaustan]

Bonjour, effectivement la solution emble être l'installation d'une clé SSH. Si je possède un certificat officiel payant (pas un let's encrypt) cela fonctionne également en insérant la clé publique sur le RaspBerry distant ?
Merci

Envoyé de mon SM-A510F en utilisant Tapatalk

[Fenrir]

Il y a 7 heures, Langer a dit :

Je ne comprends pas trop ce que tu veux faire.

Je veux dire que je pense qu'Hyperbackup essaye de se connecter en ssh et que pour s'authentifier il utilise une clef ssh (c'est la méthode la plus courante). Mais comme cette clef n'est pas installée, il n'y arrive pas.

Maintenant je n'ai pas testé ni même regardé.

Il y a 7 heures, Langer a dit :

Veux tu que je fasse mon rsync en ligne de commande ?

Ça c'est sur que ça fonctionne, mais ça ne sera plus géré par Hyperbackup.

Il y a 7 heures, Langer a dit :

Sans le rsyncd.conf, je ne peux pas trouver le serveur distant dans Hyper Backup...

Citation

Also note that the rsync daemon protocol does not currently provide any encryption of the data that is transferred over the connection. Only authentication is provided. Use ssh as the transport if you want encryption.

https://download.samba.org/pub/rsync/rsyncd.conf.html

En utilisant le serveur rsync, tu utilises le protocole rsync, donc le transfert n'est pas chiffré (mais authentifié avec un login/pass à déclarer dans rsyncd.secrets).

En utilisant ssh, pas besoin de serveur rsyncd (mais peut être qu'Hyperbackup s'en sert) car ssh peut écrire directement sur le disque distant via scp et le transfert est chiffré.

Donc reste à savoir comment fonctionne HyperBackup.

Il y a 4 heures, Amaustan a dit :

Si je possède un certificat officiel payant (pas un let's encrypt) cela fonctionne également en insérant la clé publique sur le RaspBerry distant ?

Une clef ssh ce n'est pas un certificat (même s'ils partagent certaines technos).

---------

Je vous ai trouvé 3 docs, la dernière devrait correspondre à vos demandes

http://synology.pc-fute.com/2015/10/sauvegarde-du-nas-synology-vers-un-serveur-rsync/

http://pled.fr/?p=10062

https://ludovicscribe.fr/blog/sauvegardes-cryptees-raspberry

[Langer]

Merci pour ces précisions. 

Alors l'ai fais mes tests avec l'installation des clés. J'ai installé les clés en ROOT sur le Synology et mon Kimsufi. Je suis capable de me connecter en SSH sans qu'on me demande mon mot de passe. 

Cependant, J'ai aussi copié la clé dans mon dossier home/user/.ssh/authorized_keys sur le Kimsufi, mais là incapable de se connecter en ssh sans le mot de passe...

J'ai l'impression que je tourne en rond. Comme sans l'ajout des clés, le cryptage dans hyperbackup ou la connexion SSH est possible seulement en se connectant au Kimsufi avec ROOT, alors que quand on utilise un USER, cela n'est plus possible.

[Langer]

J'ai aussi suivi le tuto pour le PI sur le réseau local, http://pled.fr/?p=10062, auquel cas que mon Kimsufi avait un bug quelque part.

Il a aussi été nécessaire de faire un fichier /etc/rsync.conf, et aucun moyen d'activer le chiffrement du transfert là aussi

[Fenrir]

Je suis entrain de tester.

Sans chiffrement du transfert aucun problème, ça marche du premier coup.

Par contre avec le chiffrement j'ai un problème, mais comme il est hors de question que j'utilise un compte root ...

Pour le moment je bloque la dessus :

Jan 20 22:36:14 xxxxx sshd[29927]: Accepted password for machin from xxx.xxx.xxx.xxx port 37842 ssh2
Jan 20 22:36:14 xxxxx sshd[29927]: pam_unix(sshd:session): session opened for user machin by (uid=0)
Jan 20 22:36:14 xxxxx rsyncd[29930]: connect from monsyno (xxx.xxx.xxx.xxx)
Jan 20 22:36:14 xxxxx rsyncd[29930]: rsync allowed access on module module01 from monsyno (xxx.xxx.xxx.xxx)
Jan 20 22:36:14 xxxxx rsyncd[29930]: rsync: chroot /home/machin/test/1 failed: Operation not permitted (1)

nb : contrairement à ce que je pensais, le HyperBackup n'est pas foutu d'utiliser des clefs ssh

edit : en fait si, le piège c'est qu'HyperBackup n'est pas lancé en root sur le syno mais avec un compte dédié, c'est tellement rare chez syno que quand ils font les choses bien, on se fait avoir

ps : sans passer par Hyperbackup mais directement en ligne de commande ça fonctionne sans soucis

Modifié le 20 janvier 2017 par Fenrir

[Langer]

C'est ou que tu peux voir le log?

J'ai demandé aussi à Synology par le centre d'assistance si ils ont une solution ;)

 

[Fenrir]

il y a 2 minutes, Langer a dit :

C'est ou que tu peux voir le log?

sur le serveur évidemment, ceux du syno on s'en fou dans le cas présent mais sinon ils sont dans /var/log/rsync.error :

@ERROR: chroot failed

on est vachement avancé avec ça ...

[Fenrir]

C'est bon ça marche

[Langer]

Wow, qu'est ce qu'il faut configurer ?

[Fenrir]

Le moins de choses possible en fait !

J'ai pour habitude de toujours serrer les vis au maximum, là j’avais juste trop fermé ma conf, donc j'ai tout viré, pour ne garder que le minimum :

cat /home/machin/rsyncd.conf
socket options = SO_KEEPALIVE
use chroot = no
[module01]
   path = /home/machin/test/1
   comment = module 1
   auth users = machin,truc,chose
   secrets file = /home/machin/rsyncd.secrets
   read only = false
[module02]
   path = /home/machin/test/2
   comment = module 2
   auth users = machin,truc,chose
   secrets file = /home/machin/rsyncd.secrets
   read only = false

Reste encore à trouver comment utiliser une clef ssh

edit : C'est bon pour la clef, il faut juste l'installer dans /var/packages/HyperBackup/target/.ssh

Modifié le 20 janvier 2017 par Fenrir

[Langer]

Hello, j'ai essayé tes paramètres, cela ne marche pas chez moi...

J'ai bien créer les clés à l'endroit indiqué sur le syno : 

Citation

root@XXX:/var/packages/HyperBackup/target/.ssh# ls -l
total 8
-rw------- 1 root root 668 Jan 20 17:49 id_dsa
-rw-r--r-- 1 root root 605 Jan 20 17:49 id_dsa.pub

 

J'ai ensuite copié la clé publique dans le répertoire user de mon Kimsufi :

Citation

root@YYY:/home/user/.ssh# ls -l
total 4
-rw------- 1 user user 605 Jan 20 23:58 authorized_keys
root@YYY:/home/user/.ssh# nano authorized_keys

 

Puis j'ai modifié mon fichier /etc/rsyncd.conf

Citation

cat /etc/rsyncd.conf
socket options = SO_KEEPALIVE
use chroot = no
log file = /var/log/rsyncd.log
[XXX]
path = /home/user
comment = Synchro fichiers avec le NAS
auth users = user
secrets file = /etc/rsyncd.secrets
read only = false

 

J'obtiens toujours et encore la même erreur quand je veux chiffrer le transfert.

[Fenrir]

il y a 40 minutes, Langer a dit :

J'ai bien créer les clés à l'endroit indiqué sur le syno : 

mais pas avec les bons droits, donc elle n'est pas utilisable (tu as certainement une erreur dans les logs du syno qui te l'indique)

-rw------- 1 HyperBackup HyperBackup 1679 Jan 20 23:25 id_rsa
-rw-r--r-- 1 HyperBackup HyperBackup  390 Jan 20 23:25 id_rsa.pub

################################

il y a 42 minutes, Langer a dit :

Puis j'ai modifié mon fichier /etc/rsyncd.conf

pas le bon

Il y a 1 heure, Fenrir a dit :

cat /home/machin/rsyncd.conf

################################

il y a 44 minutes, Langer a dit :

secrets file = /etc/rsyncd.secrets

et pas correctement

Il y a 1 heure, Fenrir a dit :

secrets file = /home/machin/rsyncd.secrets

################################

il y a 45 minutes, Langer a dit :

J'obtiens toujours et encore la même erreur quand je veux chiffrer le transfert.

C'est à dire ?

[Langer]

Ça marche!!!

J'ai changé les droits et propriétaires des clé ssh puis modifié et déplacé mon rsyncd.conf dans mon USER.

Merci infiniment de ton aide, je n'aurai jamais réussi sans toi!

Bonne fin de semaine :)

 

[Fenrir]

il y a 2 minutes, Langer a dit :

Merci infiniment de ton aide, je n'aurai jamais réussi sans toi!

Pour la peine, tu nous fais un tuto ici http://www.nas-forum.com/forum/forum/28-tutorials/ ?

[Langer]

Bonne idée!

[Amaustan]

Bonsoir, cela fonctionne merci !

Par contre je n'ai pas mis en place de clé SSH. A quoi servent les vôtres ? Sauf erreur de ma part, en mettant une clé vous enfoncez une porte ouverte car la config côté Syno demande login/password.

J'ai tort ?

Amaustan

[Langer]

Effectivement, je viens de tester et cela marche sans!

C'est vraiment le rsyncd.conf qu'il fallait mettre à la bonne place.

Bien vu :)

 

Modifié le 21 janvier 2017 par Langer

[Langer]

Il y a 3 heures, Fenrir a dit :

Pour la peine, tu nous fais un tuto ici http://www.nas-forum.com/forum/forum/28-tutorials/ ?

Chose faite ;) Je n'ai pas mis le surplus avec les clé SSL, mais je l'ai en stock si jamais.

A++

[Fenrir]

Il y a 7 heures, Amaustan a dit :

Par contre je n'ai pas mis en place de clé SSH. A quoi servent les vôtres ? Sauf erreur de ma part, en mettant une clé vous enfoncez une porte ouverte car la config côté Syno demande login/password.

Le login/pass que demande le syno sert surtout à rsync, mais le compte rsync de le compte ssh ne sont en fait pas liés.

En utilisant une clef, vous protégez l'accès à votre serveur ssh, le serveur rsync lui n'a pas besoin d'être autorisé depuis internet => bcp plus sécurisé

Donc login+clef pour le ssh et login+pass pour rsync.

Le seul soucis c'est que syno ne permet pas de mettre un login ssh différent de celui du rsync, c'est ce qui a du vous perturber.

[Amaustan]

Bonjour Fenrir,

Je crois comprendre mais tu me confirmeras ou non, mais quand j'ai créé un utilisateur rsync sur mon RaspBerry distant et c'est cet utilisateur qui se connecte via ssh à rsync. Quand je fais un netstat en cours de sauvegarde, la seule connexion existante est sur le port 22 par le user rsync. (je ne tiens pas compte de ma propre connexion ssh pour faire le netstat avec un autre user)

Dans ce cas, je ne vois pas en quoi la clé ssh apporte une sécurité supplémentaire si HyperBackup effectue une connexion sécurisée over ssh ?

Amaustan