(Français) Le ssh pour tous les utilisateurs sur les NAS Synology

Sorry, this entry is only available in Français.

46 Responses to “(Français) 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…