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


21

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.


8
J'oublie les détails, mais je pense que SSH vous permet de restreindre les utilisateurs à l'exécution d'une seule commande lorsqu'ils se connectent. Ils n'obtiennent pas un accès complet au shell si vous le configurez. Cela pourrait être utile pour votre cas d'utilisation. (Après tout, il est possible d'émuler l'accès SFTP à l'aide de SSHFS. La simple désactivation de SFTP n'empêchera pas un utilisateur moyennement déterminé d'accéder à n'importe quel fichier auquel son compte utilisateur a accès.)
David Z

3
De plus, vous pouvez envisager de "chrooter" vos utilisateurs. et pour l'accès aux données de rechange, cela ressemble à un problème de conception
Dennis Nolte

2
Utiliser .profilepour cela sonne comme la mauvaise solution. Je pense que la configuration de l'utilisateur avec un autre shell aurait beaucoup plus de sens.
kasperd

3
N'essayez pas d'utiliser l' .profileastuce pour restreindre l'accès, car il est trivial de contourner. (voir ma réponse pour plus de détails)
Aleksi Torhamo

Réponses:


22

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


1
Parfois, la ligne peut êtreSubsystem sftp internal-sftp
Kondybas

1
J'ai Subsystem sftp /usr/libexec/sftp-server Mais ça a fait l'affaire. Merci beaucoup
sosaisapunk

16
Cela ne semble pas plausible. Si vous pouvez exécuter des commandes arbitraires sur le serveur, vous pouvez exécuter le programme côté serveur sftp. Même s'il n'est pas installé, vous pouvez le réimplémenter en tant que commande shell longue et demander au client sftp d'envoyer cette commande au lieu de sftp. Cette méthode peut rendre l'utilisation de sftp moins pratique, mais il n'y a aucun moyen d'empêcher un utilisateur qui peut exécuter des commandes arbitraires d'utiliser ces commandes pour effectuer des transferts de fichiers.
R ..

1
@sosaisapunk Ce n'est pas vrai. Les utilisateurs peuvent exécuter la commande qu'ils souhaitent en utilisant ssh user@host command, car .profileils ne seront pas exécutés du tout si vous le faites, et votre application ne démarrera donc pas du tout. Ils peuvent obtenir un accès complet au shell en disant simplement ssh -t user@host bash. Essayez-le et vous verrez. Le sous-système n'est qu'un alias de commande; s'ils pouvaient utiliser sftp auparavant, ils peuvent toujours l'utiliser - et toute autre commande qu'ils souhaitent. Lisez ma réponse ci-dessous.
Aleksi Torhamo

1
@sosaisapunk: Non, le fait est que vous pouvez le faire avec ssh, mais pas avec .profilecar il n'est pas destiné à la sécurité et est facilement contourné. Dans ma réponse, j'ai énuméré trois méthodes différentes de le faire avec ssh. En bref, déplacez simplement l'invocation de votre application .profilevers un script shell et 1) définissez le script shell comme shell de l'utilisateur 2) définissez le script shell comme (correctement apparié) ForceCommanddans sshd_config3) passez à l'authentification par clé publique et définissez le script shell comme commanddans .ssh/authorized_keys. (De plus, vous devez utiliser @name pour que les gens soient informés des commentaires)
Aleksi Torhamo

28

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".


4
Je voudrais ajouter que cela ForceCommandn'empêche pas la redirection de port SSH.
nyuszika7h

1
En fait, s'appuyer sur .profileest plus que «pas idéal»; il est facilement contourné (voir ma réponse pour plus de détails) et n'offre donc aucune protection, seulement un faux sentiment de sécurité.
Aleksi Torhamo

@AleksiTorhamo Ah. Je soupçonnais que vous pouviez le contourner, mais je ne savais pas trop comment (je soupçonne généralement que les choses non destinées à la sécurité sont contournables). Merci pour les détails sur comment!
cpast

15

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.


1
Il semble qu'au moins pour ForceCommandet forcé la connexion sans mot de passe avec command=in authorized_keys, alors qu'il a été contourné auparavant, cela est dû à un bogue dans le serveur: il est destiné à être sécurisé contre un utilisateur malveillant, et un utilisateur qui le contourne compte comme une vulnérabilité grave dans le serveur SSH (et est donc un correctif prioritaire). Comme vous le faites remarquer, .profileest contournable par conception: comme il n'est pas considéré comme une fonction de sécurité, un utilisateur qui la contourne est parfaitement OK du point de vue du développeur du shell.
cpast

1
@cpast: Oui, je pensais à l'existence de plus de fonctionnalités comme la redirection de port. Je veux dire, si vous ne saviez pas que ssh autorise la redirection de port et juste utilisé ForceCommandpour restreindre l'accès, et avait un démon qui n'écoute que les connexions localement et n'effectue pas l'authentification, l'utilisateur ssh pourrait toujours accéder au démon. Les fonctionnalités que j'ai énumérées sont celles par exemple. Les solutions d'hébergement git sont généralement désactivées, et je n'en ai pas vu d'autres "malveillantes" dans les pages de manuel, mais je n'ai pas encore trouvé de document officiel "c'est comme ça que vous utilisez en ForceCommandtoute sécurité".
Aleksi Torhamo

Certes, l' ~/.profileutilisateur est modifiable et n'est pas utile pour la sécurité, mais pourriez-vous donner un sens à la technique de cpast en l'intégrant /etc/profile? Vous pouvez vérifier l'UID pour le limiter aux bons utilisateurs.
poussins

1
@chicks: Non, il a exactement le même problème. Le problème n'est pas que le fichier est modifiable par l'utilisateur; Le problème est que les deux fichiers peuvent être contournés entièrement. Les fichiers ne sont utilisés que pour les shells de connexion, que vous obtenez si vous venez de le dire ssh user@host, mais si vous dites à ssh d'exécuter une commande - c'est-à-dire. ssh user@host command- vous n'obtenez plus de shell de connexion et les fichiers ne sont pas du tout touchés. Vous pouvez donc contourner trivialement toutes les restrictions que quelqu'un a essayé de créer avec les fichiers en donnant simplement un argument supplémentaire à ssh.
Aleksi Torhamo

2
@chicks: De plus, je viens de réaliser que vous avez fait référence à cpast; la méthode dans la réponse de cpast n'utilise pas .profile, elle utilise sshd_configet devrait être sûre. Il mentionne seulement .profilecomme méthode que vous ne devriez pas utiliser pour ce faire.
Aleksi Torhamo

1

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

Dans mon cas, je voulais autoriser uniquement l'accès MySQL (interdisant à la fois l'accès SFTP et les fenêtres de terminal SSH) pour une clé autorisée particulière (c'est-à-dire, aucune modification du fichier sshd_config). J'ai réussi à le faire avec les options ~ / .ssh / authorized_keys suivantes pour la clé particulière: command = "/ usr / bin / echo 'Seul l'accès MySQL est autorisé.'", No-pty, no-X11-forwarding, permitopen = "127.0.0.1:3306"
Martin_ATS
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.