est il possible de donner un seul droit a un utilisateur, celui d'executer un script bien precis et rien d'autre (pas de creation de repertoire, de fichier etc...) ?
C'est un utilisateur qui se connecte comment? En local, à distance? C'est un vrai utilisateur, ou un service qui tourne avec un compte spécial?
Là tout de suite, je dirais que tu peux lui donner comme shell le script que tu veux qu'il exécute, au lieu d'un shell "normal", lors de la création de son compte. C'est un script interactif?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
en fait le user se connecterait en ssh sur la becanne et ne devrait pouvoir QUE lancer un script qui se trouve dans son home
Avec un couple de clé privée / publique et en utilisant l'option command=mon-script ajoutée au fichier authorized_keys tu devrais arriver à ce que tu cherches.
man sshd
command="command"
Specifies that the command is executed whenever this key is used for authentication.
The command supplied by the user (if any) is ignored. (...) This option might be useful
to restrict certain public keys to perform just a specific operation. An example might be a key
that permits remote backups but nothing else.
man ssh, option command. L'utilisateur pourra faire un ssh sur la machine, qui déclanchera la commande et le tunnel se coupe dès qu'elle est finie. Je crois qu'il n'aura pas d'accès shell à la machine distance, sinon option -N (de tête, à vérifier) si c'est toi qui lui prépare le script.
dans l'énoncé non, mais dans sa réponse que je cite "en fait le user se connecterait en ssh sur la becanne et ne devrait pouvoir QUE lancer un script qui se trouve dans son home ."
Définir ton script en tant que shell de l'utilisateur.
Du coup lorsque ton utilisateur s'authentifie, le bash|zsh|csh|... n'est pas lancé, mais le script en question oui.
Dès que le script est fini l'utilisateur est déconnecté.
C'est évidement très très moche, ça limite l'utilisateur, mais ça marche fort bien.
heu ... ça m'arrive de faire ça et je ne vois pas quels problèmes ça soulève. Au contraire même, je trouve ça très bien :)
Du coup, ça m'intéresserait que tu développes sur ce que tu vois de négatif là dedans.
Je fais ça aussi, c'est pour ça que je l'ai proposé !
Mais ça m'a posé des problèmes pour certains scripts sur le renvoi des messages vers stdout et stderr (avec des scripts csh qui lancent des scripts expect..), peut-être la solution aurait été une simple variable d'environnement à déclarer, mais j'avoue que je n'ai pas creusé (peut-être aussi que mon script était mal fait...).
ok, j'en déduis que tu as rencontré des problèmes (probablement contournables en y passant un peu de temps) dans l'implémentation d'un script particulier, mais pas de critique de fond sur le mécanisme.
merci pour les précisions
oui, bien vu.
Moment nostalgie : en prépa, sur les PCs, l'environnement Windows était très très limité. Par contre, l'IDE qu'on utilisait (ça devait être du Borland Pascal, ça nous rajeunit pas) avait une chouette menu pour ouvrir un shell dos =)
pour etre plus precis, le user devra se connecter en ssh sur un serveur web de recette et devra rapatrier le code des site web depuis un serveur de dev.pour ca il utilisera la commande "rsync" qui me semble pas mal pour ce genre de truc.de plus il y a des exclusion de fichiers voir de répertoires a prendre en compte, d'ou l'idee de faire un script par site web. donc ce que je voulais, c'est que le type qui va lancer les scripts ne puisse faire que ca.
tu sais que tu peux faire un rsync dans l'autre sens ?
depuis la source vers le serveur de destination...
donc pas forcement besoin d'ouvrir le serveur de recette autrement que d'accepter le recevoir le rsync over ssh
# Précisions?
Posté par Grunt . Évalué à 4.
Là tout de suite, je dirais que tu peux lui donner comme shell le script que tu veux qu'il exécute, au lieu d'un shell "normal", lors de la création de son compte. C'est un script interactif?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Précisions?
Posté par menza . Évalué à 1.
[^] # Re: Précisions?
Posté par Ellendhel (site web personnel) . Évalué à 8.
Avec un couple de clé privée / publique et en utilisant l'option command=mon-script ajoutée au fichier authorized_keys tu devrais arriver à ce que tu cherches.
man sshd
command="command"
Specifies that the command is executed whenever this key is used for authentication.
The command supplied by the user (if any) is ignored. (...) This option might be useful
to restrict certain public keys to perform just a specific operation. An example might be a key
that permits remote backups but nothing else.
[^] # Re: Précisions?
Posté par Dabowl_92 . Évalué à 1.
[^] # Re: Précisions?
Posté par menza . Évalué à 2.
# man ssh
Posté par tipmeabout . Évalué à 4.
man ssh, option command. L'utilisateur pourra faire un ssh sur la machine, qui déclanchera la commande et le tunnel se coupe dès qu'elle est finie. Je crois qu'il n'aura pas d'accès shell à la machine distance, sinon option -N (de tête, à vérifier) si c'est toi qui lui prépare le script.
Bonnes fêtes de fin d'année !
[^] # Re: man ssh
Posté par tipmeabout . Évalué à 3.
Ca se met dans le ~/.ssh/authorized_keys du user concerné:
command="sudo shutdown -h now" ssh-rsa <la clef publique> <descriptif/nom de la clef>
command="vlc v4l2://dev/video --no-audio --width=640 --height=480" ssh-rsa <une autre clef publique> <descriptif/nom de cette clef>
c'est pas plus compliqué.
pour le man ssh, j'ai pas retrouvé la section. google-lise la question, tu devais trouver des liens.
[^] # Re: man ssh
Posté par Dabowl_92 . Évalué à -3.
[^] # Re: man ssh
Posté par tipmeabout . Évalué à 1.
"en fait le user se connecterait en ssh sur la becanne et ne devrait pouvoir QUE lancer un script qui se trouve dans son home ."
oui ;)
# ACL
Posté par Dabowl_92 . Évalué à 2.
# Et ma mauvaise réponse est...
Posté par mekare . Évalué à 2.
Du coup lorsque ton utilisateur s'authentifie, le bash|zsh|csh|... n'est pas lancé, mais le script en question oui.
Dès que le script est fini l'utilisateur est déconnecté.
C'est évidement très très moche, ça limite l'utilisateur, mais ça marche fort bien.
[^] # Re: Et ma mauvaise réponse est...
Posté par gaaaaaAab . Évalué à 3.
Du coup, ça m'intéresserait que tu développes sur ce que tu vois de négatif là dedans.
[^] # Re: Et ma mauvaise réponse est...
Posté par mekare . Évalué à 2.
Mais ça m'a posé des problèmes pour certains scripts sur le renvoi des messages vers stdout et stderr (avec des scripts csh qui lancent des scripts expect..), peut-être la solution aurait été une simple variable d'environnement à déclarer, mais j'avoue que je n'ai pas creusé (peut-être aussi que mon script était mal fait...).
[^] # Re: Et ma mauvaise réponse est...
Posté par gaaaaaAab . Évalué à 1.
merci pour les précisions
[^] # Re: Et ma mauvaise réponse est...
Posté par totof2000 . Évalué à 2.
[^] # Re: Et ma mauvaise réponse est...
Posté par gaaaaaAab . Évalué à 1.
Moment nostalgie : en prépa, sur les PCs, l'environnement Windows était très très limité. Par contre, l'IDE qu'on utilisait (ça devait être du Borland Pascal, ça nous rajeunit pas) avait une chouette menu pour ouvrir un shell dos =)
# pour etre beaucoup plus precis :)
Posté par menza . Évalué à 1.
[^] # Re: pour etre beaucoup plus precis :)
Posté par NeoX . Évalué à 3.
depuis la source vers le serveur de destination...
donc pas forcement besoin d'ouvrir le serveur de recette autrement que d'accepter le recevoir le rsync over ssh
[^] # Re: pour etre beaucoup plus precis :)
Posté par menza . Évalué à 1.
"donc pas forcement besoin d'ouvrir le serveur de recette autrement que d'accepter le recevoir le rsync over ssh "
il faut bien un compte malgres tout sur la destination pour faire le rsync ?
[^] # Re: pour etre beaucoup plus precis :)
Posté par NeoX . Évalué à 2.
ton developpeur ne se connecteras plus sur le serveur, il pourra juste pousser des fichiers via rsync
plutot que de lui ouvrir le serveur en ssh classique et de restreindre son shell à un script qui va aller chercher les fichiers sur le serveur de dev
[^] # Re: pour etre beaucoup plus precis :)
Posté par menza . Évalué à 1.
[^] # Re: pour etre beaucoup plus precis :)
Posté par leviathan (site web personnel) . Évalué à 1.
[^] # Re: pour etre beaucoup plus precis :)
Posté par menza . Évalué à 1.
# SELinux
Posté par inico (site web personnel) . Évalué à 3.
Base toi sur la configuration de xguest, cela ressemble déjà beaucoup à ton besoin.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.