Le ssh pour tous les utilisateurs sur les NAS Synology

Deuxième article sur mon NAS Synology DS411j, cette fois ci simplement pour passer outre une limitation mise en place par Synology : l’accès en ssh est réservé à l’utilisateur root (ou admin).

Cette limitation a sans doute du être mise en place dans un souci de simplicité pour le grand public, limitant ainsi l’accès au propriétaire du NAS, qui est supposé savoir ce qu’il fait s’il a activé l’accès ssh.

Cependant, cette limitation pose 2 problèmes :
– Tout d’abord, il est déconseillé d’activer l’accès ssh en root à une machine GNU/Linux, pour des raisons de sécurité. Cette limitation va complètement à l’encontre de ce principe élémentaire.
– En plus, dans l’optique de l’utilisation de rsync sur le protocole ssh, ce que je veux mettre en place pour mon futur système de sauvegarde (ça fera l’objet d’un autre article), il faut absolument que chaque utilisateur ait un accès ssh au NAS

La procédure n’est pas très compliquée, mais il faut faire attention à ce que l’on fait car on peut très vite tout casser (et ne plus pouvoir se connecter en ssh du tout par exemple…).

1) Créer un utilisateur ordinaire depuis l’interface web du NAS.

Appelons le julien dans la suite. Je l’ai configuré pour appartenir au groupe « users ».

2) Se connecter en root au NAS.

Il faut bien sûr activer le service ssh au préalable, par l’interface web du NAS. Je conseille d’également activer le telnet pour la durée des manipulations décrites ici, cela permettra un accès de secours au NAS si on casse le SSH…
Pour se connecter en ssh, c’est comme toujours, depuis un terminal Linux :

ssh root@ip.de.votre.nas

Le mot de passe est le même que celui de l’administrateur dans l’interface web.

3) Créer le profil de l’utilisateur.

Je conseille la création d’un dossier /volume1/users/ avec dans ce dossier un dossier par utilisateur « standard », qui permettra de mettre tout ce qui est administration des utilisateurs dans ce dossier et non pas dans /volume1/homes/ car ce dossier sera accessible directement par le navigateur de fichier de l’interface web (FileStation). Les fichiers « d’administration » de l’utilisateur (le .profile en l’occurrence) y seront visibles. Cependant, si vous préférez, vous pouvez vous passer de ce nouveau dossier et utiliser /volume1/homes/.
Ensuite, il faut créer (dans le dossier /volume1/users/julien donc) le fichier .profile de julien, sur la base de celui de root.
C’est parti :

mkdir /volume1/users
mkdir /volume1/users/julien
cp /root/.profile /volume1/users/julien
chown -R julien:users /volume1/users/julien/
vi /volume1/users/julien/.profile

Changer la ligne suivante :

HOME=/root

Par celle-ci :

HOME=/volume1/homes/julien

4) Adapter le fichier /etc/passwd.

Sauvegarder le fichier /etc/passwd original et adapter sa copie :

cp /etc/passwd /etc/passwd.sauv
vi /etc/passwd

Modifier la ligne suivante (elle peut varier légèrement chez vous) :

julien:x:1026:100::/var/services/homes/julien:/sbin/nologin

Pour cette ligne là :

julien:x:1026:100::/volume1/users/julien:/bin/sh

Le dossier « /volume1/users/julien » indique le dossier dans lequel se placer quand l’utilisateur se connecte. C’est aussi dans ce dossier que sera cherché le fichier .profile, pensez donc à adapter ce dossier si vous avez mis votre .profile ailleurs.

5.a) Configurer la lecture du .profile du nouvel utilisateur

Ici, il y a 2 cas de figures.

– Vous avez choisi de n’avoir qu’un seul dossier pour l’utilisateur (/volume1/homes/julien à priori) et le fait de voir le fichier .profile trainer dans l’interface de FileStation ne vous gène pas : passez à l’étape 6).

– Vous avez choisi de suivre ma configuration, avec un dossier « technique » (/volume1/users/julien), dans lequel vous avez mis le .profile, et un dossier « utilisateur » (/volume1/homes/julien) : il faut bidouiller un peu pour s’en sortir. Si vous voulez juste appliquer ce que je dis sans trop comprendre le problème, passez au 5.b).

Sinon je vous explique le problème : il faut que le fichier .profile ne soit pas dans le dossier de connexion de l’utilisateur (configuré dans le /etc/passwd). En effet, FileStation utilise le dossier configuré dans /etc/passwd comme dossier « racine » pour l’utilisateur et on fini par tourner en rond :

– soit on a /volume1/users/julien/ dans /etc/passwd et lors de la connexion en ssh tout se passe bien, le fichier .profile est pris en compte mais dans FileStation on se retrouve aussi dans ce dossier /volume1/users/julien/ alors qu’on voulait être dans /volume1/homes/julien/ (et en plus on voit le fichier .profile du coup ^^ )

– soit on a /volume1/homes/julien/ dans /etc/passwd et on est au bon endroit dans FileStation, mais à la connexion en ssh le .profile sera cherché dans /volume1/homes/julien/, ne sera pas trouvé, et le profile par défaut sera appliqué. On sera bien connecté dans /volume1/homes/julien/ mais la variable $HOME vaudra par exemple « /root », ce qui fait que lorsqu’on passe la commande suivante, on n’a pas vraiment le résultat espéré :

julien@linux:~$ ssh julien@ip.de.votre.nas
julien@ip.de.votre.nas\'s password:


BusyBox v1.16.1 (2010-10-23 01:00:23 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

Discovery> pwd
/volume1/homes/julien
Discovery> cd
Discovery> pwd
/root
Discovery>

Inattendu hein? :p
L’astuce consiste en fait à modifier le fichier de profile par défaut : /etc/profile. J’explique cela dans le paragraphe suivant.

5.b) Modifier le fichier /etc/profile

Au final, nous voulons donc avoir le dossier /volume1/homes/julien/ comme dossier de connexion par défaut, aussi bien pour le ssh que pour FileStation, tout en prenant en compte le fichier de profile /volume1/users/julien/.profile.
Cela se fait en modifiant le fichier /etc/profile de la manière suivante (ajout des 3 dernières lignes) :

#/etc/profile: system-wide .profile file for ash.
PATH="$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin"
umask 022
#This fixes the backspace when telnetting in.
#if [ "$TERM" != "linux" ]; then
#        stty erase
#fi
PGDATA=/var/service/pgsql
export PATH PGDATA
HOME=/root
export HOME
TERM=${TERM:-cons25}
export TERM
PAGER=more
export PAGER
PS1="`hostname`> "
alias dir="ls -al"
alias ll="ls -la"
ulimit -c unlimited
PATH=/opt/bin:/opt/sbin:$PATH
if [ -f "/volume1/users/$USER/.profile" ]; then
. "/volume1/users/$USER/.profile"
fi

6) Vérifier la bonne configuration de l’utilisateur.

Exécuter les commandes suivantes :

NAS> whoami
root
NAS> cd /
NAS> pwd
/
NAS> su - julien


BusyBox v1.16.1 (2010-10-23 01:00:23 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

NAS> whoami
julien
NAS> pwd
/volume1/users/julien
NAS> echo $HOME
/volume1/homes/julien
NAS> cd
NAS> pwd
/volume1/homes/julien
NAS> exit
NAS> pwd
/
NAS>

Le résultat de toutes ces commandes est très important. La seule chose qui doit changer chez vous est « julien ». Vous remarquerez que comme le dossier de connexion configuré (/volume1/users/julien) est différent de la valeur attribuée à la variable $HOME à l’étape 3 (/volume1/homes/julien), la commande cd ne nous met pas dans notre répertoire de connexion, mais bien dans notre home. Vous pouvez bien sur mettre un autre dossier dans $HOME à l’étape 3 (comme le dossier /volume1/users/julien, je ne l’ai pas fait parce que je veux garder ce dossier strictement administratif).

7) Configurer sshd.

Commencer par sauvegarder la configuration originale :

cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.sauv

Puis adapter la configuration à votre convenance. Les points essentiels sont les suivants :
– Changer la ligne « #Protocol 2,1″ pour « Protocol 2″ (désactivation de ssh v1) si ce n’est pas fait
– Changer la ligne « #PermitRootLogin yes » pour « PermitRootLogin no » pour interdire la connexion en ssh de root (conseillé d’un point de vue sécurité, je ne l’ai pas fait pour des raisons pratiques pour le moment)

Vous pouvez également adapter les 2 lignes suivantes en fonction de ce qui vous parait raisonnable d’un point de vue sécurité :
– « #LoginGraceTime 2m » (par défaut, 2 minutes) : Le serveur se déconnecte après ce délai si l’utilisateur ne s’est pas connecté. Si la valeur est 0, il n’y a aucune limite de temps.
– « #MaxAuthTries 6″ (par défaut, 6 essais) : Nombre maximum d’essais de mot de passe pour la connexion.
– Pour les autre options : « man ssh » dans google =)

8) Redémarrer le démon sshd.

Avant de redémarrer sshd, je vous conseille encore une fois d’activer (provisoirement si vous voulez) le telnet sur votre NAS.
Le démon sshd peut être redémarré de plusieurs manières. La plus simple est de désactiver puis de réactiver le service ssh dans l’interface web. Déconnectez vous avant de faire ça. Sinon, vous pouvez utiliser la commande suivante :

/usr/syno/etc.defaults/rc.d/S95sshd.sh

Ou alors, plus brutal, vous pouvez éteindre et rallumer votre NAS.

9) Tester que ça fonctionne!

Se connecter en tant que julien pour voir si ça fonctionne, depuis votre poste Linux :

ssh julien@ip.de.votre.nas

Si vous avez bien tout suivi, ça devrait fonctionner. Sinon, vous pouvez toujours tenter de me poser une question, je ferai ce que je peux pour vous aider…

Attention

J’ai vu sur le net que le fait de modifier les caractéristique des utilisateurs pour lesquels on a activé le ssh par l’interface web remettait la configuration par défaut et que du coup le ssh ne fonctionnait plus. Si c’est le cas, il vous suffit de ré-appliquer la procédure ci-dessus, ça devrait fonctionner. Au pire, faites les manips en vous connectant via telnet en root. Cela dit, je n’ai pas encore essayé ceci. Synology a peut-être corrigé ce problème maintenant.

Sources utilisées pour cet article

http://bernhard.hensler.net/blog/synology-enable-ssh-user-login-other-than-root/
http://www.delafond.org/traducmanfr/man/man1/ssh.1.html
http://unixhelp.ed.ac.uk/CGI/man-cgi?ssh+1

46 réponses à to “Le ssh pour tous les utilisateurs sur les NAS Synology”

  • Julien:

    Merci pour ce tuto très bien expliqué !
    Ca fonctionne bien.

  • gwen:

    Arf, rien à faire, ça ne marche pas pour moi.
    Pourtant tout semble bien configuré, c’est assez frustant. Je vais finir par devoir installer le package Openssh de ipkg… :-(
    Vous arrivez vraiment à vous connecter sans root avec clé ? ;-)

  • Julien:

    j’arrive à me connecter, par contre je n’ai pas de demande d’authenticité de la clef, il le serveur me demande juste un mot de passe.

    • gwen:

      Donc ça ne marche pas !
      Le principe de l’authentification par clé, c’est justement de ne pas avoir à rentrer de mot de passe ! :-)

      • kouinkouin:

        Pour se connecter (user différent de root) avec une clé, il faut aller dans « Sauvegarde et réplication » > « Services de sauvegarde » > Cocher « Activer le service de sauvegarde réseau ».

        J’ai galéré pour le trouvé, et j’avais espoir de le trouvé sur ce post, donc j’espère que ça servira à quelqu’un d’autre :) .

  • Jidey:

    @gwen : la procédure que j’ai écrit ici permet de se connecter en ssh, mais avec un mot de passe (celui de l’utilisateur). Pour se connecter avec un clé il y a une manip en plus à faire : regarde la doc Ubuntu à ce sujet, elle est bien faite http://doc.ubuntu-fr.org/ssh#authentification_par_un_systeme_de_cles_publiqueprive
    Je l’ai mis en place chez moi, ça fonctionne. Si tu as un souci, n’hésite pas.

    • gwen:

      Merci beaucoup, ça marche ! J’avais tout essayé, ce qu’il me manquait c’était un chmod 755 sur mon $HOME. IL était en 777.
      Va comprendre, mais bon, ça marche.
      Merci beaucoup à toi ! Good job ! :-)

      • Jidey:

        Là comme ça je vois pas pourquoi ça marchait pas en 777 et ça marche en 755, mais dans tous les cas avoir son home en 777 n’est pas une super idée ;)
        Content que tu ais réussi!
        @+

        • toto:

          C’est tout simplement une question de sécurité, positionner du 777 c’est une hérésie absolue sous Linux/Unix donc pas mal de conf font un blocage dessus et ne fonctionne pas quand une telle faille est positionnée.

  • blind_killer:

    J’allais demander de l’aide mais j’ai trouvé la solution alors je la transmets, au cas où ça puisse aider quelqu’un:

    J’ai rencontré un problème pour passer de mon utilisateur en root (une fois connecté en ssh) avec la commande su…
    En fait, il y’avait un problème de SUID et donc il a fallait faire:
    chmod 4777 /bin/su

    Bien évidemment en root (si certains auront comme moi désactivé la connexion ssh en root il faut passer par telnet…)

    Puis en faisant « su – » et en entrant le mot de passe root tout fonctionne parfaitement :-)

    • Jidey:

      Merci de ton retour!
      Je n’avais pas encore rencontré ce problème, en général je me connecte en root (bouuuh pas bien).
      Je viens d’essayer, j’ai rencontré le même problème, j’ai fait ton chmod et tout fonctionne =)

    • gcado:

      excellent ! merci pour l’astuce, effectiviement j’ava

  • Bonsoir,
    Merci pour ce billet, tout s’est bien déroulé.
    Je vais parcourir le reste du blog pour voir si des articles m’intéresse (notemment rsync)

    Librement,
    Sylvain

  • Christophe:

    Merci pour ce tutorial.
    J’aimerais ajouter ce détail: avant d’interdire les connexions en ssh de root, il vaut mieux se connecter avec un autre utilisateur, et vérifier qu’il est possible d’utiliser su pour passer à l’utilisateur root. Il semble que souvent, les permissions de /bin/busybox sont incorrectes, ce qui empêche d’utiliser su. Il faut les modifier avec:
    chmod 4755 /bin/busybox
    Autrement, on risque de se retrouver dans l’impossibilité de modifier sa configuration, puisqu’il n’est plus possible de se connecter en tant que root par ssh ou par su…

  • Boreux:

    Bonjour

    Super clair tuto, je vais tester çà, mais j’ai également trouvé ceci, plus court, sur la toile :

    Activer l’accès SSH pour tous les utilisateurs :

    1.Se connecter en SSH ou Telnet sur le NAS
    2.Editer le fichier : /etc/passwd
    3.Changer la ligne correspondant à l’utilisateur de /sbin/nologin à /bin/ash
    4.Redémarrer le service SSH :
    cd /usr/syno/etc.defaults/rc.d/ ./S95sshd.sh restart &

    Votre avis d’expert ?

    • Jidey:

      Bonjour,

      C’est un condensé de ce que je propose.
      Dans mon cas, je présente aussi la personnalisation du .profile des users pour le rendre plus habituel par rapport à un linux « standard », et l’utilisation d’un home personnalisé.
      Pour une simple connexion, sans besoin d’un home personnalisé par exemple, la méthode que vous présentez suffit, cela permettra effectivement aux utilisateurs en question de se connecter en ssh.

      • Boreux:

        Merci pour cette info… Est-ce que l’utilisateur en question sera bloqué dans son environnement ?

        Je m’explique :
        – j’active le « home » utilisateur, donc je retrouve bien un /homes/user1, /homes/user2, etc
        – je suis votre tuto pour ssh

        Est-ce que user1 sera bloqué dans son home (/homes/user1) ou poura-t-il redecendre dans /homes, /root, etc ??? J’aimerais qu’il n’ait pas accès aux autres share en fait…

        • Jidey:

          Ca dépend des permissions des différents dossiers.
          La plupart des dossiers sont par défaut accessibles en lecture par tout le monde, donc oui, ils pourront naviguer dans la plupart des dossiers du NAS. La liste des dossiers où ils pourront accéder en écriture est beaucoup plus réduite par contre.

          Si tu veux juste les empêcher de voir les homes des autres users, tu peux configurer les droits des dossiers /homes/userX à 700. Toucher aux droits des dossiers « système » du NAS n’est par contre pas trop recommandé.

          Si tu veux carrément les bloquer dans leur home respectif, tu peux te tourner vers un chroot, mais c’est plus compliqué. Je n’ai pas testé un chroot ssh sur le NAS.

          • Boreux:

            En fait j’avais même mis des DENY sur les répertoires (depuis la gestion des accès dans l’interface web), mais çà ne changeait rien… ceci dit c’était avec un unser particulier nommé RSYNC (suivant leur doc), qui a peut etre plus de droits… J’essaye avec un utilisateur standard et vous tiens au courant ;)

          • Boreux:

            Bonjour, je confirme que çà marche… Mais que les droits que j’ai donné à l’utilisateur ne sont pas respectés sous SSH… j’arrive par défaut sous /homes/mon_user, mais si je fais cd .. j’ai accès à tous les shares (malgré que j’ai mis des DENY) Une idée de comment limiter l’accès à ce homes uniquement ??

          • Bonjour. Bravo pour ce tuto réellement enrichissant & instructif !

            Mon but est d’avoir un accès SSH sur le Syno pour faire du rsync.

            J’ai donc suivi votre tutoriel (méthode 1 avec accès à /volume1/homes/toto) qui fonctionne parfaitement à ce ceci prêt que mon user peut se balader dans toute l’arbo du Syno. Génant. J’ai donc voulu jouer avec CHROOT comme vous l’indiquez. J’ai donc modifié le /etc/ssh/sshd_config en y ajoutant ceci à la fin :

            Match user toto
            ChrootDirectory /volume1/homes/toto
            ForceCommand internal-sftp
            X11Forwarding no
            AllowTcpForwarding no

            Malheureusement, impossible de me connecter. Si je retire ces 5 lignes, je me connecte à nouveau. Donc y comme un problème avec. J’ai bien tenté de retirer alternativement et séparément les 3 dernières, sans plus de succès.

            Par ailleurs, j’ai trouvé ceci : http://www.justasysadmin.net/fr/practical/chroot-ssh-rsync/

            La solution me semble lourde. Est-elle selon vous nécessaire ?

            Si vous aviez une idée, je suis preneur. D’avance, merci !

  • Jidey:

    Relis ma réponse.
    Empêcher la consultation des dossiers racines va être compliqué, renseigne toi sur le chroot en ssh.

    Si tu veux juste empêcher l’accès aux /volume1/homes/userX à tous les autres users que userX il faut passer les droits à 700 sur chaque répertoire /volume1/homes/userX.
    Connecte toi en ssh en root et fait un « ls -l /volume1/homes/ » et poste le retour de la commande ici si tu veux que je vérifie que les droits sont OK.

  • Foaly:

    Merci pour ce tuto!

  • shebang:

    Petite remarque sur ce tuto : depuis les dernières MAJ du DSM, il y a un bug qui empêche de se logger via ssh pour un utilisateur lorsque le shell /opt/bin/bash est utilisé. Un possibilité est de laisser le shell pointé sur /bin/sh et de mettre dans le .profile de l’utilisateur la commande suivante : « exec /opt/bin/bash –rcfile .bash_profile ». Dans mon cas, le .bash_profile n’était pas chargé directement, je l’ai donc rajouté. Reste ensuite à mettre vos alias dans le .bash_profile :)

  • Joel:

    Je pense avoir suivi scrupuleusement ce tuto mais j’observe néanmoins que le répertoire home qui apparait dans File Station (au même niveau que music, photo etc…) est le répertoire home qui contient le fichier .profile.
    Or je pensais justemet eviter cela en suivant les recommandation du tuto.

    Je tiens à préciser que j’obtiens le même résultat que celui qui est présenté dans le paragraphe 6.

    Voici le contenu de mon fichier /etc/profile :

    #/etc/profile: system-wide .profile file for ash.
    PATH= »$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin »
    umask 022
    #This fixes the backspace when telnetting in.
    #if [ « $TERM » != « linux » ]; then
    # stty erase
    #fi
    PGDATA=/var/service/pgsql
    export PATH PGDATA
    HOME=/root
    export HOME
    TERM=${TERM:-cons25}
    export TERM
    PAGER=more
    export PAGER
    PS1= »`hostname`>  »
    alias dir= »ls -al »
    alias ll= »ls -la »
    ulimit -c unlimited
    PATH=/opt/bin:/opt/sbin:$PATH
    if [ -f « /volume1/users/$USER/.profile » ]; then
    . « /volume1/users/$USER/.profile »
    fi

    Voici le contenu du fichier /volume1/users/$USER/.profile

    umask 022

    #PATH=/opt/bin:/opt/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin
    #export PATH

    #This fixes the backspace when telnetting in.
    #if [ « $TERM » != « linux » ]; then
    # stty erase
    #fi

    HOME=/volume1/homes/joel
    export HOME

    TERM=${TERM:-cons25}
    export TERM

    PAGER=more
    export PAGER

    PS1= »`hostname`>  »

    alias dir= »ls -al »
    alias ll= »ls -la »

    Les reboot n’y font rien.
    Merci pour votre aide.

    • Joel:

      Je precise que je suis avec le DSM 4.2 Beta.

    • Sébastien:

      Je suis tombé sur le même problème que toi.
      Il y a peut-être une régression depuis !?

      J’ai contourné le problème en laissant le répertoire en ‘homes’ dans /etc/passwd
      et en mettant la variable $HOME en ‘users’ dans le .profile.

      Du coup dans FileStation, je suis bien dans le répertoire ‘homes’.
      Et quand je me connecte en ssh, je suis bien dans le répertoire ‘users’ après avoir fait un cd.

      Mais pour me connecter en ssh sans mot de passe, je suis obligé de mettre le dossier .ssh dans le dossier ‘homes’ au lieu de celui que j’ai mis dans ‘users’
      Ce qui est bien mais pas top.

      J’ai changé le /etc/ssh/sshd_config en
      AuthorizedKeysFile $HOME/.ssh/authorized_keys

      Mais sans succès. Des idées ?

  • Jidey:

    Hello,

    Désolé pour le délais de réponse, très occupé en ce moment…

    Essayez ça dans /etc/profile :
    Enveler :
    if [ -f « /volume1/users/$USER/.profile » ]; then
    . « /volume1/users/$USER/.profile »
    fi

    Ajouter :
    if [ « $USER » == « julien » ]; then
    . /volume1/users/julien/.profile
    fi

    En remplaçant julien par votre user bien sur.
    A répéter pour tous les users concernés.

    • Sébastien:

      Cela ne change rien, le fichier « .profile » dans « users » était bien exécuté.

      Si j’ai bien compris, il faut mettre le chemin en « homes » dans /etc/passwd et pas le chemin en « users » comme spécifié à l’étape 4), si l’on veut être dans le bon répertoire pour FileStation.

  • Bao:

    Bonjour,

    Merci pour ce tuto ! Cela fonctionne parfaitement pour moi.
    Cependant j’aurais une question, comment autoriser le TCPForwarding pour tous les utilisateurs (Root – Non-Root) ?

    Actuellement, j’arrive a passer à travers le proxy de l’entreprise en me connectant en ssh avec un compte root, mais avec un utilisateur lambda cela ne fonctionne pas. Le forwarding n’a pas l’air de fonctionner.

  • adrien:

    Bonjour,
    il me semble avoir suivi à la lettre ce tuto mais voilà:

    – la connection en ssh avec mon utilisateur fonctionne
    – mais quand je me connecte, je me retouve à la racine:

    Could not chdir to home directory /var/services/homes/Usertest: No such file or directory

    whoami
    username

    pwd
    /

    – si je fais echo $HOME j’ai bien:

    /volume1/homes/username

    – et un simple « cd » m’envoie dans le home attendu, dans lequel j’aimerai bien que la connection ssh commence directement.

    Une idée ?

    Merci !!

    • adrien:

      pardon, dans ce cas ce serait :

      Could not chdir to home directory /var/services/homes/username: No such file or directory

    • adrien:

      C’est bon, pardon, je suis allé trop vite à l’étape 4 en modifiant seulement /bin/sh et pas le nom du dossier, dans lequel on tombe finalement en se connectant en ssh

  • marc:

    Bonjour,

    J’ai installé OpenERP 7 et j’ai un soucis avec une police manquante sur le synology (DejaVu).

    Je ne peux donc pas imprimer mes factures …. c’est embêtant.
    Comment faire pour installer cette police ?
    je ne suis pas très familier avec le ssh.

    Merci de vos conseils,

    Marc

  • Merci pour ce post bien détaillé.

    Dans mon cas, pour que « PermitRootLogin no » soit pris en compte, redémarrer le daemon n’a pas suffit : il a fallu que je redémarre entièrement le NAS. J’ai lu sur d’autres blogs/forums que certains ont eu le même comportement.

  • marsunivers:

    Bonjour,

    Bon travail !

    Pour ma part j’ai un souci.

    J’ai changé les droits des différents répertoires pour permettre à différentes personnes à enter sur mon Photo Station, sans forcement voir toutes les photos. Dans mon malheur j’ai due faire une action qui, dans le File Station, ne me permet de voir que mon répertoire home (autant qu’admin).

    Les actions que j’ai pu mener sont :

    Lire le fichier /etc/group qui entre autres, montre le groupe users tel que :

    « users:x:100: »

    J’ai ajouté « admin » à cette ligne, autant que root, mais mes droits n’ont pas changés :/

    Je suis dans les group admin, que je n’ai pas changé :

    « administrators:x:101:admin »

    La question est en fin de compte :

    Que pourrait provoquer ce manque de visibilité par l’accès web et par accès réseau (sous mac) ?

    Merci d’avance :)

    • marsunivers:

      Bonjour,

      En changeant d’outil d’accès (Le DSM Mobile), j’ai changé de point de vue.

      Je suis arrivé à la conclusion suivante : « les droit sur un serveur pour un utilisateur sont l’intersection des droits de tous les groupes dont il est membre ».

      Mon utilisateur admin, était membre de groupes à accès restreints ce qui a probablement due réduire mes droits de visualisation de certains dossiers comme : photo, vidéo,etc.

      Si d’autres commentaires peuvent confirmer ou affirmer, je suis preneur !

      Bonne continuation ;-)

  • Gilles:

    Bonjour

    D’abord merci pour ce tuto.

    Mon utilisateur est Gilles (il fait parti du groupe administrateurs)

    Tout fonctionne bien coté ssh Gilles peut se connecter (grace au tuto)
    Par contre par l’interface http du synology le dossier home de Gilles est:
    /volume1/users/Gilles je voie donc le fichier .profile et le dossier .ssh

    j’ai essayé de mettre dans /etc/profile
    if [ « $USER » == « Gilles » ]; then
    . /volume1/users/Gilles/.profile
    fi

    Mais toujours pareil, je n’arrive pas à ce que Gilles « arrive dans le dossier /volume1/homes/Gilles.
    Bien sur j’ai voulu faire comme Julien et faire un dossier configuration :)

    Pour info le DSM est en DSM 4.3-3810 Update 1 donc le dernier disponible.

    Merci d’avance
    Gilles

  • philippe:

    bjr

    j’ai un message apres chaque reboot,,,:auto-mount unable to mount all floders automatic…
    qq’un peu m’aider,,,j’avais suivi un tuto et avait deplacer un fichier,,,opt/optware un truc comme ca sur externe USB. mais je n’ai plus usb.
    je crois que ca viens de la!!! dsm5.0 update1 beta,,,,(bien, logo BD).
    cordialement.

  • Samuel:

    Super,
    merci beaucoup pour ta pédagogie. Non simplement ça marche mais en plus on comprend pourquoi faut faire tout ça (à peu prêt car je ne suis pas un as non plus).
    On y arrive juste en suivant le tuto et en consultant la notice de ce sacré VI très pratique mais éditeur un peu austère.
    Merci.

  • Adil welk:

    Merci pour moi ça marche impeccable.
    Mon environnement pour info : ds214+ et dsm5

  • Sam:

    Bonjour,

    avec le DSM 5 je me connecte sans souci en admin, mais j’ai un « permission denied » quand j’essaye de me connecter en tant qu’utilisateur. Comme mon matériel est récent et ton post original vieux de trois ans, pourrais-tu me confirmer que l’un est bien (toujours) la solution de l’autre ?

    Accessoirement, il n’y a pas de répertoire /homes dans mon volume1 les répertoires utilisateurs sont directement à la racine du volume. Je suppose que je dois adapter mes lignes de commande en conséquence ? /volume1/homes/leon_boumard de venant /volume1/leon_boumard ?

    Merci en tous cas pour l’article :-)

  • droopyjj:

    Bonjour,
    Voila, je cherche désespérément quelqu’un pour m’aider sur un probleme de permission (a priori) dans mon répertoire web de mon syno (710+)
    Je suis absolument novice en langage informatique (trop vieux maintenant pour apprendre)
    J’ai mis dans mon serveur un fichier meteo.php qui contient cela (contenu qui m’a été donné):
    current_condition->tmp. » degrés et les conditions sont « .$json->current_condition->condition. ». »;
    $replacetoday=str_replace( » « , »%20″,$today);
    file_put_contents(« /tmp/debuglapin »,$replacetoday);
    $url = « http://192.168.0.30/cgi-bin/tts?voice=alice&text= ».$replacetoday. »&nocache=1″;
    $lapin = file_get_contents(« $url »);
    ?>
    mais j’ai cette réponse:
    Warning: file_put_contents(): open_basedir restriction in effect. File(/tmp/debuglapin) is not within the allowed path(s): (/var/services/tmp:/etc.defaults:/usr/bin/php:/usr/syno/synoman:/etc:/var/run:/volume1/@tmp/php:/var/services/web:/var/services/photo:/var/services/blog:/var/services/homes) in /volume1/web/meteo.php on line 8 Warning: file_put_contents(/tmp/debuglapin): failed to open stream: Operation not permitted in /volume1/web/meteo.php on line 8
    Pouvez-vous m’aider ?
    Comme il semble que c’est un problème de « permission »….
    mon message est une bouteille à la mer et je suis désolé si cela n’est pas du tout approprié
    cdt

  • dartagnan:

    Merci pour ce petit tuto très pratique. Même s’il date de 2011, il reste valable.

    Je suis d’accord pour supprimer le login root en ssh. Mais ne serait-il pas possible d’autoriser le su – root en localhost? C’est peut-être un peu moins secure, mais toujours mieux que la conf d’origine non?

    Je te pose la question car je n’est pas trouvé comment faire…