Le 25/03/21 à 14:05, Julien Escario <julien.escario@altinea.fr> a écrit :

Le 25/03/2021 à 13:38, Daniel Caillibaud a écrit :

...

Bonjour,

Y a-t'il un moyen propre d'avoir un login shell qui dépendent de la clé ssh utilisée ? (le shell pour exécuter une commande passée à ssh restant celui défini pour le user)

Et avec command="zsh" au début de la déclaration de la clé dans authorized_keys ?

https://www.ssh.com/ssh/authorized_keys/openssh

Ça fonctionne pour du login mais pas pour ssh user@host 'une commande' -- Daniel Un imprimeur est un homme qui ne manque pas de caractère et qui cherche à faire bonne impression. Serge Mirjean

Le 25/03/21 à 16:13, Julien Escario <julien.escario@altinea.fr> a écrit :

...

ssh user@host 'une commande'

Je ne suis bien sûr d'avoir compris alors : quand tu fais ça, à aucun moment tu n'invoques de shell (ni bash, ni aucun autre).

Dans ce cas sshd invoque le shell du user pour lancer la commande (le shell indiqué dans /etc/passwd) -- Daniel Un traître est un homme politique qui quitte son parti pour s'inscrire a un autre. Par contre, un converti est un homme politique qui quitte son parti pour s'inscrire au votre. Georges Clémenceau.

Le 25/03/21 à 14:39, Wallace <wallace@morkitu.org> a écrit :

Bonjour,

Imposer ZSH à tout le monde je ne vois pas le souci je le fais je ne vois pas le problème :D

;-)

Le souci du shell c'est qu'il faut bien en mettre un dans /etc/passwd et qu'il doit être valide.

Tu peux toujours faire une commande en plus avant ta clef ssh, ça devrait pouvoir le faire.

J'ai bien tenté un command="/path/to/login.sh" … avec dans login.sh #!/bin/sh if [ -t 1 ]; then # login shell exec /bin/zsh else # command shell exec /bin/sh fi mais revient au même que command="/bin/zsh" => ça marche pour du login shell mais pas pour des commandes passées via ssh.

Sinon dans ton bashrc ou zshrc tu fais tes choix. Je fais cela pour savoir si oui ou non je lance un tmux par défaut quand j'arrive sur certains serveurs.

C'est un peu ça que je voulais faire, mais dans le ~/.bashrc (ou le ~/.profile) je vois pas comment détecter quelle clé ssh vient de se connecter, sauf à passer le PermitUserEnvironment à yes et faire ce que j'indiquais dans le post initial. Mais en en discutant, je viens de me rappeler un truc, et Euréka, ça fonctionne avec #!/bin/sh if [ -t 1 ]; then exec /bin/zsh else $SSH_ORIGINAL_COMMAND fi :-) -- Daniel Selon les derniers chiffres, 1/3 des statistiques sont fausses.

Le jeu. 25 mars 2021 à 16:05, Daniel Caillibaud <ml@lairdutemps.org> a écrit :

Il s'agit de comptes lié à des applications, foo pour l'appli foo, je vois pas en quoi ce serait mal d'être plusieurs à s'y connecter.

Et en matière de règles chacun sa religion ;-)

Sur un paquet de chose c'est vrai. Sur ca je suis moins d'accord. Si tu t'assoie sur les pratiques Micro$oft, PCI/DSS, les reco de l'ANSSI (et probablement toutes les autres agences équivalentes à l'international), ISO 27001, etc... oui Sinon la bonne pratique est de pouvoir suivre qui fait quoi dans un système informatique en général. Si tu te fais pwn ton SI avec le compte "foo" : - Est-ce que c'est une personne en interne qui a mis le bazar ? (volontairement ou pas) - Est-ce que c'est une attaque externe via une faille dans l'application foo ? My 20 cents -- Nathan Delhaye

Le 25/03/21 à 21:13, Nathan delhaye <contact@nathan-delhaye.fr> a écrit :

Si tu t'assoie sur les pratiques Micro$oft, PCI/DSS, les reco de l'ANSSI (et probablement toutes les autres agences équivalentes à l'international), ISO 27001, etc... oui

Sinon la bonne pratique est de pouvoir suivre qui fait quoi dans un système informatique en général.

Je suis bien d'accord, mais là il s'agit de comptes d'applis, ceux qui peuvent y accéder sont bien identifiés et traçables. J'avoue ne pas comprendre l'intérêt d'obliger admin42 à se connecter à son compte admin42 pour faire ensuite du `sudo -u foo -i` et se retrouver sur le compte foo plutôt que de l'autoriser à se connecter directement sur le compte foo. Ok, on doit sûrement pouvoir interdire le sudo -i pour obliger ensuite à ce que toutes les commandes passent par sudo et soient loggées. Ici c'est moi qui ait décidé de mettre là le curseur flicage/simplicité, et je l'assume très bien ;-) (On parle d'une asso où le nb d'admins avec clés ssh se comptent sur les doigts d'une main, et ceux qui ont une clé pour se connecter à foo peuvent aussi passer root, voire mettre le host en rescue et y accéder)

Si tu te fais pwn ton SI avec le compte "foo" : - Est-ce que c'est une personne en interne qui a mis le bazar ? (volontairement ou pas) - Est-ce que c'est une attaque externe via une faille dans l'application foo ?

Y'a les logs déportés pour ça, facile de voir s'il y a eu un accès ssh à foo ou pas, quelles étaient les requêtes http qui ont précédé, etc. -- Daniel Il faut pleurer les hommes à leur naissance et non pas à leur mort. Montesquieu

Le 26/03/21 à 09:46, Maxime DERCHE <maxime@mouet-mouet.net> a écrit :

Laisse donc l'appli foo tourner en tant que user et groupe foo, et crée des comptes nominatifs qui appartiennent au groupe foo.

Mets les clefs SSH des gens dans l'annuaire LDAP, afin d'éviter d'avoir à gérer des déploiements d'accès à chaque mouvement dans l'équipe ou à chaque compromission d'accès.

On joue pas dans la même cour… Je bosse pour une asso, j'ai pas de ldap (la base des users c'est le /etc/passwd de chaque VM, ceux qui peuvent se connecter sont dans les ${userHome}/.ssh/authorized_keys, pas de password nulle part, la source de l'info est le host.yaml de mon ansible, pour répercuter d'éventuelles modifs partout). Les admins ayant des clés ssh c'est - moi - qq adminsys pompiers, d'astreinte à tour de rôle, qui peuvent se connecter si je suis pas dispo Et parfois y'a le dev de l'appli foo qui a une clé pour se connecter à son appli (c'est rare, en général s'il doit y accéder c'est du sftp sans shell). Donc pas près d'être ISO27001, ou ISOxxx, ou que sais-je, et ça tombe bien personne ne me l'a demandé ;-)

Ignorer ce travail c'est se penser meilleur que les normes : l'arrogance précède la chute.

Je suis évidemment moins malin et moins bon en sécurité que ceux qui ont pondus ces normes, je pense simplement qu'elles ne sont pas les plus pertinentes dans mon contexte. Et je ne pense pas que ce soit par arrogance, simplement du pragmatisme. -- Daniel Le carré est un triangle qui a réussi, ou une circonférence qui a mal tourné… Pierre Dac

Le 25/03/21 à 16:33, Jean-Yves LENHOF <jean-yves@lenhof.eu.org> a écrit :

C'est quoi ton besoin initial ?

- avoir zsh quand je me connecte sur ce user - laisser le shell du user pour les commandes passées par ssh (même s'il y a peu de risques il peut y avoir des scripts externes qui lancent des commandes prévues pour ce shell, je préfère ne pas y toucher) - laisser le shell du user pour les autres personnes qui se connecteraient en ssh à ce user Le user unix correspond à une appli, pour des tâches de maintenance ou de recueil d'infos, accéder aux logs applicatifs, ce genre de choses… C'est réglé avec, dans le ~/.ssh/authorized_keys du command="/path/to/login.sh" ssh-rsa …ma clé… et dans /path/to/login.sh #!/bin/sh if [ -t 1 ]; then exec /bin/zsh else $SSH_ORIGINAL_COMMAND fi -- Daniel Tout le monde est capable de créer un système incapable de fonctionner. Courteline

Le 25/03/21 à 19:31, SERRUT Arnaud <qqqrno@gmail.com> a écrit :

Pourquoi tu te fais pas un script côté client qui envoie automatiquement la commande zsh lorsque tu fais ton ssh ?

Effectivement, c'était une solution.

Plutôt que de vouloir faire ça côté serveur et risquer d'impacter tout le monde ?

Ben là j'ai trouvé une solution pour le faire coté serveur et n'impacter que moi. -- Daniel Rome a connu sous les Borgia 30 années de terreur, et ça a donné De Vinci, Michel Ange et la Renaissance. La Suisse a connu 500 ans de liberté, de fraternité et de démocratie, et qu'est ce que ça a donné ? L'horloge à coucou. Orson Welles, "Le troisième homme"

Le 26/03/21 à 10:10, Laurent Barme <2551@barme.fr> a écrit :

1 - Daniel nous soumet un problème super pointu auquel il est le seul à avoir pensé. 2 - On y réfléchi et on propose des solutions (aucune ne convient). 3 - Daniel ramasse les copies et nous donne la correction.

C'est justement d'en discuter ici qui m'a permis de trouver une réponse à la question initiale, (que je ne pensais pas spécialement pointue) en réfléchissant autour des solutions proposées. Et ce n'est pas une correction, preuve en est la discussion elle-même, montrant que le pb pouvait être dans le design des accès. Dans mon cas je continue à penser que c'est le plus pratique pour nous, mais remettre en question ses choix confort vs sécurité est toujours utile, merci à ceux qui ont donné leur avis. Désolé si la question initiale était sans intérêt…

Qu'est ce qu'il est fort Daniel !

J'avais plutôt l'impression que la discussion mettait en évidence de l'amateurisme sur la gestion des accès, mais je te laisse juge, j'ai passé l'âge de ce genre de concours ;-) -- Daniel On ne peut pas tout avoir. Où le mettrait on ? Steven Wright