authorized_keys)

Posté par ashmonger le 13 avril 2019 à 13:27. Licence CC By‑SA.

Étiquettes :

avr.

2019

Bon, je ne sais pas comment vous faites, mais après quelques temps dans une entreprise qui avait une idée assez originale pour la gestion et diffusion des clés SSH pour les accès aux serveurs (on fait des paquets debian qui s'installent avec Puppet, mais déployés tous les 36 du mois), je me suis dit qu'il fallait trouver autre chose.

Et là, le bas blesse. Soit je suis une quiche en recherche sur les internets, soit il n'y a pas d'outils pour faire ça (spécifiquement). Il n'était pas possible de changer le comportement de Puppet dans l'entreprise, ni de rajouter des outils qui auraient pu aider à déployer du paquet de clés (Ansible, Salt…).

N'étant pas dev, je me suis quand même sorti les doigts pour pondre un truc: Sakeyra/Akeyra

Sakeyra

C'est l'application serveur du duo, elle permet avec une interface web assez simple de créer des environnements (prod, recette, préprod), des utilisateurs locaux (root, maintenance, sauvegarde, toto) que l'on rattache à un environnements spécifique en précisant sa clé publique), des utilisateurs distants (avec nom/prénom, adresse email, clé ssh publique, liste des environnements autorisés), et des bundles de clés, qui permettent de faire l'association entre tous les éléments.

Akeyra

Chaque bundle (le plus récent par environnement) est disponible par un webservice à l'application cliente Akeyra qui va pouvoir le récupérer, mettre à jour les clés SSH publiques dans le fichier ~/.ssh/authorized_keys de chaque utilisateur local du bundle, et créer l'utilisateur local si celui-ci n'existe pas.

Infos supplémentaires

Le tout est fait en Python 3.5/6/7, avec Flask pour la partie webservice.

Hébergé sur Gitlab:
https://gitlab.com/LaMethode/akeyra
https://gitlab.com/LaMethode/sakeyra

Il reste encore pas mal de choses à faire (tests unitaires je vous maudis), mais l'application, client comme serveur sont actuellement utilisables et fonctionnels

Toute critique constructive et/ou rapport de bugs sur gitlab seront très grandement appéciés et me permettront d'améliorer le bouzin à terme.

# Via puppet directement

Posté par Ambroise le 13 avril 2019 à 13:59. Évalué à 7.

Je vais peut-être dire une bétise mais certain module puppet permettent d'installer les clés directement.

Au bureau, on utilise cela pour les serveurs RHEL qui sont gérés via notre Redhat Satellite…
- [^] # Re: Via puppet directement
  
  Posté par lolop (site web personnel) le 13 avril 2019 à 14:41. Évalué à 6.
  
  Idem dans mon labo, l'équipé admin-sys a des clés ssh automatiquement installées sur les postes sous Linux via la config puppet ad-hoc — et sans passer par un paquet debian intermédiaire.
  
  J'ai l'impression qu'il y a là plutôt un problème d'entreprise et de culture admin-sys que d'outils dispos…
  
  Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: Via puppet directement
    
    Posté par ashmonger le 13 avril 2019 à 15:12. Évalué à 1.
    
    Un problème d'entreprise, c'est certain.
    
    Quand on doit utiliser puppet comme on utilise ansible, et encore, c'est pas le pire.
    
    Mais je pensais aussi pour ceux qui n'ont ou ne veulent pas d'outils type Ansible/Puppet/Chef/Salt.
    
    Et pour répondre à Ambroise, la façon d'utiliser Puppet ne permet pas d'utiliser des modules de manière classique, je vais pas rentrer dans les détails, mais c'est compliqué.
    - [^] # Re: Via puppet directement
      
      Posté par Anonyme le 13 avril 2019 à 17:09. Évalué à 5.
      
      Et pour répondre à Ambroise, la façon d'utiliser Puppet ne permet pas d'utiliser des modules de manière classique, je vais pas rentrer dans les détails, mais c'est compliqué.
      
      Je veux bien des détails, parce que là comme ça, ça veut pas forcément dire grand chose.
      - [^] # Re: Via puppet directement
        
        Posté par ashmonger le 13 avril 2019 à 21:39. Évalué à 2.
        
        Pour faire rapide:
        
        Pas de manifeste par type
        
        Des Hiera par type (succints avec juste les modules) et par machines (avec justes les hostnames, ip, type)
        
        Puppet agent désactivé sur les machines et activé à la volée
        
        Génération des hieras par un outils "maison"
        
        Donc beaucoup de contraintes, parce que "c'est historique" et que même si ansible serait plus pertinent pour ceux qu'ils veulent faire, comme ils ont déjà du code puppet, bah on va pas gâcher.
        
        [^] # Re: Via puppet directement
        
        Posté par Anonyme le 14 avril 2019 à 16:50. Évalué à 3.
        
        Ah, c’est votre utilisation de Puppet qui pose problème en fait. J’avais compris que tu disais que Puppet, en soit, posait problème.
    - [^] # Re: Via puppet directement
      
      Posté par freem le 13 avril 2019 à 17:29. Évalué à 8.
      
      Mais je pensais aussi pour ceux qui n'ont ou ne veulent pas d'outils type Ansible/Puppet/Chef/Salt.
      
      Et donc, ils veulent pas utiliser d'outils rodés qui ne sont pas intrusifs sur les cibles (ansible ne nécessite pas d'agent) mais seraient disposés à passer par un soft purement expérimental développé par quelqu'un qui n'est pas accoutumé à implémenter des trucs (tu as dis ne pas être développeur, je n'invente rien)?
      
      Faudra m'expliquer la logique, la… Ou peut-être est-ce le cliquodrome qui manque?
- [^] # Re: Via puppet directement
  
  Posté par damaki le 13 avril 2019 à 19:33. Évalué à 2. Dernière modification le 13 avril 2019 à 19:33.
  
  Tout pareil avec ansible.
  Sinon, avec des VMs, cloud-init fait ça très bien sur tous les hyperviseurs.

# Certificats

Posté par Anonyme le 13 avril 2019 à 17:05. Évalué à 10.

Là où je bosse actuellement, on n’utilise plus de clef SSH à part sur nos bastions, pour tous les autres serveurs on utilise des certificats (Facebook décrit leur utilisation dans Scalable and secure access with SSH).

Ça permet de leur donner une validité assez courte, de segmenter en différentes zones (il faut faire signer un certificats différent pour se connecter en root sur les bastions ou en user sur un serveur web).

Sur mon infra perso, je rejoins le commentaire précédent, Puppet fait le taff :

class profile::base::users (
  Optional[String]  $root_password = undef,
  Optional[Hash]    $ssh_authorized_keys = undef,
) {
  user { 'root':
    home           => '/root',
    password       => $root_password,
    shell          => '/bin/zsh',
    comment        => "root@${facts['networking']['fqdn']}",
    purge_ssh_keys => true,
  }

  if $ssh_authorized_keys {
    create_resources(
      'ssh_authorized_key', $ssh_authorized_keys, { user => 'root' }
    )
  }
}

# bastillion (ex keybox)

Posté par redo_fr le 13 avril 2019 à 18:14. Évalué à 3.

Là où je travaille, nous utilisons 'keybox' (maintenant bastillion).
C'est un serveur de clefs ssh, on peut utiliser une authentification en deux étapes, créer des groupes de serveurs, lancer des scripts…

Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
- [^] # Re: bastillion (ex keybox)
  
  Posté par Pinaraf le 14 avril 2019 à 13:24. Évalué à 4.
  
  «Portability - Run SSH through the browser without requiring client software or browser plugins.»
  
  Heu, vraiment ? Comment tu fais passer des outils comme Ansible dans ce cas ?
# LDAP ?

Posté par Pinaraf le 14 avril 2019 à 13:22. Évalué à 10.

Je sais c'est has-been, c'est pas web devops tout ça machin… mais vous avez quelque chose contre LDAP ?
On stocke dans l'annuaire les utilisateurs, les clés publiques dans un attribut… et ça roule, avec la possibilité de gérer dans l'annuaire des restrictions d'accès par groupe de machine…

Et sinon ne pas remplir des authorized_keys locaux mais les récupérer dynamiquement depuis le serveur, comme ça y'a plus besoin de client qui maintienne les fichiers locaux ? (À la rigueur avec un cache local si le serveur devient injoignable, mais ça reste sujet à débat)
- [^] # Re: LDAP ?
  
  Posté par LaBienPensanceMaTuer le 15 avril 2019 à 11:13. Évalué à 2.
  
  Très bonne suggestion !
  
  Une utilisation du ~/.ssh/authorized_key local est adaptée à un petit parc de machine.
  
  Dès l'instant ou on doit gérer beaucoup de machines avec des updates régulières de ce fichier, alors il faut commencer à penser à utiliser d'autres solutions, plus adaptées.
  
  L'utilisation de LDAP est tout désignée dans ce cas !
  - [^] # Re: LDAP ?
    
    Posté par freem le 15 avril 2019 à 14:15. Évalué à 4.
    
    Une utilisation du ~/.ssh/authorized_key local est adaptée à un petit parc de machine.
    
    Dès l'instant ou on doit gérer beaucoup de machines avec des updates régulières de ce fichier, alors il faut commencer à penser à utiliser d'autres solutions, plus adaptées.
    
    Pas entièrement d'accord… gérer manuellement un authorized_keys local n'est pas adapté à un parc qui grossit ou qui évolue, mais rien n'empêche de le gérer avec ansible/rex (qui sont agentless) dans des parcs plus importants, à priori.
    Bon, ce n'est pas le plus efficace, certes, mais l'intérêt d'ansible/rex, c'est que, justement, pas besoin d'installer quoique ce soit sur la cible, ce qui du coup me fais un peu tiquer sur le "problème" de l'OP.
    
    Bon, dans le cas d'ansible, il faut python, qui est installé presque partout, mais quand même moins souvent que perl, qui est nécessaire pour rex: c'est la raison pour laquelle j'ai opté pour rex au taf, sur des systèmes pour lesquels il me faut minimiser le nombre de dépendances (et qui n'ont aucune raison actuelle d'utiliser python).
    Je serais bien partit sur cfengine3 (qui me ferait sauter pas mal de libs perls), mais c'est franchement compliqué de savoir comment le configurer, quels daemons servent vraiment à quoi et on besoin de quels autres… et avec le manque de temps, suis parti sur un agentless en me disant que je pourrais automatiquement passer à plus robuste et automatique le jour ou j'aurai mis en place tout le nécessaire… d'ici 2-3 siècles, avec du bol :D
    - [^] # Re: LDAP ?
      
      Posté par claudex le 01 mai 2019 à 11:40. Évalué à 3.
      
      mais rien n'empêche de le gérer avec ansible/rex (qui sont agentless) dans des parcs plus importants, à priori.
      
      Si tu dois retirer une clef corrompue rapidemment sur un gros parc, il vaut mieux LDAP qu'ansible qui va mettre un certain temps à refaire le tour de ton parc.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Kerberos ?

Posté par Donk le 14 avril 2019 à 13:46. Évalué à 6. Dernière modification le 14 avril 2019 à 13:46.

ou je m’égare?
- [^] # Re: Kerberos ?
  
  Posté par lolop (site web personnel) le 14 avril 2019 à 21:19. Évalué à 3. Dernière modification le 14 avril 2019 à 21:19.
  
  Vu que la façon d'utiliser puppet rend déjà les choses difficiles, Kerberos ne peux être qu'un égarement (idem pour LDAP juste avant).
  
  Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: Kerberos ?
    
    Posté par LaBienPensanceMaTuer le 15 avril 2019 à 11:15. Évalué à 7.
    
    Je trouve le concept de se dire "vu qu'on fait déjà les choses de façon très discutable, on va continuer comme ça et ne pas utiliser les outils adaptés" relativement saugrenu :)
  - [^] # Re: Kerberos ?
    
    Posté par barmic le 15 avril 2019 à 11:21. Évalué à 3.
    
    Quel différence tu fais entre Sakeyra/Akeyra et OpenLDAP/AuthorizedKeysCommand ? À part qu'il y en a un qui est développé par une communauté plus étoffée ? Qu'est-ce qui pousse à moins bien utiliser LDAP que Sakeyra ?
    - [^] # Re: Kerberos ?
      
      Posté par lolop (site web personnel) le 15 avril 2019 à 13:51. Évalué à 2.
      
      S'il est parti pour développer une solution à sa sauce au lieu de pouvoir prendre ce qui se fait partout ailleurs (ça pourrait être fait simplement en puppet), c'est qu'il y a un problème organisationnel/humain quelque part qui refuse ce qui se fait partout ailleurs — ils ont peut-être de bonnes raisons, c'est leur taf, leur choix, leur workflow, leur expérience, et ici on n'a pas le contexte.
      
      Proposer d'autres solutions qui se heurteraient au même problème est dans ce sens un “égarement” — seraient-elles même bien meilleures (et AMA elles le sont, au pire il aurait pu avoir à développer une appli frontale pour faciliter certaines configurations, mais ne pas se lancer dans l'aspect diffusion des clés sur les postes avec les risques importants pour la sécurité s'il se plante quelque part).
      
      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
      - [^] # Re: Kerberos ?
        
        Posté par freem le 15 avril 2019 à 14:19. Évalué à 3. Dernière modification le 15 avril 2019 à 14:19.
        
        Un workflow qui préfère accepter un code lié à la sécurité des postes implémenté par non développeur, moi, ça me fait peur quand même…
        
        Je n'ai pas plus de contexte que toi, mais outre le point précédent, j'ai l'impression que le soft présenté ici à été développé "par derrière", avant d'avoir l'approbation globale, du coup j'ai en plus un doute que ça finisse réellement par régler son problème, ou alors ça ne le réglera peut-être qu'a l'échelle de l'auteur et de ses "collègues proches".
        M'est avis que ça risque de plus ajouter au bordel ambiant qu'autre chose, in fine.
        
        [^] # Re: Kerberos ?
        
        Posté par lolop (site web personnel) le 15 avril 2019 à 15:06. Évalué à 2.
        
        Son application Sakeyra a des fonctionnalités qui pourraient être utiles lors du partage entre dev/test/prod et elle pourrait probablement générer les fichiers de conf puppet / ansibe / (mettre ici votre outil préféré) ou autre outil qui s'occuperait de la diffusion des clés — plutôt que de se bases sur son autre application Akeyra.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Kerberos ?
        
        Posté par freem le 16 avril 2019 à 22:30. Évalué à 3.
        
        Son application Sakeyra a des fonctionnalités qui pourraient être utiles lors du partage entre dev/test/prod
        
        Il te faudrait citer lesquelles, l'auteur est justement en recherche d'idées de ce genre.
        
        les fichiers de conf puppet / ansibe / (mettre ici votre outil préféré)
        
        Le projet semble quand même vachement plus orienté "boîte avec procédures de merdes voire inexistantes qu'il faut contourner". Du coup, je miserais plutôt sur les outils agent-less, qui ont le mérite de ne nécessiter aucune installation sur les cibles.
        
        ou autre outil qui s'occuperait de la diffusion des clés
        
        Je suis triste que l'outil se concentre juste sur la gestion des clés SSH… réinventer la roue, sans même avouer faire du NIH, juste pour gérer un inventaire de clés? Vraiment, il n'y avais pas mieux? Pour une fois, je suis contre la naissance d'une alternative, parce qu'elle en fait vachement moins que les autres, et sans avantages supposés autres que le NIH.
        
        plutôt que de se bases sur son autre application Akeyra.
        
        Ça, OK pour moi, une interface web a des outils agent-less pourrait être une vraie plus-value, pour moi, dans le sens ou je n'en connaît aucune. Notes bien, je ne dis pas qu'il n'en existe aucune, juste, je n'en connaît aucune.
        Si je pouvais pousser un peu mes rêves, et un truc qui me ferait étudier sérieusement l'usage, une interface HTTP compatible curl/lynx serait, au final, même un truc ou je pourrait même investir du temps. Ça me permettrait de convaincre facilement les devs qui m'entourent d'adopter ce genre d'outils, avec les conséquences néfaste qui en résulteront, mais je suis prêt à les supporter.
        Faudrait encore que les côtés scriptable et reproductibles soient des objectifs avoués du projet, ce que je n'ai pas cru remarquer.
        
        Je suis pas admin, mais je suis le seul de ma boîte a qui l'on fait confiance pour gérer des tâches que seul un vrai admin saurait gérer efficacement… en plus de mes tâches de dev, et, vu que je suis le "meilleur", on me file même des trucs de communication… avec des marketeux qui n'écrivent ni ne parlent anglais (ou autres langue que je gère un tant sois peu)… j'ai sûrement encore vérifié le principe de peter….
        
        Mea culpa pour les derniers paragraphes en mode pleurs…
        
        [^] # Re: Kerberos ?
        
        Posté par Hotshot92 le 09 mai 2019 à 11:22. Évalué à 1.
        
        Un workflow qui préfère accepter un code lié à la sécurité des postes implémenté par non développeur, moi, ça me fait peur quand même…
        
        Effectivement ! Dans son authentification, il vérifie en premier si l'utilisateur est dans la base et répond « utilisateur inconnu » en cas d'échec. Erreur classique de débutant…
        Pour les fonctions liées à la sécurité, ne jamais se baser sur du code maison.
# AuthorizedKeysCommand

Posté par Joris Dedieu (site web personnel) le 15 avril 2019 à 08:54. Évalué à 8.

sshd peut récupérer les clés en utilisant une AuthorizedKeysCommand.

Par exemple avec sssd https://linux.die.net/man/1/sss_ssh_authorizedkeys
- [^] # Re: AuthorizedKeysCommand
  
  Posté par Nodeus le 24 avril 2019 à 22:57. Évalué à 0. Dernière modification le 24 avril 2019 à 23:01.
  
  tu peux détailler car le man est un peu succin.
  
  si j'ai compris tout ça tu peux ajouter une commande dans ton sshd config
  
  AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
  
  mais à partir de quelle version de ssh et est ce disponible sur toutes les distribs?
  - [^] # Re: AuthorizedKeysCommand
    
    Posté par Joris Dedieu (site web personnel) le 26 avril 2019 à 02:08. Évalué à 4.
    
    Tu précises dans le sshd_config la commande que tu veux exécuter, il suffit qu'il retourne une ou plusieurs clés au format texte habituel (comme dans le fichier authorized_keys) ou aucune bien sûr.
    
    La commande est soit exécutée par l'utilisateur qui tente d'ouvrir la session, soit par celui précisé dans AuthorizedKeysCommandUser. Tu peux passer des arguments au script selon le format habituel de sshd_config (%u …).
    
    C'est supporté par openssh depuis la 6.1, partiellement par rhel6 (qui ne connait pas AuthorizedKeysCommandUser ce qui fait penser a une intégration arrivé) et par debian depuis au moins Jessy.
    
    IMHO l'avantage sur un parc important est la rapidité avec laquelle on peut publier ou supprimer une clé.
    
    Typiquement avant on faisait ça avec puppet, mais le volume de changements, le nombre d'intervenants et l'exigence de validation du code fait qu'un changement met en moyenne une semaine a arriver partout. Ce qui est inadapté pour un référentiel de compte.
    Nous gérons tout ça avec freeipa / sssd. Ça marche sur centos, debian, freebsd et ça permet aussi de faire du Kerberos.
    
    Dans le cadre de ton software tu peux très bien imaginer un script qui récupère le nom de l'utilisateur courent et lance un curl. Tu peux même gérer un cache local assez simplement
    - [^] # Re: AuthorizedKeysCommand
      
      Posté par Nodeus le 26 avril 2019 à 08:11. Évalué à 1.
      
      Merci pour cette réponse didactique et détaillée
# Vault de HashiCorp

Posté par Arnal le 15 avril 2019 à 12:38. Évalué à 2.

Bonjour,
Lors d'une discussion on m'a orienté vers https://www.vaultproject.io/ je ne l'ai pas testé mais il pourrait peut être répondre ?

Bonne journée
# Commentaire supprimé

Posté par Shivam1 le 25 avril 2019 à 12:45. Évalué à 0. Dernière modification le 25 avril 2019 à 13:11.

Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.