Lorsque j'ai appris à créer des clés ssh, les tutoriels que j'ai lus indiquaient tous qu'il fallait choisir une bonne phrase de passe. Mais récemment, lors de la mise en place d'un processus démon qui doit se connecter en ssh à une autre machine, j'ai découvert que la seule façon (semble-t-il) d'avoir une clé que je n'ai pas besoin d'authentifier à chaque démarrage est de créer une clé avec une phrase d'authentification vide. Je me demande donc quels sont les problèmes liés à l'utilisation d'une clé sans phrase d'authentification.
Réponses
Trop de publicités?Si vous souhaitez utiliser ssh pour effectuer une procédure automatisée - je pense en particulier aux contrôles Nagios - vous ne voudrez probablement pas utiliser de phrase de passe.
Dans ce cas, vous ne l'utiliserez probablement pas en dehors d'un réseau local et la clé sera stockée en toute sécurité sur le serveur qui exécute la procédure.
La plupart des tutoriels traitant de SSH prévoient qu'une personne se connectera à partir d'un réseau externe, éventuellement à partir d'un ordinateur non sécurisé, auquel cas le conseil est judicieux.
En principe, sauf si vous avez une bonne raison de ne pas le faire, créez une phrase de passe. Le fait d'être trop paresseux pour taper votre mot de passe à chaque fois peut être une raison suffisante pour vous :-)
certificats ssh
Un ~/.ssh/authorized_keys
permet d'accéder à un serveur SSH avec option d'attribution parce que dans la configuration par défaut, ce fichier appartient à l'utilisateur, qui peut donc ajouter les clés publiques de ses amis pour partager l'accès. De plus, il est laissé à la discrétion de l'utilisateur d'implémenter des options telles que celles mentionnées par @jrg. Le fait que l'utilisateur dispose ou non d'une phrase de passe n'est pas connu de sshd. Ainsi, quelle que soit votre opinion sur la sécurité de l'utilisation des phrases de passe, il y aura toujours des personnes qui ne les utiliseront pas ou qui les supprimeront.
Une alternative est un processus de signature avec ssh-keygen
qui crée une paire de clés de l'autorité de certification sur un système sécurisé indépendant de vos serveurs et clients ssh. Il s'agit simplement d'une paire de clés ssh, mais avec une phrase de passe, un algorithme fort et une protection contre la force brute :
ssh-keygen -t ed25519 -a 500 -f ~/.ssh/trusted-user-ca-keys
La clé publique de l'autorité de certification est installée sur les serveurs ssh. AuthorizedKeysFile et PasswordAuthentication sont désactivés :
TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pub
PasswordAuthentication no
AuthorizedKeysFile /dev/null
Le seul moyen pour accéder au serveur ssh est d'utiliser une clé publique signée. Toute personne ayant besoin d'un accès doit en faire la demande en envoyant sa clé publique à l'autorité de certification. En retour, elle reçoit un inviolable qui peut inclure des options telles que décrites dans man ssh-keygen
et, par exemple, une validité d'une semaine :
ssh-keygen -s ~/.ssh/ca_ssh -I user -O no-port-forwarding -O no-pty -V +1w user.pub
- Vous n'avez plus besoin de gérer les fichiers authorized_keys sur vos serveurs.
- Les utilisateurs ne peuvent pas modifier leur fichier authorized_keys.
- Vous pouvez effectuer une rotation des autorisations avec un accès temporaire.
- Vous pouvez verrouiller les options.
- Réponses précédentes
- Plus de réponses