Journal AuthorizedKeysCommand

Posté par  . Licence CC By‑SA.
Étiquettes :
32
3
juin
2013

Bonjour Nal,
Pour mon premier journal, je voulais te partager une nouvelle feature d'OpenSSH que j'ai découvert en lisant le dernier Linux Mag, il s'agit de l'AuthorizedKeysCommand qui permet de déléguer la gestion des authorizedkeys à un script plutôt que de juste le comparer aux clés stockés dans le bien connu fichier ~/.ssh/authorized_keys.
Perso je trouve ça génial, parce que ça permet de facilement gérer les accès à nos chers serveurs sans avoir à mettre en place de mécanisme de copie de clé dans tous les sens et en gardant les avantages de l'authentification par clé.
Pour information, cette feature est disponible à partir de la version 6.2 d'OpenSSH.

Voici un lien vers un article qui me semble intéressant sur le sujet [http://www.sysadmin.org.au/index.php/2012/12/authorizedkeyscommand/]

Voilà mon premier journal est écrit, j'espère que je me suis pas trompé d'endroit pour partager ma découverte.

  • # Avalanche

    Posté par  . Évalué à 10.

    On va avoir une pelletée d'implémentations trouées.

  • # Linux Mag et release notes

    Posté par  (site web personnel) . Évalué à -9.

    Donc en fait la presse papier c'est fait pour les gens qui lisent pas les release notes. Tu peux trouver d'autres features récentes d'OpenSSH que tu as ratées par ici :
    http://openssh.org/txt/release-6.2

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Linux Mag et release notes

      Posté par  . Évalué à 7.

      LinuxFR c'est fait pour ceux qui ne s'informent pas à la source, il n'y a qu'à voir le succès des dépêches du noyau, de celles sur GCC ou bien du bi-annuel top500.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # LPK

    Posté par  . Évalué à 4.

    À noter que pour les clés stockées dans LDAP c'était déjà possible avant avec le patch LPK. Je l'utilise depuis des années sans aucun problème. :)

    • [^] # Re: LPK

      Posté par  . Évalué à 2.

      D'après ce que j'ai lu, il semblerait que ce patch ne soit plus maintenu. L'avantage de cette nouvelle solution est aussi de généraliser cette solution pour des personnes n'utilisant pas de LDAP

    • [^] # Re: LPK

      Posté par  . Évalué à 4.

      sauf que ce patch n'est pas remonté upstream, les dev semblent le refuser.

      Donc c'est pas pratique en production sur des systèmes où l'application de ce patch risque de casser le support (même si on s'en sert pas).

  • # Avantages par rapport aux certificats ?

    Posté par  . Évalué à 1.

    Perso, je pense que je préfère les certificats pour gérer les clés ssh.

    • [^] # Re: Avantages par rapport aux certificats ?

      Posté par  . Évalué à 2.

      Comme LPK c'est une solution qui reste en dehors de l'upstream donc forcément moins audité et avec moins de chances de pérennité.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Rien de neuf

    Posté par  (site web personnel, Mastodon) . Évalué à -3.

    C'est ce qui est utilisé par gitolite & co pour avoir une authentification sur ssh via clé publique avec un utilisateur unique, d'où les git@machinchose qu'on voit partout.
    Exemple avec mon petit code de gestion de dépôts git : http://git.enialis.net/gitweb/?p=simple-git-host.git;a=tree;f=homegit;hb=HEAD

    • [^] # Re: Rien de neuf

      Posté par  . Évalué à 3.

      Tu n'a peut être pas compris de quoi il s'agit. Le fait que git s'appuie généralement sur SSH pour l'authentification n'a rien de nouveau, le fait que celle puisse s'établir via un couple de clef privée/publique est antérieur encore à git. Là il s'agit juste de permettre une gestion plus flexible des clefs publiques grâce à l'utilisation d'une commande (qui peut aller chercher la clef publique sur un serveur LDAP, SQL, noSQL ou bien faire ce qu'elle veut).

      Les précédentes solutions comme LPK n'ont jamais étaient intégrées upstream.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

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