web-dev-qa-db-fra.com

Activer l'accès SSH Shell mais désactiver l'accès SFTP

J'ai cherché une réponse viable à cette question, et la plupart des réponses incluent des conseils sur les raisons de ne pas le faire. Cependant, voici le scénario et ce qui le rend nécessaire:

J'ai une application console, et dans le .profile de chaque utilisateur, il y a une commande de démarrage pour l'application, et juste après la commande qui la démarre, il y a une commande "exit", qui les déconnecte du système. Je veux seulement qu'ils puissent accéder à cette application console via l'interface fournie par celle-ci. Au démarrage, l'application présente à l'utilisateur une liste de clients accessibles via l'application, chaque client ayant son propre répertoire de données. Les utilisateurs ne sont autorisés à accéder qu'aux clients auxquels ils auront besoin d'accéder.

Maintenant, voici le problème: si je donne aux utilisateurs un accès SSH, ils pourront également se connecter en utilisant un client SFTP, ce qui leur donnera un accès direct aux répertoires de données de l'application, ce qui est TRÈS indésirable, car cela donnera également leur donner accès aux répertoires de données auxquels ils ne devraient pas avoir accès.

C'était une chose si simple à faire lors de l'utilisation d'une combinaison telnet/FTP, mais maintenant que je veux donner aux utilisateurs un accès depuis n'importe où sur Internet, je n'ai pas réussi à trouver un moyen de les désactiver de SFTP, tandis que leur permettant toujours d'accéder au shell où ils peuvent exécuter l'application.

linuxsshsecuritysftp
21
sosaisapunk

Éditer:

Dans le cas où ce n'est pas évident, la réponse suivante n'est pas conçue comme une méthode sécurisée pour empêcher SFTP d'être utilisé par toute personne ayant un accès Shell au serveur. C'est juste une réponse qui explique comment le désactiver de la visibilité externe. Pour une discussion sur la sécurité au niveau utilisateur, voir les réponses de @cpast et @Aleksi Torhamo. Si la sécurité est votre priorité, cette réponse n'est pas la bonne. Si la simple visibilité du service est votre objectif, alors c'est votre réponse.

Nous continuons maintenant à la réponse originale:

Commentez la prise en charge de sftp dans sshd_config (et bien sûr redémarrez sshd):

#Subsystem sftp /usr/lib/openssh/sftp-server

22
Wesley

Comme d'autres l'ont mentionné, la désactivation de sftp n'est pas du tout suffisante - un utilisateur avec un accès illimité ssh peut afficher n'importe quel fichier que son compte est autorisé à afficher, peut modifier tout ce qu'il est autorisé à modifier et peuvent facilement télécharger tout ce qu'ils peuvent lire sur leur propre machine. La seule façon de les empêcher de le faire est de restreindre leur accès. Il n'est pas non plus idéal de s'appuyer sur .profile pour restreindre les utilisateurs, car ce n'est pas pour ça (Edit: Comme Aleksi le mentionne dans sa réponse, il est en fait trivial de contourner .profile; la chose à propos de .profile c'est que c'est pour plus de commodité, pas pour la sécurité, donc ce n'est pas destiné à restreindre l'utilisateur. Utilisez des éléments conçus pour la sécurité, comme les éléments ci-dessous, pour assurer la sécurité).

Il existe deux méthodes de base pour ce faire: vous pouvez les restreindre via des autorisations de fichier ou les forcer à exécuter uniquement votre application console. La deuxième méthode est meilleure: affectez des utilisateurs qui devraient être limités à l'application console à un groupe (par exemple customers); puis dans sshd_config, ajoutez les lignes suivantes:

Match Group customers
ForceCommand /path/to/app

Cela permet de faire en sorte que toutes les connexions des utilisateurs de ce groupe ouvrent l'application console; ils ne peuvent rien démarrer d'autre, y compris l'outil serveur sftp. Cela les empêche également de faire quoi que ce soit else avec le système, et contrairement à .profile, le fait en utilisant le serveur SSH lui-même (.profile les restreint au Shell, ForceCommand empêche également de faire d'autres choses qui n'impliquent pas le démarrage d'un Shell). Contrairement à .profile, c'est conç comme une chose de sécurité; il est spécifiquement conçu pour résister à un utilisateur malveillant qui l'évite.

L'alternative (probablement inférieure) impliquerait la création d'un nouvel utilisateur pour exécuter l'application console. Vous limitez ensuite les répertoires de données à cet utilisateur, définissez l'application console appartenant à cet utilisateur et définissez u+s sur le programme. Il s'agit du bit setuid; cela signifie que quelqu'un qui exécute le programme de console le fait avec les autorisations du propriétaire du programme. De cette façon, l'utilisateur n'a pas lui-même accès aux répertoires, il ne l'obtient que via le programme. Cependant, vous devriez probablement simplement utiliser ForceCommand, car cela restreint l'accès all à "exécuter simplement ce programme".

28
cpast

N'essayez pas de le faire avec .profile car il n'offre aucune sécurité et ne restreint absolument rien!

Peu importe ce que vous mettez .profile, puisque vous pouvez le contourner en donnant simplement une commande à exécuter sur la ligne de commande ssh, comme ceci: ssh user@Host command. Vous pouvez toujours obtenir un accès Shell normal en faisant ssh -t user@Host bash.

La désactivation du sous-système sftp, comme mentionné dans une autre réponse, n'aide pas du tout. Les sous-systèmes ne sont essentiellement que des alias de commandes, et vous pouvez toujours utiliser sftp normalement en faisant sftp -s /path/to/sftp-executable user@Host.

Comme cpast et certains commentateurs l'ont dit, vous devez utiliser les mécanismes appropriés pour restreindre l'accès. C'est,

  • Utilisez ForceCommand dans sshd_config
  • Utilisez une connexion sans mot de passe et command="..." dans .ssh/authorized_keys
  • Changer le shell de l'utilisateur en quelque chose qui restreint ce que l'utilisateur peut faire

Remarques:

  • command="..." ne s'applique qu'à une seule clé, donc il ne restreint pas la connexion ssh pour l'utilisateur utilisant un mot de passe ou une autre clé
  • Vous pouvez également vouloir restreindre la redirection de port, etc. (la redirection de port, la redirection x11, la redirection d'agent et l'allocation de pty sont celles dont j'ai entendu parler)
    • AllowTcpForwarding etc. dans sshd_config
    • no-port-forwarding etc. dans .ssh/authorized_keys
  • Si vous avez d'autres démons (comme FTP) en cours d'exécution, vous devez vérifier qu'ils ne laissent pas entrer l'utilisateur (certains démons prennent cette décision en fonction du shell de l'utilisateur, donc si vous changez cela, vous voudrez peut-être revérifier cela)
  • Vous pouvez changer le shell de l'utilisateur en un script qui fait ce que vous voulez; il est exécuté sans arguments ou comme script -c 'command-the-user-wanted-to-run'
  • ForceCommand et command="..." exécutez la commande via le shell de l'utilisateur, afin qu'ils ne fonctionnent pas si le shell de l'utilisateur est défini par exemple. /bin/false ou /sbin/nologin

Avertissement: je ne suis aucunement expert en la matière, alors même si je peux dire que le .profile chose n'est pas sûre, je ne peux pas promettre qu'il n'y a pas de "gotcha" avec les autres méthodes que je ne connais pas. Ils sont en sécurité pour autant que je sache, mais je ne serais pas la première personne à se tromper sur Internet.

15
Aleksi Torhamo

Il est possible d'activer SSH et de désactiver SFTP à la fois globalement et par utilisateur/groupe.

Personnellement, j'en ai besoin parce que je veux donner accès à certains dépôts git via SSH, et j'aime désactiver les systèmes qui ne sont pas nécessaires. Dans ce cas, SFTP n'est pas nécessaire.

Globalement

Vous pouvez désactiver SFTP pour tous les utilisateurs de plusieurs manières.

Le sous-système manquant

Le démon SFTP utilisé par SSH peut être configuré via le mot clé Subsystem. Dans le manuel sshd_config(5):

Subsystem
        Configures an external subsystem (e.g. file transfer daemon).
        Arguments should be a subsystem name and a command (with optional
        arguments) to execute upon subsystem request.

        The command sftp-server(8) implements the “sftp” file transfer
        subsystem.

        Alternately the name “internal-sftp” implements an in-process
        “sftp” server.  This may simplify configurations using
        ChrootDirectory to force a different filesystem root on clients.

        By default no subsystems are defined.

La dernière ligne suggère qu'il devrait suffire de ne définir aucun sous-système pour "sftp".

Un faux mensonge

Vous pouvez également désactiver SFTP en définissant le démon SFTP utilisé par SSH sur quelque chose d'inutilisable. Par exemple, configurez le sous-système "sftp" sur /bin/false:

Subsystem sftp /bin/false

Lorsque quelque chose tentait de se connecter via SFTP, le démon SSH tentait de générer le "démon sftp" /bin/false. Le programme /bin/false Ne fait qu'une chose, c'est de renvoyer un code d'erreur. La tentative de connexion SFTP est effectivement refusée.

Par utilisateur/groupe

Il est également possible de désactiver SFTP par utilisateur, groupe ou quelques autres critères.

Cela ne fonctionne pas si vous voulez que votre utilisateur reçoive une invite Shell régulière. Cela n'a pas de sens, car vous pourriez contourner la plupart des choses si vous avez un accès Shell. Cela ne fonctionnera que si vous ne souhaitez donner accès qu'à un programme spécifique.

Correspondant à

Pour faire correspondre un ensemble d'utilisateurs, vous pouvez configurer SSH avec le mot clé Match. Dans le manuel sshd_config(5):

Match
        ...

        The arguments to Match are one or more criteria-pattern pairs or the
        single token All which matches all criteria.  The available criteria
        are User, Group, Host, LocalAddress, LocalPort, and Address.  The
        match patterns may consist of single entries or comma-separated
        lists and may use the wildcard and negation operators described in
        the PATTERNS section of ssh_config(5).

        ...

Quelques exemples:

  • Match User eva Correspond à l'utilisateur "eva"
  • Match User stephen,maria Correspond aux utilisateurs "stephen" et "maria"
  • Match Group wheel,adams,simpsons Correspond aux groupes "roue", "adams", "simpsons"

Si vous voulez plus d'informations, il y a des charges dans le manuel sshd_config(5).

Commande forcée

Normalement, vous obtenez le shell de connexion de l'utilisateur lorsque vous vous connectez via SSH, mais SSH peut être configuré pour forcer une certaine commande. La commande est forcée pour toute connexion SSH, y compris SFTP, et vous pouvez donc avoir la possibilité de forcer la commande souhaitée.

La commande à forcer peut être configurée avec le mot clé ForceCommand. Dans le manuel sshd_config(5):

ForceCommand
        Forces the execution of the command specified by ForceCommand,
        ignoring any command supplied by the client and ~/.ssh/rc if
        present.  The command is invoked by using the user's login Shell
        with the -c option.  This applies to Shell, command, or subsystem
        execution.  It is most useful inside a Match block.  The command
        originally supplied by the client is available in the
        SSH_ORIGINAL_COMMAND environment variable.  Specifying a command of
        “internal-sftp” will force the use of an in-process sftp server that
        requires no support files when used with ChrootDirectory.  The
        default is “none”.

Vous pouvez donc forcer la commande contrainte que vous souhaitez utiliser en utilisant ForceCommand <your command>. Par exemple:

Match User kim
        ForceCommand echo 'successful login man, congrats'

Exemple

Dans mon cas où je veux donner un accès à git, j'ai seulement besoin que l'utilisateur ait accès à git-Shell. C'est la section qui désactive SFTP pour mes utilisateurs git, avec quelques options de sécurité:

Match Group git

        # have to do this instead of setting the login Shell to `git-Shell`,
        # to disable SFTP
        ForceCommand /usr/bin/git-Shell -c "$SSH_ORIGINAL_COMMAND"

        # disable stuff we don't need
        AllowAgentForwarding no
        AllowTcpForwarding no
        AllowStreamLocalForwarding no
        PermitOpen none
        PermitTunnel no
        PermitTTY no
        X11Forwarding no
1
aude