Sftp et Scp sans se logguer

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes : aucune
0
22
déc.
2002
Sécurité
S'il vous est comme moi, un jour, arrivé d'avoir besoin de laisser des utilisateurs déposer des fichiers sur une machine sans avoir autre chose que Ssh (scp et sftp). Vous vous êtes surement aussi demandé, si ces utilisateurs étaient sérieux et s'ils n'allaient pas se logguer directement (via ssh).

Pour faire bref, si vous souhaitez que vos utilisateurs ne puissent faire que du scp et du sftp, sans pouvoir se logguer (genre telnet pour ceux qui ne suivent pas). Je ne saurais trop que vous conseiller scponly. Il est sorti dans son habit de lumière en v3.5 le 16/12.

Son fonctionnement est assez simple, il remplace en fait le shell et ne laisse passer que les requetes de type sftp-server, scp et ls.

what it is:

"scponly" is an alternative 'shell' (of sorts) for system administrators who would like to provide access to remote users to both read and write local files without providing any remote execution priviledges. Functionally, it is best described as a wrapper to the "tried and true" ssh suite of applications.

A typical usage of scponly is in creating a semi-public account not unlike the concept of anonymous login for ftp. This allows an administrator to share files in the same way an anon ftp setup would, only employing all the protection that ssh provides. This is especially significant if you consider that ftp authentications traverse public networks in a plaintext format.

Instead of just a single anon user, scponly supports configuring potentially many users, each of which could could be set up to provide access to distinct directory trees. Aside from the installation details (see INSTALL), each of these users would have their default shell in /etc/passwd set to "/usr/local/sbin/scponly" (or wherever you choose to install it). This would mean users with this shell can neither login interactively or execute commands remotely. They can however, scp files in and out, governed by the usual unix file permissions.

Aller plus loin

  • # Re: Sftp et Scp sans se logguer

    Posté par  . Évalué à 3.

    ouais ben y a plus simple
    un accces normal
    et tu mets /bin/false comme shell par default pour l'user
    le mec pourra toujours essayer de se logger, il aura du mal :)

    ++
    • [^] # Re: Sftp et Scp sans se logguer

      Posté par  . Évalué à 8.

      oui mais non.

      Avec OpenSSH (dans la config standard en tout cas), t'es pas obligé d'avoir un shell pour pouvoir exécuter une commande distante.

      Donc imagine que t'as un bind4 troué sur ton serveur, un luser malintentioné peut très bien faire un ssh luser@serveur "/usr/sbin/named ArgDeLaMortQuiTueSec" et hop, tu te retrouve r00ted.
      • [^] # Re: Sftp et Scp sans se logguer

        Posté par  . Évalué à 2.

        Non, on ne peut pas faire fonctionner scp lorsque l'utilisateur a comme shell /bin/false ou autre. Si je ne me trompe pas, scp execute scp à distance en utilisant ssh (comme pour cvs : deux instances du programme communique, l'une locale et l'autre executée a distance par une méthode quelconque). Or ssh utilise le shell de l'utilisateur pour interpréter les commandes.

        Quoi qu'il en soit, donner un compte, même volontairement restreint, à un utilisateur revient presque à lui donner un shell. Il y a de multiples manières d'executer une commande si l'on à accès aux fichiers de l'utilisateur (.forward, fichiers rc, php et autre, crontabs peut-être, etc...). C'est pas gagné d'avance, mais il faut considérer cette possibilité, surtout si la config du système est complexe. Reste à savoir si les utilisateurs en question sont dignes de confiance (ainsi que ceux qui peuvent avoir accès à leurs mots de passe).

        Si l'on ne veut donner qu'un accès fichier à un utilisateur, il vaut peut-être mieux considérer d'en faire un utilisateur virtuel, sans UID réel.
        • [^] # Re: Sftp et Scp sans se logguer

          Posté par  . Évalué à 5.

          >> Or ssh utilise le shell de l'utilisateur pour interpréter les commandes.

          Pas dans le cas d'OpenSSH.

          Tiré de man page sshd(8) :

          Command execution and data forwarding

          Finally, the client either requests a shell or execution of a command.

          un petit coup d'oeil rapide dans les sources (session.c, do_exec*) confirme également.
  • # Re: Sftp et Scp sans se logguer

    Posté par  . Évalué à 0.

    Et pourquoi ne pas virer le shell des utilisateurs tout simplement ? Ils pourront faire du scp sans ssh non ?
  • # Question

    Posté par  . Évalué à 5.

    Si c'est pour faire du "scp only", on le peut déjà, avec OpenSSH, en ajoutant command="/usr/bin/scp -t /home_directory" au début de $HOME/.ssh/authorized_keys2, et ce, pour chaque clé, non ?

    Et si on est vraiment parano, on peut également appliquer la méthode d'Idealx pour chrooter un compte ssh : http://www.idealx.org/en/doc/chrooted-ssh-cvs-server/chrooted-ssh-c(...)


    Qu'apporte donc de plus scponly ? (celle ci est une vraie question).
    • [^] # Re: Question

      Posté par  . Évalué à 3.

      hum... déjà il crée son chroot tout seul comme un grand (la méthode que tu donne sert à installer un serveur cvs, et c'est le cvs qui chroote).

      par contre, pour ce qui est de la restriction de commandes, je suis d'accord pour dire que smrsh est mieux. En effet, là il interdit tous les caractères spéciaux et passe par des wildcards pour se débrouiller dans le cas ou le nom de fichier contient des caractères spéciaux... ce qui n'est pas terrible, vu qu'il pourrait confondre des fichiers.

      Dans tout les cas, il faut bien interdire au user l'accès à son home (et ne lui autoriser les modifications que dans un sous-répertoire). En effet, il peut facilement se créer un acces sinon :)
  • # Re: Sftp et Scp sans se logguer

    Posté par  . Évalué à 3.

    Il me semble qu'il y est déjà le paquet rssh qui face ça ?

    Quel est la différence entre les deux ?

Suivre le flux des commentaires

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