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'

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)

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

:-)

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

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.

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.

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

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.

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 ;-)