Puis-je utiliser une clé SSH avec une phrase secrète vide?

Quand j'ai d'abord appris à créer des clés SSH, les tutoriels que j'ai lus indiquaient tous qu'une bonne phrase secrète devait être choisie. Mais récemment, lors de la configuration d’un processus démon devant ssh sur une autre machine, j’ai découvert que le seul moyen (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 un phrase secrète. Ma question est donc la suivante: quelles sont les préoccupations liées à l’utilisation d’une clé sans phrase secrète?

Une clé sans phrase secrète est tributaire du fait que personne d'autre ne puisse accéder à cette clé (qui ne pourrait pas accéder aux ressources auxquelles elle donne accès de toute façon). Donc, si la clé donne accès à une machine adjacente et que les deux machines ont le même niveau de sécurité physique et électronique, alors ce n'est pas vraiment grave.

D'autre part, si votre clé se trouve sur une machine peu sécurisée (peut-être qu'elle compte de nombreux utilisateurs non fiables, qu'elle est facilement accessible physiquement ou qu'elle n'est pas bien mise à jour avec son régime de correctifs), alors vous ne le faites probablement pas. Je ne veux pas garder les clés sans phrase de passe là-bas.

En fin de compte, il en va de la confiance dans votre configuration et de l’évaluation des risques / coûts, si vous pouvez être assez confiant pour dire qu’il n’est pas réellement réaliste pour un attaquant d’avoir accès à la clé plutôt qu’à la ressource à laquelle la clé vous donne accès. , alors vous allez bien. Si vous n’avez pas cette confiance, vous devriez probablement en fixer les raisons :)

Une autre solution, renforcer la sécurité tout en vous simplifiant la tâche, vous évitant ainsi de saisir votre mot de passe à tout moment:

Si vous souhaitez chiffrer votre clé privée, vous pouvez utiliser ssh-agentsur votre poste de travail pour «mettre en cache» la clé non chiffrée. lorsque vous souhaitez stocker votre clé déchiffrée, vous exécutez ssh-add ~/.ssh/id_rsaou quel que soit le nom de votre clé privée. le mot de passe vous sera demandé et la clé déchiffrée sera disponible pour vos connexions SSH jusqu'à ce que vous vous déconnectiez, que vous mettiez fin à vos activités ou que vous vous ssh-agentarrêtiez.

vous pouvez utiliser killles clés stockées avec ssh-agent -ket vous pouvez attribuer une durée de vie pour que la clé soit en mémoire avec ssh-agent -t [seconds]ainsi par exemple; Si vous ne voulez pas garder votre clé déchiffrée pour toujours, mais que vous voulez faire beaucoup de ssh-ing autour de vos hôtes, vous pouvez définir un délai d'expiration de 5 à 10 minutes. vous n'avez donc pas à saisir en permanence le mot de passe de votre clé.

encore une fois, tout cela a à voir avec votre confiance en la sécurité de votre / workstation /, qui, si vous êtes le seul à y avoir accès, et que vous avez un mot de passe local assez sécurisé, et vous ne le faites pas. invitez des exploits et des rootkits sur vous-même, votre clé privée sans phrase secrète est raisonnablement sécurisée.

si vous êtes comme moi et que vous gardez votre clé privée sur une clé USB, vous allez certainement vouloir la chiffrer, même s'il ne s'agit que d'une clé privée (une clé distincte que j'utilise sur mon poste de travail, donc si je perds ma clé, je peux facilement supprimer la clé publique de la clé USB de la ~/.ssh/authorized_keysliste de mon serveur , ce qui entraîne également une / excellente / raison d'ajouter des commentaires UTILES à vos clés publiques)

Dans votre réponse à une réponse précédente, vous avez indiqué que seules les personnes de confiance ont accès à la machine avec les clés. Je tiens simplement à préciser que votre clé privée NE doit PAS obligatoirement se trouver sur le serveur auquel vous vous connectez, au cas où vous le feriez. seule votre clé publique doit être sur le serveur, ce qui ne pose aucun problème, raison pour laquelle il s'agit d'une clé "publique".

oh, j'ai oublié de mentionner; Je lance ssh-agentquand je lance X, sinon les clés décryptées que je stocke avec ssh-addne sont pas conservées au cours de xtermsessions différentes , et je dois ressaisir le mot de passe chaque fois que je ferme le xtermi lancé ssh-adddans. Dans mon ~/.xinitrcdossier, j'ai:

if [ -x /usr/bin/ssh-agent ]; then
   eval $(/usr/bin/ssh-agent)
fi

J'ai l'appel à être ssh-agentintégré evalcar ssh-agent renvoie certaines variables d'environnement qui doivent être définies lors de son exécution et s'exécutent à partir de ~/.xinitrc, les variables d'environnement sont constantes tout au long de la session X.

Vous pouvez consulter une question similaire que j'ai posée à propos des clés privées SSL pour les serveurs Web. Fondamentalement, il y a trois options:

1. Protégez la clé avec les permanentes du système de fichiers.
2. Utilisez une clé protégée par mot de passe et entrez-la manuellement à chaque redémarrage.
3. Utilisez une clé protégée par mot de passe et stockez-la dans le système de fichiers pour automatiser le redémarrage.

Chacun d'entre eux est défectueux, donc tout dépend de ce que vous craignez le plus.

Pour un accès automatisé, qui, comme vous le dites, nécessite des clés sans phrase secrète, j’utilise toujours les options supplémentaires de allowed_keys (voir sshd (8)) pour limiter la commande pouvant être exécutée.

D'habitude, je fournis un script soigneusement écrit à l'extrémité distante, qui effectue exactement le travail (ou les travaux - il peut examiner les paramètres) que je souhaite être autorisé.

Ensuite, je le verrouille également aux adresses IP pouvant se connecter avec cette clé (pas à 100% infaillible, mais très bien avec la restriction de commande également.)

Tant que personne d'autre que vous n'a accès à la clé, vous n'avez pas besoin de phrase secrète. En fait, vous ne pouvez pas utiliser de phrase de passe sur les clés utilisées par un logiciel automatisé.

Si vous souhaitez utiliser ssh pour effectuer tout type de procédure automatisée (je pense en particulier aux contrôles Nagios), vous ne voudrez probablement pas utiliser de phrase secrète.

Dans cette situation, vous ne l'utiliseriez probablement pas en dehors d'un réseau local et la clé serait stockée de manière sécurisée sur le serveur effectuant la procédure.

La plupart des tutoriels traitant de SSH anticiperont une personne se connectant depuis un réseau externe, éventuellement depuis un ordinateur non sécurisé, auquel cas les conseils sont judicieux.

Fondamentalement, à moins que vous ne sachiez qu'il existe une bonne raison de ne pas créer de phrase secrète. Être trop paresseux pour taper votre mot de passe à chaque fois peut être une raison suffisante pour vous :-)