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

J'ai cherché une réponse viable à cette question, et la plupart des réponses comprennent 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 permettre d'accéder 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.

Modifier:

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 le support sftp dans sshd_config (et bien sûr redémarrez sshd):

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

Comme d'autres l'ont mentionné, la désactivation sftpn'est pas du tout suffisante - un utilisateur avec un sshaccès illimité peut afficher n'importe quel fichier que son compte a les autorisations de visualiser, peut modifier tout ce qu'il a l'autorisation de modifier et peut facilement télécharger tout ce qu'il peut lire lui-même. machine. La seule façon de les empêcher de le faire est de restreindre leur accès. Il est pas l' idéal compter sur .profilepour limiter les utilisateurs, car ce n'est pas ce qu'il est pour (Edit: Comme Aleksi mentionne dans sa réponse, il est en fait trivial à contourner .profile, la chose au sujet .profileest que ce soit pour la commodité, pas de sécurité, il est donc 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 façon est meilleure: affecter 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' sftpoutil serveur. Cela les empêche également de faire quoi que ce soit d' autre avec le système, et contrairement à .profilecela, en utilisant le serveur SSH lui-même (les .profilerestreint au shell, ForceCommandempêche également de faire d'autres choses qui n'impliquent pas le démarrage d'un shell). À la différence également .profile, ceci est conçu 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+sle programme. C'est le setuidbit; 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 par le biais du programme. Cependant, vous devriez probablement simplement l'utiliser ForceCommand, car cela restreint tout accès à "il suffit d'exécuter ce programme".

N'essayez pas de le faire avec .profilecar 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 le 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,

• Utiliser ForceCommanddanssshd_config
• Utiliser la connexion passwordless 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 soit exécuté sans arguments ou commescript -c 'command-the-user-wanted-to-run'
• Les deux ForceCommandet 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/falseou/sbin/nologin

Avis de non-responsabilité: Je ne suis en aucun cas un expert en la matière, alors même si je peux dire que la .profilechose 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. à propos. Ils sont en sécurité pour autant que je sache, mais je ne serais pas la première personne à se tromper sur Internet.

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 Subsystemmot clé. Du sshd_config(5)manuel:

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" pour /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 /bin/falseprogramme 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 souhaitez que votre utilisateur reçoive une invite shell standard. Cela n'a pas non plus de sens, car vous pourriez contourner la plupart des choses si vous avez accès au 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 Matchmot clé. Du sshd_config(5)manuel:

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 sshd_config(5)manuel.

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 ForceCommandmot - clé. Du sshd_config(5)manuel:

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 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 y 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