Ajout d'un utilisateur qui ne peut exécuter des scripts qu'à distance

14

Je voudrais créer un utilisateur qui ne peut faire qu'une seule chose: via ssh, spécifiez un script (et des arguments de ligne de commande pour le script) qui réside dans un dossier particulier (pour les besoins de cette question, appelons-le /local/remote_only_scripts/foo) et faire exécuter ce script et retourner sa sortie.

Pour être clair, quelques exemples de choses que je ne veux pas que l'utilisateur puisse faire:

Connectez-vous localement au compte. L'application de connexion est /bin/login. Ce n'est pas un script dans le /local/remote_only_scripts/foodossier, il ne doit donc pas être appelé par l'utilisateur.
Connectez-vous à distance au compte. Encore une fois, la connexion (est-ce ce que ssh appelle?) N'est pas un script dans le dossier correspondant.
Liste le contenu du répertoire. ls est dedans /bin/ls. Ce n'est pas un script dans le répertoire approprié.
Modifiez un fichier dans ce répertoire. emacs, vi, gedit la plupart des autres éditeurs ne sont pas des scripts dans ce répertoire.
Affichez le contenu d'un fichier dans ce répertoire.
Exécutez un fichier dans ce répertoire qu'il n'est pas autorisé à exécuter.

Notez que ce sont des exemples, il y a beaucoup d'autres actions que je ne veux pas que l'utilisateur puisse faire. Lorsque vous envisagez une action, demandez "est-ce que cela se fait par un script en /local/remote_only_scripts/foo?" si la réponse est non, l'utilisateur ne devrait pas pouvoir le faire. Si la réponse est oui, l'utilisateur devrait pouvoir le faire.

PS: Permettez-moi de clarifier ce que je veux dire par "ajouter un utilisateur". Je ne veux pas dire ajouter un utilisateur à un sous-système ssh. Je veux plutôt dire ajouter un utilisateur au système informatique. Ainsi, par exemple, j'ai un système exécutant Debian stable, appelez-le par son adresse, www.hg.bar.com. Je veux ajouter un utilisateur (via kuser, users-admin ou useradd ou d'une manière similaire) l'appeler hg_guest. hg_guest ne peut pas se connecter localement ou faire l'une des choses dans la liste ci-dessus. Tout ce que hg_guest peut faire est d'exécuter des scripts "à distance". J'ai dit qu'il devrait pouvoir le faire via ssh, mais en y réfléchissant maintenant, peut-être que lui permettre d'utiliser ssh peut lui permettre de se connecter localement, donc un autre mécanisme peut être nécessaire.

ssh account-restrictions

— HandyGandy
source

12

Il y a une option de commande dans le fichier authorized_keys. Cette option semble faire exactement ce que vous voulez.

Notez que ce n'est pas un chroot ou un shell restreint. Il permet d'exécuter uniquement ces commandes via ssh. Avec votre exemple, ce serait:

ssh somehost /local/remote_only_scripts/foo

Pour ce fichier authorized_keys:

command="/local/remote_only_scripts/foo",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ...public key...

Il existe de nombreuses possibilités si vous ne souhaitez pas que votre utilisateur puisse se connecter localement. Vous pouvez soit :

définissez simplement son shell sur / bin / false (vous aurez peut-être besoin de / bin / true car ssh a besoin d'une connexion valide)
verrouiller son mot de passe, voir passwd -l

EDIT : ajout d'options de restriction supplémentaires et clarification de la façon dont vous supprimez l'accès local.

— Coren
source

Je ne pense pas que vous ayez besoin de spécifier cette commande dans ssh côté client, c'est une commande 'forcée' donc elle serait toujours exécutée;) L'utilisateur sur le site distant a toujours besoin d'un shell valide défini dans / etc / passwd.

— jirib

1

A côté command=, les options no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-ptysont nécessaires pour vraiment restreindre le compte.

— jofel

D'accord. Je me suis réveillé au milieu de la nuit et j'ai décidé de vérifier les réponses. Étant donné que je suis somnolent, je n'assimilerai pas la réponse entière mais demanderai quelque chose qui me laisse perplexe. Comment cela empêche-t-il hg_quest de se connecter depuis un terminal?

— HandyGandy

@HandyGandy C'est la partie la plus simple. J'ai ajouté 2 façons de le faire, mais je pense qu'il y a plus

— Coren

0

Essayez ceci comme shell de connexion pour l'utilisateur:

#!/bin/sh
basedir=/local/remote_only_scripts
while read -p '$ ' prog args; do
    if [ ! -x "$basedir/$prog" ]; then
        echo "Invalid program: $prog"
    else
        case "$prog $args" in
            *\**|*\?*|*\^*|*\&*|*\<*|*\>*|*\|*|*\;*|*\`*|*\[*|*\]*)
                echo "Invalid character in command";;
            *)
                eval "$prog $args"
                echo;; # force a trailing newline after the program
        esac
    fi
done

Vous voudrez probablement aussi avoir ceci dans le authorized_keysfichier explicitement comme dans la réponse de Coren; mais remplacez le '... / foo; avec le programme ici. Cela permettra d' éviter les commandes de SSH comme sftp, scpet ssh hostname command.

— Arcege
source

Si vous voulez seulement que l'utilisateur puisse exécuter les commandes depuis votre répertoire (et il n'y en a pas trop), vous pouvez retirer le "prog" de la lecture ci-dessus et utiliser une instruction select pour offrir un menu texte de choix de ces programmes, puis faites la lecture des arguments. Je testerais également cela pour m'assurer de ce qui se passe si vous tapez un groupe de Ctrl-C à différents points du script. Vous voudrez peut-être également une commande trap.

— Joe

0

Dans le cas contraire, ils n'ont besoin d'accéder qu'à un script, cela fonctionne très bien pour moi. Ajoutez l'utilisateur et modifiez son shell par défaut sur le chemin du script. Lorsqu'ils se connectent via ssh, il exécutera le script et fermera leur session.

server1:/ # useradd -s "/local/remote_only_scripts/foo/script.sh" hg_guest

server1:/ # grep hg_guest /etc/passwd

hg_guest: x: 2002: 100 :: / home / hg_guest: /local/remote_only_scripts/foo/script.sh

— 2bc
source