ssh permet de faire à peu près ce que tu veux je crois. Il faut ajouter quelque paramètre devant la clé publique dans le fichier authorized_keys.
Les paramètres intéressants entre autres (man ssh pour les avoir toutes ;-))
command="command"
environment="NAME=value"
from="pattern-list"
no-pty
"command" va déclencher l'utilisation de cette commande lors de la connexion ssh. Notamment dans l'environnement il y a SSH_ORIGINAL_COMMAND, donc lorsque tu fais:
"ssh user@machine_distante ma_commande"
tu peux tout à fait faire que la machine distante exécutera toujours:
"sudo -u utilisateur_restreint ma_commande"
avec un sudo bien réglé.
Tu peux mettre ton petit programme aussi, comme ça ça lui évitera de tourner en root mais uniquement lors de la connexion et avec l'identité "finale". A charge de ce programme de vérifier si tel utilisateur peut exécuter ce programme, à la rigueur.
[^] # Re: sonde -> log -> syslog -> serveur
Posté par Bertrand Mathieu . En réponse au journal Launch And Forget. Évalué à 1.
Les paramètres intéressants entre autres (man ssh pour les avoir toutes ;-))
command="command"
environment="NAME=value"
from="pattern-list"
no-pty
"command" va déclencher l'utilisation de cette commande lors de la connexion ssh. Notamment dans l'environnement il y a SSH_ORIGINAL_COMMAND, donc lorsque tu fais:
"ssh user@machine_distante ma_commande"
tu peux tout à fait faire que la machine distante exécutera toujours:
"sudo -u utilisateur_restreint ma_commande"
avec un sudo bien réglé.
Tu peux mettre ton petit programme aussi, comme ça ça lui évitera de tourner en root mais uniquement lors de la connexion et avec l'identité "finale". A charge de ce programme de vérifier si tel utilisateur peut exécuter ce programme, à la rigueur.
Voilà un lien où cette solution est évoquée: https://linuxfr.org/comments/1014767.html#1014767
En tous cas tu peux faire en sorte que l'utilisateur n'aie aucun shell à sa disposition, voire pas de pty, c'est un cas prévu par ssh.