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 Kerro . Évalué à 10.
On va avoir une pelletée d'implémentations trouées.
# Linux Mag et release notes
Posté par Krunch (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 barmic . É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 peikk0 . É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 Gilles DEHAUDT . É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 scullder . Évalué à 1.
Perso j'ai préféré tester pubkeyfs [1] pour éviter de patcher openssh, c'est un fs fuse, qui se bind sur ldap. On peut ensuite utiliser normalement la directive AuthorizedKeysFile (qui peut prendre plusieurs paramètres depuis openssh 5.9 [2])
[1] https://github.com/kelseyhightower/pubkeyfs
[2] http://www.openssh.com/txt/release-5.9
J'ai d'ailleurs un module puppet non publié pour pubkeyfs…
[^] # Re: LPK
Posté par Dabowl_75 . É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 dems . É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 barmic . É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 Cyrille Pontvieux (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 barmic . É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.