Aller au contenu

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


Messages recommandés

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.

Lien vers le commentaire
Partager sur d’autres sites

  • 6 mois après...

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 :)

 

 

 

Capture.PNG

Lien vers le commentaire
Partager sur d’autres sites

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)

Lien vers le commentaire
Partager sur d’autres sites

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

Lien vers le commentaire
Partager sur d’autres sites

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.

8. test connection user masqué.png

Lien vers le commentaire
Partager sur d’autres sites

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 :evil:

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 :lol:

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

Modifié par Fenrir
Lien vers le commentaire
Partager sur d’autres sites

:lol: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é par Fenrir
Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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 ?

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

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.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.