Je lis un article dans Master Linux Now 2013 appelé OpenSSH: Easy Logins et il utilise ssh-agent pour vous permettre d'entrer une fois une phrase secrète pour votre clé, puis vous pourrez vous connecter librement à une machine distante sans la retaper pendant que l'agent ssh est en cours d'exécution.
La raison pour laquelle j'ai été attiré par l'article en premier lieu, mis à part le fait de ne pas avoir à retaper mon mot de passe un million de fois ; était pour que je puisse faire des sauvegardes sans surveillance de/vers des machines distantes en appelant rsync depuis cron sur une machine distante du serveur via ssh ;
J'ai vu un autre article dans lequel quelqu'un a simplement sauté la phrase secrète afin que cron puisse facilement utiliser la clé pour se connecter, cela ne semble pas correct, mais est-ce acceptable de le faire dans la pratique ? Je veux dire que si quelqu'un mettait la main sur ce fichier clé, il pourrait faire des ravages sur la machine en cours de sauvegarde.
Il me semble qu'il serait plus sûr de s'assurer que l'utilisateur est connecté au redémarrage et de lui faire saisir la phrase secrète une fois, lorsqu'il se connecte pour faire fonctionner l'agent, puis d'attendre que le travail cron s'exécute avec l'écran verrouillé; mais il me manque probablement quelque chose ici, comme à propos de l'utilisateur ou des types d'utilisateurs avec lesquels les tâches cron s'exécutent.
Réponse acceptée :
Restreindre les commandes pouvant être invoquées par la clé
Si une clé SSH doit être utilisée par n'importe quel type de tâche automatisée ou sans surveillance, vous devez restreindre les commandes qu'elle est capable d'exécuter sur une machine distante, quelle que soit la décision que vous prenez sur comment et où stocker la clé.
Utilisez quelque chose comme ça dans ~/.ssh/authorized_keys :
command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAABBBBBXXXXXX.....
De cette façon, au moins la clé ne devrait pas pouvoir, comme vous le dites, faire des ravages. Il ne peut accéder qu'à ce à quoi il est censé accéder, etc. Il peut très probablement encore causer des dommages, mais il ne devrait pas avoir un accès total au système distant.
Vous pouvez également restreindre les adresses IP autorisées à se connecter à l'aide de cette clé et désactiver un ensemble d'autres fonctionnalités SSH, telles que le transfert de port pour les connexions où cette clé est utilisée :
from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX.....
Tout cela doit aller sur une seule ligne dans ~/.ssh/authorized_keys .
Protéger la clé
Cela dépend de votre modèle de menace.
Si vous craignez que la clé ne soit volée "à froid", par exemple, si l'ordinateur sur lequel elle est enregistrée est physiquement volé, vous ne voudrez pas l'enregistrer sans une phrase secrète à cet emplacement.
Vous pourriez démarrer une sorte d'agent SSH d'arrière-plan manuellement après le démarrage du serveur, ajouter la clé à cet agent et enregistrer le $SSH_AUTH_SOCK de l'agent pour une utilisation future par le travail cron, mais honnêtement, cela ressemble à plus de problèmes qu'il n'en vaut la peine. Vous pourriez tout aussi bien stocker la clé non chiffrée dans un tmpfs système de fichiers et que le travail cron y accède à partir de là. Dans tous les cas, la clé vit uniquement en mémoire (si vous n'avez pas d'échange ou d'échange chiffré). Bien sûr, vous devriez chown et chmod le fichier afin que seul l'utilisateur cible puisse y accéder.
Là encore, si cela vous inquiète, vous avez probablement déjà configuré cet ordinateur avec un système de fichiers racine chiffré et un swap (par exemple, luks), vous n'avez donc peut-être pas à vous en soucier en tant que tel.
Si vous craignez que la clé ne soit volée alors qu'elle est "chaude" (chargée en mémoire), vous ne pouvez pas faire grand-chose à ce sujet. Si la tâche cron peut y accéder, il en va de même pour quelque chose d'autre qui a réussi à obtenir le même accès. C'est cela, ou renoncez à la commodité de l'exécution de tâches sans surveillance.
En conclusion, vous devez traiter un serveur de sauvegarde comme un système très privilégié puisqu'il aura, par nécessité, un accès en lecture seule aux systèmes de fichiers complets de tous les ordinateurs qu'il sauvegarde. Votre serveur de sauvegarde ne doit pas être accessible depuis Internet, par exemple.