Solution 1 :
Comme d'autres l'ont mentionné, la désactivation de sftp n'est pas suffisant - un utilisateur avec ssh illimité access peut voir n'importe quel fichier que son compte a l'autorisation de voir, peut modifier tout ce qu'il a l'autorisation de modifier et peut facilement télécharger tout ce qu'il peut lire sur sa 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 se fier à .profile 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 est que c'est pour la commodité, pas pour la sécurité, donc il n'est pas destiné à restreindre l'utilisateur. Utilisez des choses conçues pour la sécurité, comme les choses ci-dessous, pour assurer la sécurité).
Il existe deux manières de procéder :vous pouvez les restreindre via des autorisations de fichiers ou les forcer à n'exécuter que votre application de console. La deuxième méthode est meilleure :affectez les utilisateurs qui doivent être limités à l'application console à un groupe (par exemple, customers ); puis, en 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 le sftp outil serveur. Cela les empêche également de faire quoi que ce soit d'autre avec le système, et contrairement à .profile , le fait en utilisant le serveur SSH lui-même (.profile les restreint au niveau du shell, ForceCommand empêche également de faire d'autres choses qui n'impliquent pas de démarrer un shell). Contrairement à .profile , ceci est conçu comme chose de sécurité; il est spécialement 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 restreindriez ensuite les répertoires de données à cet utilisateur, définiriez l'application de console appartenant à cet utilisateur et définiriez u+s au programme. C'est le setuid bit; cela signifie que quelqu'un qui exécute le programme console le fait avec les permissions 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 utiliser ForceCommand , car cela restreint tous accès à "exécuter simplement ce programme".
Solution 2 :
Modifier :
Au cas où ce ne serait pas évident, la réponse suivante n'est pas destinée à être sécurisée méthode pour empêcher l'utilisation de SFTP 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 de l'utilisateur, consultez 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 passons maintenant à la réponse d'origine :
Commentez le support sftp dans sshd_config (et bien sûr redémarrez sshd ):
#Subsystem sftp /usr/lib/openssh/sftp-server
Solution 3 :
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 dans .profile , puisque vous pouvez le contourner en donnant simplement une commande à exécuter sur la ligne de commande ssh, comme ceci :ssh [email protected] command . Vous pouvez toujours obtenir un accès shell normal en faisant ssh -t [email protected] 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 [email protected] .
Comme cpast et certains commentateurs l'ont dit, vous devez utiliser les mécanismes appropriés pour restreindre l'accès. C'est-à-dire
- Utilisez
ForceCommandensshd_config - Utiliser une connexion sans mot de passe et
command="..."en.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 cela ne restreint pas la connexion ssh pour l'utilisateur utilisant un mot de passe ou une autre clé- Vous pouvez également restreindre le transfert de port, etc. (le transfert de port, le transfert x11, le transfert d'agent et l'allocation de pty sont ceux dont j'ai entendu parler)
AllowTcpForwardingetc. danssshd_configno-port-forwardingetc. en.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 l'utilisateur entrer (certains démons prennent cette décision en fonction du shell de l'utilisateur, donc si vous modifiez cela, vous voudrez peut-être re- vérifie ceci)
- Vous pouvez remplacer le shell de l'utilisateur par un script qui fait ce que vous voulez ; il est soit exécuté sans arguments, soit comme
script -c 'command-the-user-wanted-to-run' - Les deux
ForceCommandetcommand="..."exécutez la commande via le shell de l'utilisateur, de sorte qu'ils ne fonctionnent pas si le shell de l'utilisateur est défini sur eg./bin/falseou/sbin/nologin
Clause de non-responsabilité :je ne suis en aucun cas un expert en la matière, donc 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. Pour autant que je sache, ils sont sûrs, mais je ne serais pas la première personne à me tromper sur Internet.