Gestion de vos clefs SSH (et leur deploiement)

bonjour,

Je lance ce sujet car avec des infra.conséquente on en vient vite à des confusions etc … or confusion et clefs ssh : c’est pas trop bon.

Je suis en train de tester Bastillion.

Donc en solution libre :

  1. openSSH + Ansible (à l’ancienne quoi …),
  2. Bastillion (tourne avec Jetty/JDK, Bind ldap ok)
  3. FreeIPA (complexe ?!)

Vous utilisez quoi ?

Nous utilisons FreeIPA pour cela.

merci,
Mais ce n’est pas trop l’usine à gaz pour gérer les clefs ssh ?
(je veux dire par là , le bazooka pour écraser la mouche ?)

Cela dépend ce que tu veux faire. FreeIPA permet de gérer les accès et faire du HBAC ce qui est pratique lorsqu’il y a plusieurs équipes qui bossent sur une infra : ops, devops, dev…etc.

FreeIPA expose aussi un service LDAP ce qui peut être utilisé pour l’authentification sur d’autres outils (outil de monitoring, gitlab, …etc.) et même pour du SSO si on le couple avec Keycloak par exemple. Il offre aussi d’autres service comme un DNS interne que nous utilisons souvent.

Sinon tu peux gérer tout simplement les clés via un outil de provisioning tel qu’ansible.

Après l’avantage que je vois à Bastillion, c’est la simplification des règles pare-feu et de la segmentation réseau des accès VPN. Je n’ai pas eu encore l’occasion de le tester, est-ce qu’il permet de faire des choses comme du scp ? de faire du tunneling ? offre-t-il la possibilité de gérer les règles sudo?

1 « J'aime »

Jusqu’ici chez ARN on a un puppet pour ça. Mais je dois dire que je vais finir par tout passer sur ansible.

1 « J'aime »

La gestion de conf (puppet, Salt, etc.) ça fonctionne très bien, et c’est effectivement souvent moins lourd (et ça fait moins de spof) qu’un SSO pour l’administration.

Une piste complémentaire, qui peut soit s’intégrer avec de la gestion de conf, soit même directement avec un bête git ou rsync : AuthorizedKeysFile. Le principe, gérer en central la base de clés, et configurer le démon ssh avec par exemple un AuthorizedKeysFile /etc/ssh/keys/%u.

Plutôt que d’aller lire dans le homedir, sshd recherche la clé dans un dossier unique, qui peut être possédé et inscriptible uniquement par root, et géré en central.

1 « J'aime »

FreeIPA (crée son propre annuaire 389, sous licence … couci couça) ne fait il pas doublon avec Keycloak (il bind trés bien sur les annuaires lui aussi , mais ne gére pas SSH ouinnnnn)?

FreeIPA est sous licence GPL tout comme 389 Directory Server. Keycloak et FreeIPA ne répondent pas exactement aux mêmes besoins :

  • Keycloak est un IdM permettant de faire du SSO avec des applications web notamment via le protocoles OIDC, OAuth2 ou SAML.
  • FreeIPA est un système de gestion d’identités et de politiques d’accès orientées machines (accès ssh, règles sudo…). FreeIPA est construit autour d’un annuaire LDAP auquel des services complémentaires y sont pluggués comme un service DNS, un service de CA, …etc.

On peut donc être amené à coupler les deux via LDAP ou SSSD afin de couvrir un champ plus large : Accès machines + SSO sur les applications web.

Bien entendu, ces approches sont essentiellement adoptées sur des grosses infrastructures ou de grosses structures avec beaucoup d’utilisateurs. Cela simplifie la gestion day-to-day mais cela apporte aussi une couche de complexité qu’il faudra maintenir dans le temps.

Pour une infrastructure plus modeste, on peut très bien s’en sortir avec un outil de provisioning comme ansible.

merci pour tes conseils.
Le souci c’est qu’il a pas mal de developpeurs : 100 (on a des centaines de serveurs !!)
et 3 ou 4 d’admin … potentiel.
Mais par contre potentiellement plus de 4000 utilisateurs finaux (voir bcp plus !) pour aller sur des applications web.
Donc pour la partie SSh Ansible suffit … mais pour le binding applicatif : Freeipa ou Keycloak , that is the question ?

Du SSO avec Keycloak ne serait pas déconnant, Il faut cependant vérifier la compatibilité avec les protocoles supportés.

1 « J'aime »

J’aime bien keycloak.
FreeIPA par contre me fait peur ! (surtout avec la partie Active Directory)
Il lui faut son DNS, son royaume kerberos …
bref pour l’intégrer avec un Active Directory existant : faut serrer les miches !

je suis sur keycloak pour industrialiser le déploiement : c’est juste l’enfer Java (et j’ai fait du dev java) : comment ca peut encore exister des trucs aussi tordu ?
Là je veux installer le bouzin avec … une base Mysql : fallait pas , juste pas.
… ajouter les classe jdbc pour utiliser mysql : horrible expérience.

En gros ca ressemble à ca :
https://www.janua.fr/how-to-install-keycloak-with-mariadb/
(THE tartine)

En gros y’a des consoles de partout, des classes, modules en veux tu, en voila : et si par pas de chance celui que tu veux n’y est pas , c’est le grand huit assuré !
Rien que pour suivre le tuto il faut passer des heures à chopper les infos … et quand ca buggue (style un .jar pas à jour ) , çà devient l’enfer.
Et des conflits y’en a eu.
Sans parler du cache du navigateur : faut bosser en nav. privée.

J’imagine ceux qui foutent avec docker etc … : ils sont incapables de débogué quoique ce soit , pas possible autrement.

En gros quand ca marche t’es heureux , si ça merde : t’es mort !
Bref , ces belles solutions qui font tout en webgui, ben cela commence à bien me refroidir , j’avais eu un avant gout avec FusionDirectory. Je suis en train d’avoir la confirmation avec Keycloak … j’ose même pas imaginer FreeIPA !

FreeIPA fonctionne out of box sans souci particulier. Bien sur, il fonctionne mieux quand il est correctement packagé donc pas super top sous Ubuntu.

Sinon sous Docker cela semble être plus simple à configurer : https://github.com/keycloak/keycloak-containers/blob/master/docker-compose-examples/keycloak-mysql.yml

Merci pour l’info.
Mais Docker ca veut dire entrer dans un tout autre monde, celui de l’abstraction … total.
Ou alors c’est mon manque évident de connaissance sur docker, k8s qui me fait dire cela.