Langer

Je trouve que ça fonctionne bien, j'ai pas eu de problème pendant 1 an avec. Les app sont beaucoup plus nombreuses maintenant. Je ne fais pas des choses très avancées par contre haha

ok, je vais essayer, il y a l'app OpenVPN sur Yunohost. J'ai dèjà un client VPN privé pour mon surf, dont le serveur est bcp plus proche que mon serveur distant actuel :)

J'ai un serveur distant avec Yunohost dessus, avec wordpress et ma seedbox. Un script php permet de génèrer un flux rss de tous les téléchargements, cependant avec le login et mot de passe en clair, pour que DownloadStation puisse grabber les liens. http://www.nas-forum.com/forum/topic/37336-ssh-download-station-ou-notification/?page=2 L'idée est de connecter DownloadStation avec le serveur distant par clé ssh pour que le mot de passe ne soit plus obligé d'apparaitre dans les liens du flux rss. Je fais aussi une sauvegarde de certains dossiers de mon Syno vers mon serveur distant avec HyperBackup. C'est peut être too much pour mes besoins mais s'il est possible d'encapsuler seulement le trafic de Hyperbackup et du sftp par DownloadStation dans un VPN entre mon serveur distant et le Syno, la sécurité serait encore augmentée :)

j'avais fait un .htaccess effectivement pour n'autoriser que mon IP, mais malheureusement je n'ai plus d'IP fixe ... Je pense aussi au VPN entre les deux serveurs aussi, mais je crois que tout le flux DownStation passera par mon serveur distant, ce que je ne souhaite pas non plus. Je m' attarderai une fois le reste résolu haha

Si je comprends bien, le lien HTTPS contiendrait quand même login et mot de passe ?

Pas fou, J'ai jamais testé le HTTPS avec authentification, je vais tester ce soir. Les débits seront peut être différents. Je souhaite de toute manière ne plus avoir l'authentification dans mes liens rss, mais avec des clés ssh sur les deux machines. Je pense que cela sera transparent pour DownloadStation si l'authentification par clés se transmette, que ce soit du SFTP ou HTTPS

Salut Fenrir, Le flux Rss conserve l'historique, mais je peux surement le paramétrer différemment. A vrai dire, j'aimerai que tout passe par le DownloadStation, pour un suivi plus simple :) Je vais attendre sagement l'implantation du feature dans une mise à jour du syno, je suis pas pressé, ça fait 2 ans que je chercher une solution haha

Update : J'ai eu un retour du support Synology qui m'a confirmer que ce n'était pas possible pour l'instant, mais qu'il allait probablement intégrer cette fonctionnalité dans une mise à jour futur :

Bonjour à tous, je me demandais si il était possible de faire manger à DownloadStation des liens SFTP (depuis un flux RSS) qui nécessitent une authentification sur un serveur distant, mais sans inscrire le login et le mot de passe dans le lien, grace au clés ssh. Exemple de fichier qui se fait télécharger par DownloadStation sans problème je souhaite que le lien soi sous cette forme pour que le mot de passe ne soit plus visible. J'ai donc créer des clés de connexion ssh entre le syno et mon serveur distant pour éviter de rentrer le mot de passe à chaque fois. Dans la console du syno, la connexion sftp sans mot de passe au serveur distant fonctionne bien, mais les liens sftp rentrés dans DownloadStation ne sont pas téléchargés, il y a une erreur. Y a t il des paramètres supplémentaires à modifier dans le cœur de DownloadStation pour qu'il considère les connexions par clés SSH? Merci de votre aide

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

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

Effectivement, je viens de tester et cela marche sans! C'est vraiment le rsyncd.conf qu'il fallait mettre à la bonne place. Bien vu :)

Bonne idée!

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

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 : J'ai ensuite copié la clé publique dans le répertoire user de mon Kimsufi : Puis j'ai modifié mon fichier /etc/rsyncd.conf J'obtiens toujours et encore la même erreur quand je veux chiffrer le transfert.

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

C'est ou que tu peux voir le log? J'ai demandé aussi à Synology par le centre d'assistance si ils ont une solution ;)

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

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.

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

Salut Mouflo, Il faut faire un filtre pour bloquer tout ce que tu veux filtrer, puis faire tes filtres personnalisés par la suite. Voici mon filtre AUTRES et mon filtre ViKINGS

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 : Merci de votre aide :)

je lai ouvert mais sans succès. J'utilise le module de sauvegarde suivant que j'ai placé dans /home/Cedric/rsyncd.config. il y a peut être une erreur que j'arrive pas à trouver

Oui mais ça finit toujours par arriver à ce point avec mon serveur distant OVH.

Merci, c'est une astuce qui peut être utile :) On ne peut donc pas encore effectuer des tâches de sauvegarde depuis "sauvegarde et replication" du Syno avec un serveur OVH ? Sinon faut rester en ligne de commande :/