Forum Linux.debian/ubuntu sécuriser user dédié pour tunnel ssh

Posté par  . Licence CC By‑SA.
0
24
sept.
2016

Salut la communauté.

Je souhaiterais restreindre au maximum les privilèges d'un user côté serveur : en gros il ne doit que pouvoir recevoir des tunnels de données à acheminé vers 127.0.0.1:port comme dans ce tuto. Je souhaiterais qu'il ne puisse pas faire un "ls /" ni autre commande, ni effectuer de montage sftp/sshfs.

distro : xubuntu

Merci d'avance pour votre aide :)

  • # Quelques questions

    Posté par  (site web personnel) . Évalué à 2.

    Bonjour,

    pourquoi avoir choisi Xubuntu? pour un serveur, il n'y a généralement pas besoin d'un "bureau".

    Est ce que l'utilisateur à la possibilité d'accéder physiquement à la machine?

    Ensuite, je ne vois pas le lien entre ta demande et le tutoriel en question.

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Quelques questions

      Posté par  . Évalué à 1. Dernière modification le 24 septembre 2016 à 14:32.

      pourquoi avoir choisi Xubuntu? pour un serveur, il n'y a généralement pas besoin d'un "bureau".

      Disposer d'une interface a quelques avantages, sans oublier que le serveur sert aussi de télé :) Xubuntu intègre aussi beaucoup de drivers très utile pour les ordinosaures, drivers que Debian n'intègre pas par défaut :)

      Est ce que l'utilisateur à la possibilité d'accéder physiquement à la machine?

      Non, c'est un user dédié au proxy que je souhaite ré-utiliser sur X machines appartenant a X personnes tout en le protégeant contre une compromission d'un des clients.

      Ensuite, je ne vois pas le lien entre ta demande et le tutoriel en question.

      c'est juste pour montrer le contexte (je souhaite sécuriser deux users: un qui est dédié exclusivement a tunneler des connexions de clients vers le owncloud (uniquement vers 127.0.0.1), et un dédié exclusivement au montage SSHFS comme ici pour ranger les fichiers de mes webservices sur mon raid :) )

      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

  • # chroot

    Posté par  (site web personnel) . Évalué à 2.

    Tout est dans le titre

    Tutos à la pelle sur le web.

    Système - Réseau - Sécurité Open Source

    • [^] # Re: chroot

      Posté par  . Évalué à 1.

      Oui j'ai déjà tenté d'en suivre plusieurs mais je me tape un "packet_write_wait: Connection to 192.168.1.42 port 22: Broken pipe" à chaque fois

      Pour le moment j'ai

      sudo su

      cd /home/userNeedChroot/

      On crée les dossiers des requis
      mkdir bin dev lib lib/i386-linux-gnu lib/x86_64-linux-gnu lib64

      On copie Bash
      cp /bin/bash /home/userNeedChroot/bin/

      Lister les requis
      ldd /bin/bash

      exemple
      └─ # ▶ ldd /bin/bash
      linux-vdso.so.1 => (0x00007ffc33cf1000)
      libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fc810b11000)
      libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc81090d000)
      libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc810543000)
      /lib64/ld-linux-x86-64.so.2 (0x000055647a454000)

      Trouver les requis
      find /lib/ -name libdl.so.2

      Copier les requis
      cp /lib/i386-linux-gnu/libtinfo.so.* ./lib/i386-linux-gnu/
      cp /lib/x86_64-linux-gnu/libtinfo.so.* ./lib/x86_64-linux-gnu/
      cp /lib/i386-linux-gnu/libdl.so.* ./lib/i386-linux-gnu/
      cp /lib/x86_64-linux-gnu/libdl.so.* ./lib/x86_64-linux-gnu/
      cp /lib/i386-linux-gnu/libc.so.* ./lib/i386-linux-gnu/
      cp /lib/x86_64-linux-gnu/libc.so.* ./lib/x86_64-linux-gnu/
      cp /lib64/ld-linux-x86-64.so.* ./lib64/

      Note : pas moyen de trouver linux-vdso.so.1

      Accorder les bons droits et propriétaires
      chown userNeedChroot:root -R ./*
      chmod 770 -R ./*

      Ajouter dans /etc/ssh/ sshd_config

      Match user userDedieSSH
      PasswordAuthentication no
      ChrootDirectory /home/%u

      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

  • # /bin/false

    Posté par  . Évalué à 5.

    Si le but est uniquement de pouvoir établir des tunnels (avec -L ou -R) alors il n'y a même pas besoin de pouvoir exécuter des commandes locales, tu peux donc mettre le shell de l'utilisateur à /bin/false et exécuter ssh avec l'option -N.

    Si tu veux pouvoir exécuter quand même quelques commandes, il existe des shell restreints que tu peux configurer pour n'accepter que quelques commandes, éventuellement avec seulement quelques options.

    • [^] # Re: /bin/false

      Posté par  . Évalué à 1. Dernière modification le 24 septembre 2016 à 15:51.

      Wow @wismerhill ça fonctionne exactement comme je le souhaitais et sans faire des tonnes de modifications obscures !
      Merci merci merci !

      la commande :
      sudo usermod -s /bin/false jeSuisUnUser

      PS: tu sais si on peut aller jusqu'à restreindre les tunnels vers une seule IP (127.0.0.1 dans le cas présent)?

      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

      • [^] # Re: /bin/false

        Posté par  . Évalué à 1. Dernière modification le 24 septembre 2016 à 16:00.

        Note : comment je fais pour l'annuler? (je pense (need verification) que cette méthode bloque l'ajout de nouvelle clés et doit donc être remis à la valeur par défaut avant d'ajouter un client)

        usermod -s /bin/login jeSuisUnUser renvoie "-login : fonctionnement impossible sans être réellement le superutilisateur" lors de la tentative de connexion via ssh

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: /bin/false

          Posté par  . Évalué à 2.

          Ça n'a rien à voir, les clés doivent simplement être ajoutées dans le fichier ~/.ssh/authorized_keys (mais si tu comptais sur ton utilisateur pour pouvoir les ajouter lui-même, effectivement il ne sait plus le faire).

          • [^] # Re: /bin/false

            Posté par  . Évalué à 1.

            Oui je parlais de l'export de clés des clients avec la commande
            ssh-copy-id -i ~/.ssh/id_ed25519 jeSuisUnUser@adresseServerSSH

            Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

      • [^] # Re: /bin/false

        Posté par  . Évalué à 3.

        Dans la configuration d'openssh server, je vois le paramètre AllowTcpForwarding dont l'option local devrait faire ce que tu veux (à tester, je ne suis pas sur d'avoir bien compris).
        Il y a aussi le paramètre PermitOpen qui semble intéressant.

        Tu peux combiner ça avec le paramètre Match pour ne mettre ces options que pour un utilisateur en particulier (et peut-être ajouter encore d'autres restrictions).

        • [^] # Re: /bin/false

          Posté par  . Évalué à 1.

          "AllowTcpForwarding local" semble valide mais ne m'empêche pas de contacter un autre serveur.
          Par contre "PermitOpen 127.0.0.1:*" fait se que je demande

          Si tu sais juste me renseigner comment revenir en arrière après mon "sudo usermod -s /bin/false jeSuisUnUser", j'en aurai terminé avec cet user grâce tes infos gros merci @wismerhill :)

          Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

          • [^] # Re: /bin/false

            Posté par  . Évalué à 3.

            Si tu sais juste me renseigner comment revenir en arrière après mon "sudo usermod -s /bin/false jeSuisUnUser", j'en aurai terminé avec cet user grâce tes infos gros merci @wismerhill :)

            Tu te connecte en root (ou un user pouvant exécuter sudo) et tu remet un autre shell à ton user.

            Ensuite, tu peux laisser un shell normal au user pour permettre les connexion locales, tu peux utiliser le paramètre ForceCommand d'openssh server avec un shell limité comme rush ou rssh (j'ai personnellement eu de bon résultats avec rush) que tu configure pour autoriser les quelques commandes souhaitées (comme celles exécutées par ssh-copy-id).

            Attention, si configure ton serveur ssh comme ça, fais bien attention à ce que ce ForceCommand ne soit actif que pour l'utilisateur souhaité, sinon tu va bloquer tout le monde.

            • [^] # Re: /bin/false

              Posté par  . Évalué à 1.

              ce rush la? J'avais déjà tenté une fois avec rssh mais ça avait mal terminé ^ ^

              Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

              • [^] # Re: /bin/false

                Posté par  . Évalué à 3.

                Non, celui-là
                http://puszcza.gnu.org.ua/software/rush/
                il y a un paquet debian du même nom, donc probablement pour ubuntu aussi.
                À l'époque où j'en avais eu l'usage je l'avais trouvé plus pratique que rssh (mais je ne me souviens plus pourquoi).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.