Rechercher dans la communauté

Ce tutoriel nécessite DSM 6.2.4 ou une version ultérieure. Son but est de permettre à des clients macOS de se connecter à SSH sans avoir à fournir de mot de passe, que ce soit au niveau d'un compte administrateur ou du compte root. Ce tutoriel a été rédigé à partir de la contribution de référence du regretté unPixel : Et à partir d'une documentation émanant de Synology : Comment puis-je me connecter à DSM avec des paires de clés RSA via SSH ? Le tutoriel de unPixel est plutôt orienté PC et fait appel à des outils comme PuTTY, Pageant ou WinSCP totalement inconnus du monde Mac. Dans ce dernier on n'utilise qu'un seul outil, le Terminal. Il y a bien une partie consacrée aux environnements Mac et Linux ajoutée par @Fenrir mais toutes mes tentatives pour l'appliquer ont été vaines, du moins sous macOS Ventura. unPixel lui-même disait avec humour qu'il n'appliquait pas ce tutoriel sur son Mac et utilisait la bonne vieille méthode du mot de passe. C'est sans doute qu'il y avait quelque part un problème de mise en œuvre. Il est vrai qu'Apple, dont la dernière chimère est de de vouloir créer un système théoriquement inviolable, ne cesse de durcir de façon drastique les mesures de sécurité concernant macOS ce qui explique à mon avis les problèmes rencontrés qui sont des problèmes de droits. Bref, vous l'aurez compris, ce tutoriel est né d'une frustration. Pourquoi ça marche sur PC et pas sur Mac ? 😀 J'ai refondu la documentation de Synology et j'ai dû faire appel à leur support technique après avoir constaté qu'on ne pouvait pas l'appliquer en l'état. Le support a accepté d'ouvrir un ticket et a proposé des modifications qui se sont avérées déterminantes. Merci à eux. Facilité du tutoriel : FACILE si l'on maîtrise un peu l'interface en ligne de commande Durée : 20 minutes environ INTRODUCTION L’authentification par clés SSH (Secure Shell) fonctionne en utilisant une clé publique sur le NAS et une clé privée sur l'ordinateur local. La clé publique peut être placée sur n’importe quel serveur distant auquel on souhaite accéder. C'est d'ailleurs ce que nous ferons par la suite. La clé privée reste sur le Mac et n'est jamais communiquée à quiconque : lors du lancement de la session SSH le NAS envoie une requête à l'ordinateur local et c'est lui qui, en confrontant la clé publique transmise par le NAS et la clé privée qu'il détient, accepte ou pas l'ouverture de session. Le NAS ne voit qu'une chose, la réponse de l'ordinateur local et c'est oui ou non. Dans ce dernier cas l'ouverture de session est bien entendu refusée. Comme l'a dit @.Shad. que je me permets de citer « En gros la clé publique c'est ta réservation au restaurant, et la clé privée c'est le fait de prouver ton identité. ». SSH utilise des algorithmes de cryptage puissants pour sécuriser la communication entre le client et le serveur. Il garantit que les données transmises sur le réseau ne peuvent pas être interceptées ou modifiées par des entités malveillantes. Remarque : la mise en œuvre du tutoriel implique de faire des allers-retours constants entre le Mac (via l'application Terminal) et DSM. Suivez bien les instructions qui sont données car elles vous indiquent où vous vous trouvez et ne vous perdez pas ! N'hésitez pas à m'indiquer les difficultés que vous aurez pu rencontrer afin que j'améliore le tutoriel. De toute façon, si vous rencontrez des problèmes qui vous obligent à tout recommencer, la marche à suivre est décrite en fin de document. N'hésitez pas à m'en faire part là encore. Il est vivement recommandé pour des raisons de sécurité de changer le port par défaut de SSH dans le panneau "Terminal & SNMP" du Panneau de configuration. À chaque fois que vous verrez une commande "ssh ... -p XX" par la suite, remplacez XX par le port que vous avez spécifié. ATTENTION : N'ouvrez pas ce port sur votre box Internet car il doit être utilisé en local pour des raisons de sécurité une fois de plus. Si vous devez absolument vous connecter à SSH sur le NAS hors du réseau local utilisez un VPN. LANCEZ L'APPLICATION TERMINAL SUR LE MAC Inutile de la télécharger, elle est présente sur tous les Mac. Dans tout ce qui suit vous devrez remplacer "username" par par votre nom d'utilisateur sur le NAS et sur le Mac. Ils peuvent être différents (c'est le cas chez moi). Il faut faire attention au contexte dans ce cas afin d'appliquer la bonne substitution : Terminal Mac --> usernameX, SSH --> usernameY. GÉNÉRATION DES CLÉS On génère une paire de clés SSH à partir du Terminal du Mac avec la commande ssh-keygen en spécifiant l’algorithme de chiffrement désiré. J'ai retenu ed25519 qui est le plus sûr à ce jour : ssh-keygen -t ed25519 Vous êtes invité à saisir le chemin d'accès au dossier qui contiendra la clé publique et la clé privée. Laissez l’emplacement par défaut, à savoir : /Users/username/.ssh/id_ed25519 en appuyant sur Entrée. Vous êtes invité à saisir une phrase de passe (passphrase) pour la clé privée CE QUI EST VIVEMENT RECOMMANDÉ VOIRE INDISPENSABLE. Vous pouvez cependant l'ignorer en appuyant deux fois sur la touche Entrée si vous ne souhaitez pas saisir de passphrase à chaque fois que vous utilisez la clé. @Fenrir recommande, je cite « de protéger la clef avec un super mot de passe » et « de renouveler la clef de temps en temps (1 fois par an c'est largement suffisant) en pensant bien à supprimer la clef publique de l'ancienne ». La clé publique (id_ed25519.pub) et la clé privée (id_ed25519) ont été crées sur le Mac dans le dossier choisi plus haut. Il est possible de stocker la passphrase dans le Trousseau d'accès du Mac en utilisant ssh-agent mais je me méfie de cette solution que je n'ai d'ailleurs pas retenue pour deux raisons au moins : La passphrase dans le Trousseau n'est pas identique à la passphrase fournie à l'origine ce qui peut poser problème. De plus la passphrase peut être tronquée par rapport à l'original ce qui n'est pas normal et pose des problèmes de sécurité. C'est bien beau de définir une passphrase de 25 caractères s'il elle est finalement tronquée à 10 caractères dans le Trousseau... Je reproche au Trousseau d'accès d'être dépendant de la session utilisateur puisqu'il est débloqué automatiquement à l'ouverture de la session. Suite à un vol où le cambrioleur a physiquement accès à la machine, il est difficile d'être certain que le mot de passe de session ne sera pas décrypté. Dans tous les cas de figure il est nécessaire pour se connecter à SSH de connaître la passphrase, il ne faut pas faciliter la tâche des intrus en la stockant quelque part sauf dans des coffres sécurisé comme Vaultwarden ou 1Password qui ont leur propre mot de passe et ne sont pas débloqués automatiquement à l'ouverture de session. Vous devrez par la suite copier la clé publique (id_ed25519.pub) dans le dossier home de votre compte administrateur sur le NAS en utilisant File Station. Cette clé se trouve actuellement dans un dossier masqué sur le Mac (.ssh est masqué car précédé d'un point). C'est pourquoi ce dossier n'apparaîtra pas dans la fenêtre de File Station. Pour contourner le problème, le plus simple est d'utiliser le terminal. Il faut se positionner dans le dossier .ssh sur le Mac : cd ~/.ssh puis copier la clé à la racine de son home sur le Mac : cp id_ed25519.pub ~/id_ed25519.pub ENREGISTREMENT DE LA CLÉ PUBLIQUE DANS VOTRE COMPTE ADMINISTRATEUR SUR LE NAS Connectez-vous à DSM avec votre compte administrateur. Accédez à File Station. Dans votre dossier home créez un sous-dossier nommé .ssh (n'oubliez pas le point au début de .ssh). Transférez la clé publique id_ed25519.pub (qui est désormais visible) dans le dossier .ssh en utilisant l'onglet "Charger" de File Station comme illustré ci-dessous (lionel est mon dossier home). Il faut ensuite accéder au dossier home sur le Mac avec le Terminal et supprimer la clé qui s'y trouve afin de faire le ménage (on l'avait déplacé là afin qu'elle soit visible). cd ~/ rm id_ed25519.pub CONNEXION SSH ADMINISTRATEUR AVEC LA PAIRE DE CLÉS Connectez-vous à SSH avec votre compte administrateur sur le NAS. Un message d'avertissement apparaît : The authenticity of host '[192.168.1.2]:22 ([192.168.1.2]:22)' can't be established. ED25519 key fingerprint is SHA256:4nLwr4EVpCwt/jjH9kIEXDUaILvWhVXCzbDCzJv4z66. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? Ce message apparaît lors de la première connexion SSH ce qui est normal. Répondez simplement 'yes'. Warning: Permanently added '[192.168.1.2]:22' (ED25519) to the list of known hosts. Après, vous pouvez être déconnecté auquel cas vous aurez le message : Connection closed by 192.168.1.2 port 22 Il vous faut vous reconnecter dans ce cas. Si vous avez le message : username@192.168.1.2's password: On vous demande simplement votre mot de passe à la suite de quoi vous serez déconnecté de toute façon ! Pour des raisons qui m'échappent, les deux cas se sont produits lors des tests que j'ai réalisés. Pour faire simple dans tous les cas de figure reconnectez-vous ! Accédez au dossier .ssh précédemment créé sur le NAS : cd ~/.ssh Ajoutez la clé publique à un fichier, authorized_keys qui sera créé à cette occasion : cat id_ed25519.pub >> authorized_keys Le dossier .ssh sur le NAS contient désormais deux fichiers : authorized_keys et la clé publique id_ed25519.pub. Se positionner dans son home sur le NAS cd ~/ Puis taper les instructions suivantes où 711 donne les droits en lecture et en écriture au seul propriétaire (vous) et le droit d'exécution à tout le monde : chmod 711 .ssh chmod 711 .ssh/authorized_keys chown -R username .ssh/ Où username est votre nom d'administrateur sur le NAS. Ceci afin d'être sûr que les droits sur ces dossiers sont conformes aux règles. Ces instructions sont très importantes. La première partie du tutoriel est terminée. Vous pouvez maintenant vous connecter à SSH à l'aide de votre compte administrateur sans avoir à saisir un mot de passe. Mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés (ce qui, je le rappelle, est vivement recommandé). Par exemple : ssh username@192.168.1.1 -p XX Enter passphrase for key '/Users/username/.ssh/id_ed25519':_ CONNEXION SSH ROOT AVEC LA PAIRE DE CLÉS Sur le NAS, se connecter à SSH en tant que root à partir de votre compte administrateur en tapant "sudo -i". Soyez conscients qu'en tant que root vous avez tous les droits sur le NAS et qu'une erreur sur une commande peut provoquer des dommages irrémédiables. En cas de doute, il est préférable de copier les commandes du tutoriel et de les coller dans la session SSH. Exécutez la commande mkdir /root/.ssh afin de créer le dossier .ssh s'il n'existe pas. Il peut avoir été créé auparavant si des clés d'administrateurs autres que vous ont été consignées. Vous aurez dans ce cas le message d'erreur : mkdir: cannot create directory ‘/root/.ssh’: File exists qui est sans gravité. Accédez à votre propre dossier .ssh sur le NAS qui se trouve dans votre dossier home : cd /volume1/homes/username/.ssh où volume1 est le volume dans lequel se trouve le fichier id_ed25519.pub et username votre nom d'utilisateur sur le NAS. On crée le fichier authorized_keys de root s'il n'existe pas et on ajoute la clé publique id_ed25519.pub. cat id_ed25519.pub >> /root/.ssh/authorized_keys Entrez la commande chmod 700 -R /root/.ssh afin d'être certain que tout ce qui se trouve dans le dossier .ssh n'est accessible qu'au compte root et ceci est très important (700 donne l'exclusivité de tous les droits à root). ON REDÉMARRE LE SERVICE SSH POUR QUE LES CHANGEMENTS SOIENT PRIS EN COMPTE DSM6 : synoservicectl --reload sshd DSM7 : systemctl restart sshd Vous pouvez maintenant vous connecter en tant que root sans avoir à saisir de mot de passe mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés comme indiqué plus haut. Par exemple : ssh root@192.168.1.1 -p XX Le tutoriel est terminé. MODIFIER LA PASSPHRASE Lancer le Terminal sur le Mac et taper : ssh-keygen -p -f ~/.ssh/id_ed25519 On demande l'ancienne phrase de passe puis la nouvelle. Il faut parfois relancer le service SSH pour que le changement soit pris en compte. Le plus simple est d'essayer de se connecter en tant que root avec la nouvelle passphrase et, si elle est refusée, de saisir l'ancienne. Les changements n'ont pas été pris en compte dans ce cas et il faut utiliser la commande de redémarrage du service SSH indiquée ci-dessus (celle-ci nécessite les droits root). EN CAS D'ERREUR LORS DE LA MISE EN ŒUVRE DU TUTORIEL QUI VOUS OBLIGE A TOUT RECOMMENCER NB : Ces instructions ne s'appliquent que si vous êtes le seul administrateur du NAS ou si vous avez créé une session SSH avec paire de clés pour la première fois. Si un historique préexiste n'hésitez pas à me contacter. Connectez-vous à SSH en tant que root sur le NAS et supprimez son dossier .ssh : rm -R .ssh Connectez-vous à SSH avec votre compte administrateur sur le NAS et supprimez le dossier .ssh qui se trouve dans votre dossier home : rm -R .ssh Lancez l'application Terminal et supprimez le dossier .ssh qui se trouve dans votre dossier home sur le MAC : rm -R .ssh VOUS AUREZ COMPRIS QUE CES ACTIONS SONT IRRÉVERSIBLES ! CRÉATION D'UN FICHIER DE CONFIGURATION SUR LE MAC Un fichier de configuration permet de définir des profils par défaut (hosts) en renseignant l'adresse IP du serveur, le nom d'utilisateur sur le serveur, le port utilisé par SSH et le chemin d'accès à la clé privée. Ainsi au lieu de taper ssh username@192.168.1.1 -p XX pour initier une session SSH, il suffit de taper ssh username Il est possible de créer dans le fichier de config plusieurs hosts avec des adresses IP différentes ce qui permet de se connecter à des serveurs distincts. Ne créez un fichier de config qu'après de la mise en œuvre complète du tutoriel lorsque vous serez sûr que tout fonctionne. # point d'entrée : tapez ssh server_1 pour vous connecter Host server_1 HostName 192.168.1.1 # nom d'utilisateur sur le serveur User username Port XXX # Chemin d'accès à la clé privée IdentityFile ~/.ssh/id_ed25519 Host nas HostName ndd.fr User cyberfr Port XXX IdentityFile ~/.ssh/id_ed25519 Host root HostName 192.168.1.2 User root Port XXX IdentityFile ~/.ssh/id_ed25519 Le fichier de configuration doit être placé sous le nom "config" (sans extension) dans le dossier .ssh de votre home où résident déjà les clés publiques et privées id_ed25519 et id_ed25519.pub. Le plus simple est de le rédiger dans un traitement de texte (TextEdit ou BBEdit) puis de le déplacer au bon endroit. Il vaut mieux respecter le canevas des exemples donnés ci-dessus et ne pas utiliser de tabulations (je n'ai pas essayé donc je ne sais pas si elles sont acceptées 😀).

1. Préambule Ce tutoriel a pour but d'autoriser l'accès aux données du NAS via le protocole SMBv1 (ou NT1) sans pour autant impacter le niveau de sécurité d'accès au NAS. Cela permet d'assurer la compatibilité d'équipement qui n'auraient pas été mis à jour par leur fabricant. SMBv1 est un protocole déprécié et comportant des failles de sécurité. Lorsqu'il est possible de vous en passer, faites-le. 2. Prérequis Avoir un NAS compatible Docker, voir la liste ici. Savoir se connecter au NAS via SSH en root : Utiliser Docker-compose Avoir installé le paquet SynoCLI File Tools, pour ajouter le dépôt SynoCommunity voir la partie Easy Install sur cette page. IMPORTANT : Si vous souhaitez accéder aux dossiers partagés "music", "video", etc... à la racine tels quels, ça ne pourra pas fonctionner, il faudra monter des sous-dossiers de ces dossiers partagés. Autant prévenir de suite. 3. Principe Afin de ne pas devoir réduire drastiquement le niveau de sécurité du NAS en autorisant le protocole SMBv1, on va passer par un conteneur qui va monter uniquement les fichiers du NAS dont on a besoin, et qui lui, autorisera l'accès en SMBv1. Comme le NAS utilise déjà le port 445 pour parler SMB avec les autres périphériques du réseau, il n'est pas disponible, on va donc utiliser un réseau macvlan (voir point 11-A de mon tutoriel introductif à Docker). Ce réseau permet entre autre d'attribuer au conteneur une IP située sur le même sous-réseau que votre réseau local. En somme, il devient accessible comme n'importe quelle autre machine, avec une IP par exemple du 192.168.0.x. Comme il est fréquent de faire avec des machines virtuelles. Cela permet notamment d'utiliser des ports déjà utilisés sur le NAS, et facilite la détection par les autres appareils, car visible directement par tout le réseau. 4. Mise en place du réseau macvlan Je ne détaille pas cette étape, car elle est décrite avec précision au point 11-A-1 du tutoriel introductif. A noter dans ce tutoriel précis qu'il n'est pas nécessaire de mettre en application le point 11-A-2 qui s'attarde sur la création d'une interface virtuelle pour communiquer entre le NAS et le conteneur. Si vous avez déjà un réseau macvlan disponible, assurez-vous simplement de disposer d'une IP libre dans la plage utilisée. Et adaptez les hypothèses suivantes. 5. Hypothèses Je vais me baser sur la plage et le sous-réseau utilisés dans le tutoriel introductif : IP hôte (NAS) : 192.168.0.100 Passerelle : 192.168.0.1 Sous-réseau local : 192.168.0.0/24 (ou encore écrit 192.168.0.0/255.255.255.0) Plage macvlan : 192.168.0.144/28 (vous pouvez vérifier les IP que ça concerne ici : http://jodies.de/ipcalc) IP conteneur : 192.168.0.145 Les valeurs en orange sont directement héritées de la mise en place du réseau macvlan, et sont simplement répétées par rapport au tutoriel introductif dans un souci de contextualisation. Les valeurs en vert sont propres à votre installation et ce tutoriel. 6. Configuration 6-A. Fichier docker-compose On va créer le fichier docker-compose.yml qui va reprendre toute la configuration de notre conteneur. On va utiliser l'image servercontainers/samba. Elle met à disposition un serveur Samba entièrement configurable, accompagné d'Avahi et WSD pour qu'il s'annonce sur le réseau et le rendre consultable et visible dans Finder (Mac) et l'explorateur Windows. Il faut savoir que cette image a été améliorée suite à des propositions que j'ai faites à son créateur. Elle a été adaptée pour faciliter la compatibilité avec DSM et sa version particulière de Linux. Tout d'abord, on se connecte en SSH en root, puis on crée le dossier qui va contenir la configuration du conteneur mkdir -p /volume1/docker/samba/ && cd $_ mkdir conf On va ensuite créer le fichier docker-compose.yml en utilisant nano (ou le télécharger ici : docker-compose.yml et l'importer dans File Station au bon endroit). nano docker-compose.yml dont voici un modèle : version: '2.1' services: samba-nt1: image: servercontainers/samba container_name: samba-nt1 hostname: samba-nt1 networks: mac0: ipv4_address: 192.168.0.145 environment: ## Groups ## - GROUP_users=100 ## Accounts ## - ACCOUNT_media=motdepassemedia - UID_media=10XX - GROUPS_media=users ## Global variables ## - SAMBA_GLOBAL_CONFIG_server_SPACE_min_SPACE_protocol=NT1 - SAMBA_GLOBAL_CONFIG_ntlm_SPACE_auth=ntlmv1-permitted - SAMBA_CONF_MAP_TO_GUEST=Never ## Shares ## - SAMBA_VOLUME_CONFIG_music=[music]; path=/shares/music; guest ok = no; read only = yes; browseable = yes; valid users = media; force group = users volumes: - /volume1/music/bibliotheque:/shares/music - /volume1/docker/samba/conf:/etc/samba restart: unless-stopped networks: mac0: external: true 6-B. Personnalisation des paramètres 6-B-1. Général Dans un fichier docker-compose, il n'y a pas de tabulation, uniquement des espaces, et il est important de respecter l'indentation (l'alignement). Les sauts de lignes ou le nombre d'espaces que vous mettez pour décaler les items n'a en revanche aucun impact, assurez-vous juste que ce soit lisible. hostname : cette variable est importante ici car c'est le nom que vous verrez apparaître dans la découverte de réseau de Windows. Cette chaine de caractères est automatiquement convertie en majuscules sous Windows, évitez les caractères exotiques. ipv4_address : c'est l'adresse IP que j'attribue manuellement au conteneur, c'est la première disponible dans la plage que j'ai choisie pour mon réseau macvlan nommé mac0. GROUP_users : On va définir au sein du conteneur un group "users", celui-ci correspond au groupe auquel appartient naturellement votre/vos utilisateur(s) du NAS. On lui donne la valeur de 100 car c'est le gid du groupe users sur DSM également. Si pour une raison ou un autre vous utilisez un groupe personnalisé, vous devez déterminer le GID affilié à ce groupe. Pour cela, tapez en SSH : cat /etc/group | grep nom_du_groupe Il faudra utiliser le nombre à la fin de la ligne en sortie de commande. ACCOUNT_media, UID_media et GROUPS_media : Voir paragraphe 6-B-3. SAMBA_GLOBAL_CONFIG_server_SPACE_min_SPACE_protocol : En lui donnant une valeur NT1 on autorise SMBv1 comme protocole minimal, depuis Samba 4.x le protocole minimal est SMB2. NT1 est le nom officiel de SMBv1. SAMBA_GLOBAL_CONFIG_ntlm_SPACE_auth : Il faut également autoriser l'authentification NT1. SAMBA_CONF_MAP_TO_GUEST : On ne souhaite pas que les utilisateurs soient automatiquement redirigés sur guest en cas de mauvais nom d'utilisateur ou de mot de passe. Donc on désactive la directive. SAMBA_VOLUME_CONFIG_music : voir 6-B-4. volumes : voir 6-B-2. restart: unless-stopped : Le conteneur redémarre quand il s'arrête suite à une erreur, si le service Docker ou le NAS redémarrent. Sauf si on l'a arrêté manuellement. networks : Je dois définir la nature du réseau mac0 invoqué plus haut pour le paramètre ipv4_address. Il a été créé extérieurement au conteneur, ce que je précise par le paramètre external: true. 6-B-2. Volumes Pour revenir au point abordé dans les pré-requis, et sans rentrer dans les détails, l'utilisation de cette image avec DSM possède quelques limitations : Il n'est pas possible de monter directement un dossier partagé à la racine : par exemple dans mon fichier docker-compose, je monte /volume1/music/bibliotheque et pas /volume1/music dans /shares/music. Cela vient des permissions UNIX qui sont inexistantes au niveau des dossiers partagés du point de vue de l'utilisateur root, c'est la surcouche d'ACL qui gère les permissions. Par conséquent, les permissions UNIX doivent être suffisantes pour garantir un fonctionnement adéquat. Prenons un exemple : ls -l /volume1/music Les permissions UNIX pour le dossier "bibliotheque" par exemple sont définies par les caractères qui se situent à gauche du "+" : drwxr-xr-x. Cas d'utilisation : Pour traverser les dossiers et lire en lecture seule avec un utilisateur authentifié, il faut a minima : dr-x------ pour un dossier (-r-x------ pour un fichier). Pour traverser les dossiers et lire/écrire avec un utilisateur authentifié, il faut a minima : drwx------ pour un dossier (-rwx------ pour un fichier). NON RECOMMANDÉ : Pour traverser les dossiers et lire en lecture seule avec un utilisateur guest (non authentifié), il faut a minima : d------r-x pour un dossier (-------r-x pour un fichier). NON RECOMMANDÉ : Pour traverser les dossiers et lire/écrire avec un utilisateur guest (non authentifié), il faut a minima : d------rwx pour un dossier (-------rwx pour un fichier). Je ne recommande pas les deux derniers cas d'utilisation, car SMBv1 est un protocole déprécié et ayant des failles de sécurité. Or SMB de manière générale est sûrement le moyen le plus simple d'infecter un NAS. Néanmoins, cela peut avoir son utilité par exemple pour des imprimantes d'ancienne génération, qui stocke des éléments scannés dans un répertoire du NAS via SMBv1. L'utilisation d'un guest doit rester exceptionnelle. NOTE : Avoir d------rwx n'implique pas qu'un guest aura forcément accès aux données du partage, on peut tout à fait désactiver l'accès guest par la configuration du partage (voir point 6-B-4), limiter l'accès à certains partages à certains utilisateurs uniquement, etc... c'est simplement une condition nécessaire, mais non suffisante. En revanche, si vous n'avez pas ces permissions a minima, activer le guest n'aura aucun effet. Voilà un type de montage qu'on pourrait vouloir faire : volumes: - /volume1/music/bibliotheque:/shares/music - /volume1/video/films:/shares/films - /volume1/video/series:/shares/series - /volume1/famille/documents:/shares/documents On doit aussi s'assurer d'avoir monté le dossier dans lequel se trouvera le fichier de configuration smb.conf créé par le conteneur lors de sa mise en route : - /volume1/docker/samba/conf:/etc/samba 6-B-3. Utilisateur Pour faciliter le bon fonctionnement du conteneur, il est recommandé de créer des utilisateurs dont le nom existe déjà dans DSM. Dans mon cas, j'ai un utilisateur media qui est propriétaire de tous les fichiers multimédias (musique et vidéo). ls -l /volume1/music/bibliotheque Au sein d'un même partage (par exemple le contenu musical), il est recommandé qu'un seul et même utilisateur soit propriétaire de tous les fichiers. Ca ne changera rien dans DSM car le système a sa propre couche d'ACL qui détermine les permissions de chacun, et ça facilitera l'exploitation du conteneur. Pour unifier le propriétaire d'un ensemble de fichiers et dossiers, c'est très simple, on va dans File Station, on sélectionne les éléments dont on souhaite changer la propriété, clic droit, Propriétés. En bas de la fenêtre, on choisit le propriétaire. Si on a sélectionné un dossier, on peut cocher la case "Appliquer à ce dossier, ses sous-dossiers et ses fichiers" pour que les enfants héritent du même propriétaire. NOTE : Si vous sélectionnez à la fois des dossiers et des fichiers, il se peut que le cadre Propriétaire n'apparaisse pas. Limitez votre sélection et ça marchera. Je vais donc créer un utilisateur media dans le conteneur via la variable d'environnement : ACCOUNT_media. La valeur de cette variable est le mot de passe pour l'utilisateur media dans ce conteneur. NOTE : Ce mot de passe ne doit pas être le même que celui pour l'utilisateur media du NAS ! En effet, le conteneur aura ses propres accès. La documentation de cette image permet de chiffrer ce mot de passe, pour ma part je n'en vois pas l'intérêt. Car pour accéder à ce fichier, l'utilisateur doit déjà avoir infecté le NAS. Cacher ses clés dans la maison n'a pas d'intérêt s'il y a déjà effraction. Concernant la variable UID_media, il s'agit de l'ID de l'utilisateur. Il est pratique d'utiliser le même UID que celui de l'utilisateur du NAS. Pour récupérer cet UID, il suffit de taper en SSH : id media Dans mon cas c'est 1035, dans tous les cas c'est strictement supérieur à 1025. Enfin, pour GROUPS_media, on lui donne la valeur users, par défaut l'utilisateur appartient à un groupe identique à son nom d'utilisateur. Pour DSM, le groupe users est le groupe par défaut pour les utilisateurs. On s'assure une meilleure compatibilité avec les ACL. Au final, en configurant ces trois variables, on assure la création d'un utilisateur qui pourra se servir des droits utilisateurs accordés par les permissions UNIX et ne fâchera pas les ACL de DSM. REMARQUE : Il est tout à fait possible de créer plusieurs utilisateurs, par exemple si vous décidez de monter l'espace personnel d'un utilisateur du NAS, ou simplement parce que tous les fichiers de vos partages n'appartiennent pas à un seul et même utilisateur. Exemple : - ACCOUNT_media=motdepassemedia - UID_media=1035 - GROUPS_media=users - ACCOUNT_lolita=motdepasselolita - UID_lolita=1031 - GROUPS_lolita=users 6-B-4. Configuration des partages La configuration des partages se fait via la variable d'environnement SAMBA_VOLUME_CONFIG_music (pour un partage qui se nommerait "music"). La valeur associée peut paraître étrange avec ses points virgule, mais ça représente juste un saut de ligne dans ce qui correspond habituellement à la configuration d'un partage SMB. Voyons plus en détail : path=/shares/music : correspond à l'emplacement qu'on a indiqué dans le montage de volume, c'est le chemin DANS le conteneur. [music] : c'est le nom du partage tel que vous le verrez dans votre explorateur. Vous pouvez utiliser des majuscules et des espaces ici. guest ok : prend la valeur "yes" ou "no", dans le premier cas lorsque vous vous connecterez aucun mot de passe ne vous sera demandé. Valeur recommandée : no. read only : est assez explicite, prend la valeur "yes" ou "no". En SMBv1, préférez la lecture seule. browseable : permet de voir apparaître le partage dans les onglets de découverte du réseau. valid users : permet de définir quel(s) utilisateur(s) sont autorisés à accéder au partage. Pour ajouter plusieurs utilisateurs, les séparer par une virgule. Si tous les utilisateurs peuvent accéder au partage, il n'est pas nécessaire d'utiliser cette directive. force group : Par défaut, ce sera l'utilisateur media/media qui écrira quand on est connecté avec cet utilisateur, on souhaite que le groupe par défaut soit users, d'où la valeur forcée à "users" pour ce paramètre. Autres directives majeures disponibles : comment : permet de décrire notre partage, majuscules autorisées. directory mask : permet de définir quelles seront les permissions UNIX par défaut lors de la création d'un dossier. Exemple : create directory mask = 0755 => les dossiers auront les permissions suivantes : drwxr-xr-x. Voir la page Wikipédia (Fonctionnement - Représentation des droits) pour plus d'information : https://fr.wikipedia.org/wiki/Permissions_UNIX create mask : même chose pour un fichier. guest only : nécessite d'avoir réglé guest ok sur "yes" au préalable. Accès guest seulement (pas d'authentification). Il existe énormément de paramètres configurables pour un partage SMB, voir la liste ici : https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html Tout est maintenant configuré. On n'a plus qu'à sauvegarder le fichier docker-compose (sous nano, CTRL+O puis Entrée pour sauvegarder, CTRL+X pour sortir de l'éditeur). 7. Création du conteneur Pour créer le conteneur, on vérifie qu'on se trouve toujours dans /volume1/docker/samba et on tape : docker-compose pull Ce qui va télécharger la dernière version de l'image. Puis : docker-compose up -d Si pas d'erreur à la création (souvent dues à des caractères de tabulation, une directive dans le fichier docker-compose mal orthographiée ou désalignée, etc...), vous verrez un petit done apparaître en vert. Si browseable a été activé, on voit le partage dans la découverte réseau : Tous les autres moyens habituels pour accéder à un partage SMB sont actifs (connecter un lecteur lecteur réseau, smb:// via Finder, etc...). MàJ : 13/01/2022

Bonjour, Voulant me connecter comme d'habitude à mon NAS via un terminal en SSH et grand étonnement, je me retrouve avec un message du type : Je vais donc dans le panneau de configuration vérifier l'activation du service SSH. Constat : Désactivé 😥 Je le réactive donc et j'applique la modif pour l'enregistrer mais là il se désactive à nouveau. Même problème après plusieurs tentatives de réactivation. J'active donc le service TELNET et via PuTTY je me connecte au NAS. Sous root je relance le service SSHD (synosystemctl restart sshd.service) et revient sur l'UI du NAS pour réactiver le service SSH. Mais là toujours pareil, impossible à réactiver ce service SSH. 🙄 Du coup j'en appelle "aux barbus" du site car là je n'ai plus d'idées🥴. Edit : J'ai aussi reboot le NAS mais sans effet ... Comment puis-je m'en sortir ? Je n'ai pas encore osé un reset mode 1, serait-ce d'ailleurs vraiment utile d'en passer par là ? Il y a sûrement une autre solution, non ? D'avance MERCI pour vos réponses. Cordialement oracle7😉

Bonjour, Pour X raisons je souhaitais accèder aux arcanes de SRM via une connexion SSH avec mon utilisateur courant ayant des droits Admin mais voilà la connexion est refusée. Après investigation je m'apperçois que pour cet utilisateur j'avais activé la 2FA. Du coup, cette connexion peut-elle être qu'en même possible ou pas ? Si d'aventure la réponse est Oui quelle est alors selon vous l'astuce à employer ? D'avance Merci de vos réponses. Cordialement oracle7😉

Bonjour, les disques durs de mon DS218 étaient en accès constant hier soir. impossible de se connecter au Finder. J'ai attendu 3 h, toujours pareil et du coup j'ai appuyé sur le bouton ON/OFF qui s'est aussi mis à clignoter. Ce matin, rien de changé. J'ai débranché l'onduleur et coupé l'alimentation du disque. Tout est reparti avec des dates de mises à jour erronées sur Video station, classique après une panne électrique. Je n'ai toujours aucune idée de ce qui s'est passé, rien vu dans les journaux .... Est-ce que j'avais une autre solution, sachant que j'avais désactivé telnet/ssh et le user admin. Là j'ai réactivé SSH et Admin et testé un top et un kill de process. Voilà, ça m'embête de laisser SSH et Admin mais ai-je vraiment le choix ? Je suis preneur de tout conseils sur le sujet, qu'est ce qui s'est passé et comment s'en sortit proprement si ça recommence ? merci. Hervé

Bonsoir à tous ! Alors voilà comme un bêta j'ai crée un groupe " Famille " pour partager mes photos, et j'ai seulement voulu donner l'accès à Synology Photos, alors j'ai refusé l'accès pour tout sauf Synology Photos... sauf que je me suis mis dans le groupe Famille également et du coup je n'ai plus accès à DSM 😅 Comme j'ai DSM 7 tout fraichement installé, il y a peut-être un bug car j'ai réinitialisé ( deux essais ) mon NAS avec le trombone pendant 4 secondes, j'ai entendu le bip, mon NAS a remis le port 5000 etc donc cela a marché, mais lorsque je vais sur Synology Web Assistant, il ne me propose pas de recréer un mot de passe.. du coup si je met celui que j'avais, cela marche mais j'ai toujours l'accès refusé.. bug ? En tout cas j'ai un accès en SSH depuis mon iPhone, alors si vous saviez ce que je peux modifier pour donner l'autorisation, ça serait super ! Merci à vous ! ÉDIT: il me semble que c'est dû à cause de l'option "Conserver le mot de passe admin actuel inchangé" que j'avais cochée, me semble-t-il.

Bonjour tout le monde, J'ai fait une boulette en me connectant en SSH sur mon NAS Synology, j'ai étais amené à faire un sudo -i du coup j'ai plus accès a mes dossiers partagés avait vous une idée de la commande que je dois utiliser pour que mes utilisateurs reprennent leurs droits ? Merci d'avance pour vos retours

J'ai lu quelques post et je me suis rendu compte que le script que j'ai écrit la semaine dernière était très utile à beaucoup. Le script a été mis en place sur Deux Syno distant, derrière deux FREEBOX en dégroupé (IP publique fixe). Je n'avais qu'un accès distant aux deux syno, via SSH, Web et FTP. Voici un peu la démarche. 1) je sépare le disque de travail du disque de sauvegarde. J'appelerai HOME celui sur lequel je crée une sauvegarde, et BUREAU celui qui doit être sauvegardé. 2) chaque samedi à 1h00 je lance la sauvegarde (CRONTAB) 3) je crée un fichier log sur lequel j'écris les infos 4) je lance rsync entre les dossiers 5) j'envoie un mail au final quand ça a fonctionné (ou pas fonctionné) 1 _ ACCES SSH il vous faut un accès SSH sur les deux Syno. La démarche est simple : fixer via le routeur l'adresse du Syno, la sortir de la plage DHCP, router les ports 5000, 21 et 22 vers le Syno. Des deux côtés 2_ MISE EN PLACE DES CLEFS PUBLIQUES/PRIVEE Cette partie est nécessaire pour que la sauvegarde soit entièrement automatique. En effet, dans un script, lorsqu'on se connecte à un SSH, il demande TOUJOURS le mot de passe. Du coup. VIA SSH Sur le disque BUREAU, je lance la commande : ssh-keygen -t dsa je récupère ainsi, dans le dossier /root/.ssh une cle privee et une clef publique. ( id_dsa et id_dsa.pub) J'envoie alors la clef publique à HOME (id_dsa.pub) j'inclue ce fichier dans authorized_keys du coup, tentez : connectez vous sur BUREAU en SSH. Lancez la commande ssh root@IP_DU_HOME .... il devrait accepter sans demander de mot de passe. Tant que cette partie ne marche pas, je vous conseille de chercher encore un peu. Il existe pas mal de tutos. 3_NAIL (pour ceux qui veulent envoyer un mail à la fin) installez nail en utilisant ipkg install nail si ipkg n'est pas installé, il existe un excellent tuto de fredo dans /OPT/etc/nail.rc ajoutez : smtp= votresmtp. 4_mise en place du script voici, il n'y a plus qu'à écrire le script. j'ai mis les commentaire après les # Voici le mien : #!/opt/bin/bash touch log_$(date '+%d-%m-%Y') #création d'un fichier LOG qui permettra d'envoyer le résultat echo "Debut $(date '+%d-%m-%Y')de la sauvegarde" >> log_$(date '+%d-%m-%Y') # message au début du fichier echo "du dossier PUBLIC vers le disque dur HOME" >> log_$(date '+%d-%m-%Y') # idem echo "$(date '+%d-%m-%Y') vers $(date '+%H : %M') > demarrage ..." >> log_$(date '+%d-%m-%Y') #idem rsync --delete -az /volume1/public/testcopy -e ssh root@IP_DU_DISQUE_HOME:/volume1/public/ # la commande ultime ! la ligne suivante vérifie le résultat et ajoute à mon fichier log le résultat if [ $? -eq 0 ] ; then echo "$(date '+%d-%m-%Y') vers $(date '+%H : %M') > sauvegarde reussie ! du disque BUREAU" >> log_$(date '+%d-%m-%Y') else echo "$(date '+%d-%m-%Y')> sauvegarde problematique du disque BUREAU ..." >> log_$(date '+%d-%m-%Y') fi echo " ----- " >> log_$(date '+%d-%m-%Y') nail -s "Sauvegarde terminee" sylvain.germe@gmail.com < log_$(date '+%d-%m-%Y') #j'envoie le fichier log rm -f /volume1/.rsync/log_$(date '+%d-%m-%Y') # je n'ai plus besoin du fichier log Je place ce script dans un dossier que je définis . Pour moi je l'ai mis dans /volume1/@scripts. 5_mise en place du crontab modifier le fichier /etc/crontab il existe également plein de tutos là dessus. NB : pensez à relancer le crontab après modifs !!!! Je n'ai pas beaucoup détaillé, mais si besoin, dites le moi

Bonjour à tous, Voila mon problème, me connectant à mon serveur synology nas rs408 (sous le DSM 3.2 Officiel), en ssh. J'essaye tant bien que mal à faire tourner certain script PHP, utilisant la class PDO pour les connexions à la base de donnée MySQL. Le problème est que à la commande: php -f monfichier.php j'ai l'erreur PHP Fatal error: Class 'PDO' not found in ... Jusque la le problème est comprehensible, mais je ne vois pas comment installer php_pdo .... Même en cherchant sur Google, je ne trouve aucune réponse, tout les topics qui peuvent parler de ce sujet dates de 2008 ... J'espère que vous pourrez m'aider à résoudre ce problème. Merci d'avance

Bonjour tout le monde, Après moultes recherches sur le Web je n'ai absolument rien trouvé comme piste sur comment installer le gestionnaire de paquet YUM J'ai réussi à installer il y a quelque temps le gestionnaire de paquet IPKG mais maintenant j'aurais également besoin de YUM. Merci d'avance pour vos réponses. Synology DS111

Bonjour! J'ai un petit souci depuis que je suis passé au DSM 3.2 . J'arrive à me connecter en root , mais dès que j'essaie d'acceder à un dossier il me met "permission denied" login as: admin admin@192.168.0.11's password: BusyBox v1.16.1 (2011-09-04 02:18:34 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. DS-211J> /usr/ -sh: /usr/: Permission denied J'ai beau chercher sur google la reponse en vain, j'ai essayé d'éditer le config.ssh, rien n'y fait Quelq'un a t'il eu le meme probleme ? Merci