La key d'un job cron qui s'exécute automatiquement sur ssh ne doit-elle pas avoir une phrase secrète?

Je lis un article dans OpenSSH: Easy Logins dans Master Linux Now 2013 et il utilise ssh-agent pour vous permettre d'entrer une phrase secrète pour votre key une seule fois, puis vous pouvez vous connecter librement à une machine distante sans la taper à nouveau 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, en dehors de ne pas avoir à retaper mon mot de passe un million de fois; était de sorte que je pourrais faire des sauvegardes sans surveillance de / vers des machines distantes en appelant rsync de cron sur une machine à distance au server sur ssh;

J'ai vu un autre article où quelqu'un a simplement sauté la phrase de passe afin que cron puisse facilement utiliser la key pour se connecter, cela ne semble pas correct, mais est-ce correct dans la pratique? Je veux dire que si quelqu'un se saisissait de ce file key, ils pourraient faire des ravages sur la machine sauvegardée.

Il me semble plus sûr de s'assurer que l'user est connecté lors du redémarrage et de leur requestr de saisir la phrase secrète une fois, lorsqu'ils se connectent pour que l'agent soit en cours d'exécution et attendent que le travail cron s'exécute avec l'écran verrouillé. mais il me manque probablement quelque chose ici, comme à propos de l'user ou des types d'users avec lesquels les tâches cron sont exécutées.

Restreindre les commands pouvant être invoquées par la key

Si une key SSH doit être utilisée par n'importe quel type de tâche automatisée ou non, vous devez restreindre les commands qu'elle peut exécuter sur une machine distante, quelle que soit la décision que vous avez prise sur comment et où stocker la key.

Utilisez quelque chose comme ceci dans ~/.ssh/authhrized_keys :

 command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX.....

De cette façon, au less la key ne devrait pas pouvoir, comme vous le dites, faire des ravages. Il ne peut accéder qu'à ce qu'il est censé accéder, etc … Il peut très probablement causer des dommages, mais il devrait avoir un access inférieur au plein access au système distant.

Vous pouvez également restreindre les adresses IP autorisées à se connecter à l'aide de cette key et désactiver un set d'autres fonctionnalités SSH, comme le transfert de port pour les connections où cette key 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 ce qui doit aller sur une seule ligne dans ~/.ssh/authorized_keys .

Protéger la key

Cela dépend de votre model de menace.

Si vous craignez que la key ne soit volée pendant que vous «avez froid», par exemple, si vous avez physiquement volé l'ordinateur sur lequel vous avez été physiquement volé, vous ne voudrez pas l'save sans mot de passe à cet endroit.

Vous pouvez démarrer une sorte d'agent SSH d'arrière-plan manuellement après le démarrage du server, append la key à cet agent et save le $SSH_AUTH_SOCK de l'agent pour une utilisation future par le travail cron, mais honnêtement cela semble plus problématique que cela en vaut la peine. Vous pouvez tout aussi bien stocker la key non chiffrée dans un système de files tmpfs et faire en sorte que le travail cron y accède. De toute façon, la key ne vit que dans la memory (si vous n'avez pas de swap ou de swap crypté). Bien sûr, vous devriez chown et chmod le file afin que seul l'user cible puisse y accéder.

Là encore, si vous êtes inquiet à ce sujet, vous avez probablement déjà installé cet ordinateur avec un système de files racine crypté et swap (par ex. Luks) afin de ne pas vous en soucier.

Si vous êtes inquiet au sujet de la key volée pendant que "chaud" (chargé dans la memory) alors il n'y a pas grand-chose que vous pouvez faire à ce sujet. Si le travail cron peut y accéder, alors peut-être quelque chose d'autre qui a réussi à get le même access. C'est cela, ou renoncer à la commodité de l'exécution des tâches sans surveillance.

En conclusion, vous devriez considérer un server de sauvegarde comme un système très privilégié puisqu'il sera, par nécessité, donné un access en lecture seule aux filesystems complets de tous les ordinateurs qu'il sauvegarde. Par exemple, votre server de sauvegarde ne doit pas être accessible depuis Internet.