chloroplaste

Merci pour vos retours. Du coup je me sens d'une stupidité sans nom de ne pas avoir vu (déjà) que les cases associées à mes règles n'étaient pas cochées.... Et dire que j'avais le sentiment derrière d'être une jolie porte blindée alors que j'avais le cul à l'air derrière... Je m'en vais de ce pas lire le tutorial.

Bonjour, Je viens vers concernant la sécurité de mon syno. J'ai reçu la notification suivante de mon syno : Un Whois m'indique que cette IP est localisée au USA. Jusque là rien d'étonnant. Le seul accès ouvert vers l'extérieur sur mon syno est pour du SFTP (donc via protoclol SSH, avec redirection au niveau de routeur depuis un port lambda). Au niveau de pare-feu, seules 2 règles existent (voir capture). Mes questions sont donc les suivantes : S'agissant d'une adresse IP hors France, n'aurait-elle pas dû être bloquée avant même de pouvoir tenter une authentification ? Cette tentative est-elle juste un hasard (tomber sur mon IP + le bon port) ou s'agit-il d'un bot scannant le réseau ? (l'identification ayant été tentée sur un nom d'user n'existant même pas dans ma base). Merci d'avance pour vos retours.

Bonjour Avant le passage à DSM 6, je crois me rappeler qu'était présente par défaut une courbe de l'utilisation du stockage dans l'Analyseur de stockage. Cependant, depuis la mise à jour DSM 6, je ne retrouve plus cette fonctionnalité. Peut-être doit-elle être désormais activée manuellement mais impossible de mettre la main de dessus. Merci d'avance pour votre aide

Merci pour votre sujet auto-alimenté car cette problématique m'intéresse également. Cependant, en suivant votre tuto est-ce que je ne risque pas de retrouver dans media_dir=PV,/volume1/photoANDvideofolder mes photos et vidéos de vacances mais aussi mes films et séries ? Synology étant relativement à l'écoute, cela ne vaudrait-il pas le coup d'ouvrir un ticket pour permettre l'indexation DLNA de vidéo présentent dans /photo ?

Merci d'avoir éclairé ma lanterne.

Après quelques recherches, je suis tombé là-dessus : "Mise en place du canal sécurisé La mise en place d'une couche de transport sécurisée débute par une phase de négociation entre le client et le serveur afin de s'entendre sur les méthodes de chiffrement à utiliser. En effet le protocole SSH est prévu pour fonctionner avec un grand nombre d'algorithmes de chiffrement, c'est pourquoi le client et le serveur doivent dans un premier temps échanger les algorithmes qu'ils supportent. Ensuite, afin d'établir une connexion sécurisée, le serveur envoie sa clé publique d'hôte (host key) au client. Le client génère une clé de session de 256 bits qu'il chiffre grâce à la clé publique du serveur, et envoie au serveur la clé de session chiffrée ainsi que l'algorithme utilisé. Le serveur déchiffre la clé de session grâce à sa clé privée et envoie un message de confirmation chiffré à l'aide de la clé de session. A partir de là le reste des communications est chiffré grâce à un algorithme de chiffrement symétrique en utilisant la clé de session partagée par le client et le serveur. " Du coup cela répond à ma question de la façon dont étaient chiffrés les échanges. Mais 2 questions subsistent : - Avoir un fichier id_rsa.pub en plus du authorized_keys n'est-il pas inutile. Peut-être ai-je mal compris un point du process ? - Où le serveur obtient-il son "host key" ? est-elle générée automatiquement à chaque début de session SSH ?

Bonjour, Je viens à vous afin d'avoir des lumières sur un point qui m'échappe même après des recherches sur Internet. J'ai mis en place un serveur SFTP sur mon Syno afin de partager des données avec une personne précise.J'ai donc suivi précisément la base de connaissances Synology et avec un peu d'aide du forum en prime, tout s'est bien mis en place. Maintenant j'ai ainsi : - La clé privée stockée sur le client Filezilla de la personne à qui j'ai ouvert ce serveur SFTP - La clé publique présente sur le serveur dans un dossier .ssh du dossier /home de l'utilisateur (La clé publique est en 2 exemplaire : Un dans un fichier id-rsa.pub et l'autre dans authorized keys. J'ai bien compris le principe de chiffrement asymétrique. La clé privée permet de déchiffrer un message, chiffrer avec le publique mais aussi de signer un document. La clé publique permet, elle de chiffrer un document, ou de vérifier qu'un document provient bien du possesseur de la clé privée. Mes questions : - Avoir un fichier id_rsa.pub en plus du authorized_keys n'est-il pas inutile. Peut-être ai-je mal compris un point du process ? - Comment se déroule le chiffrement des données en SFTP ? Si le serveur ne possède que la clé publique, il est donc en mesure de chiffrer les données qui vont vers le client Filezilla. Ce client peut alors les déchiffrer avec sa clé publique. Mais comment cela se passe-t-il dans le sens inverse. Le serveur n'ayant pas de clé privé ni publique, comment fait-il le déchiffrement ? Cela signifie-t-il que l'échange de données en SFTP (dans mon cas) n'est chiffré que dans le sens Serveur -> Client et pas dans l'autre ? Merci d'avance pour vos lumières.

Merci pour ton retour. Effectivement, inutile de masquer une IP privée, j'ai eu droit à la même moquerie d'un collègue de boulot qui m'aiguillait sur le sujet. Je viens de tester avec le sudo et ça passe. La connexion en sftp est donc fonctionnelle. Merci beaucoup. J'ai aussi eu droit à un cours concernant la différence d'une session admin sous Windows par rapport à Linux. J'ai d'ailleurs trouvé sympa le petit message sous Putty après avoir activé le "sudo". Merci en tout cas pour ton aide.

Voici une nouvelle capture. En vert, ma session admin (j'ai revérifié, j'ai bien tous les droits en R/W même sur Homes) En rouge, la session de l'utilisateur à qui je cherche à configurer l'accès J'avoue avoir du mal à interpréter les résultats de la commande ls -l

Sur la capture, le nom apparaissant à gauche est mon profil admin (fait partie du groupe admin du NAS), celui avec lequel je fait les opérations. Le nom en rouge à gauche est le profil d'un ami que je cherche à modifier. En rentrant ce soir, j'essaierai les commandes données pour vérifier mes droits. il doit en effet y avoir un souci quelque part. Merci.

Bonjour, Je suis entrain de paramétrer un accès sftp pour un ami, mais je bloque. A noter qu'il s'agit de mon premier essai en sftp. Le FTP fonctionnant correctement. J'ai donc suivi à la lettre la base de connaissances Synology : Mais je bloque à l'étape illustrée dans la capture jointe. Il semble s'agir d'un problème d'autorisation mais je ne vois pas ce qui bloque. L'accès en ssh se fait via mon compte admin. L'utilisateur en question est membre des groupes suivants : - users (droits standard de ce groupe "synology" non modifiés) - FTP Amis : R/W sur /video, toutes les applications en "refuser" sauf le FTP en "autoriser", Il n'existe aucun droit "exotique" sur mon NAS, les seuls droits sont paramétrés via les groupes. J'ai également refait un essai après avoir activé les "permissions avancées" dans le partage Homes mais résultats identiques. Pourriez-vous me donner des pistes ? Merci à vous

J'avais peur qu'il faille en arriver à un script "maison" Ayant un niveau de connaissance 0 sur le sujet et malheureusement pas assez de temps, je laisse de côté pour le moment. Mais merci quand même.

Désolé pour le "bazar" mais je n'étais pas trop sûr de la section au départ.

Bonjour, Je viens à vous pour une demande assez particulière. J'utilise Cloud Station Drive pour synchroniser certains répertoires sensibles du PC de ma compagne vers le NAS. Il y a un mois de ça, l'application Cloud Station Drive ne se lançait plus sur son PC et donc plus de synchro. On a mis 3 semaines à s'en rendre compte. Comme chaque événement de synchro génère un log dans le journal de cloud station, serait-il possible de créer une alerte de ce type : " Si aucun événement de synchonisation pour [utilisateur] Sur les 5 derniers jours, Alors envoyer un mail à [utilisateur]" J'ai un peu cherché dans les options du NAS mais rien trouvé. Merci d'avance pour vos retours.

Merci pour les infos, c'est tout ce qu'il me fallait.