Quelle est la différence entre authorized_keys et authorized_keys2?
Je voulais juste un bref résumé des différences entre eux et pourquoi il y en a deux?
Dans OpenSSH avant la version 3, la page de manuel sshd disait:
Le fichier $ HOME/.ssh/authorized_keys répertorie les clés RSA autorisées pour l'authentification RSA dans les protocoles SSH 1.3 et 1.5. De même, le fichier $ HOME/.ssh/authorized_keys2 répertorie les clés DSA et RSA autorisées pour l'authentification par clé publique ( PubkeyAuthentication) dans le protocole SSH 2.0.
annonce de publication pour la version 3 indique que authorized_keys2 est obsolète et toutes les clés doivent être placées dans le fichier authorized_keys.
L'utilisation de authorized_keys2 pour le protocole 2 a été déconseillée depuis 2001 .
[ via ]
À l'origine, la différence concernait la différenciation des versions.
Mais ne vous embêtez plus, comme maintenant le 2 peut être ignoré.
Une très bonne raison d'utiliser authorized_keys2 est si vous disposez d'un VPS avec Arvixe où l'équipe de support technique écrase continuellement votre authorized_keys fichier.
J'ai aussi aimé qu'il y ait un deuxième fichier authorized_keys.
J'utilise et distribue mon fichier de clés autorisées sur plusieurs ordinateurs, ce qui limite mon accès afin que seul mon domicile principal soit autorisé à se connecter à d'autres comptes. Mais cela signifie généralement que c'est la même chose sur tous mes comptes, et est écrasé s'il est différent. J'ai également vu d'autres programmes de configuration informatique l'écraser en continu (Puppet).
Cependant, lorsque je me connecte au nœud avant d'un grand cluster cumputing, j'aime mettre les clés dans le fichier authorized_keys2, afin que le nœud avant puisse accéder aux autres nœuds du cluster, mais n'a accès à aucune autre machine. c'est-à-dire que je l'ai utilisé comme un "fichier d'autorisation local", séparément d'un "fichier d'autorisation distribué".
Cela devient particulièrement important lorsque des maisons partagées sont utilisées (comme elles le sont généralement sur un cluster).
C'est vraiment dommage qu'il soit désormais amorti.
Une alternative qui serait Nice serait un mécanisme d'inclusion, ou un sous-répertoire "authorized_keys.d", ou un "utiliser ces clés pour cet hôte".