Automatiser mes backups à travers ssh avec un clef privée chiffrée

Discuss Advanced use case
1

Bonjour ! :smiley:

TL ; DR : Je souhaite automatiser des backups sur un serveur distant avec borg. Pour cela, je m’y identifie par clef via SSH. Mais il me faut déchiffrer ma clef à chaque backup. Pour l’instant, je le fait en lançant ssh-agent et en ajoutant la clef manuellement après chaque démarrage. Quelle est la meilleure façon de complètement automatiser ce process ?

Je backup mon serveur avec borg, installer et configuré moi-même. Au cœur de mon script, la commande suivante crée mon backup journalier :

borg create --remote-path $REMOTE_BIN \
$(for dir in $EXCLUDE_DIRS; do echo "--exclude $dir"; done) \
$REPOSITORY::$ARCHIVE_NAME /

Problème : cette commande à besoin du mot de passe de ma clef privée pour s’identifier via ssh. Pour l’instant, je dois manuellement lancer ssh-agent à chaque fois que je démarre mon serveur, et y ajouter ma clef :

$ eval "$(ssh-agent -s)"

ssh-add

Je crains de finir par oublier de faire ça systématiquement. Le principe d’automatiser ces backup, c’est d’éviter de se retrouver à risquer d’oublier ce genre de choses…

J’ai cru comprendre que je pouvais simplement ne pas chiffrer ma clef, mais stocker sur un disque une clef privée non chiffrée donnant accès à mon serveur de backup me semble une très mauvaise idée.

Je comprends qu’on ne peut pas faire de magie, et que si le serveur redémarre et que la clef n’est disponible que chiffrée sur le disque, il faudra bien la déchiffrer d’une manière ou d’une autre. Mais peut-être que je passe à côté de quelque chose…

Bref, quelle est la meilleure manière de vraiment automatiser ces backups ? A défaut, est-il possible d’automatiser une alerte mail me rappelant de déchiffrer ma clef quand le script échoue ?

Merci pour ta lecture attentive jusqu’ici :heart:

P.S. :rage: : J’ai récupérer comme server de backup un vieux NAS Synology. L’OS de ce dernier à la bonne idée d’accorder les connection SSH exclusivement aux utilisateur admin, de manière visiblement impossible à configurer autrement. Mon accèss en ssh est donc un accès avec un compte sudoer, quelle merveille de sécurité !

2

Salut PP44,

La seule vraie solution à ton problème c’est une solution hardware sur ton serveur, par exemple un module TPM ou equivalent. Les paires de clés sont générées dans le module et la clé privée n’en sort jamais: toutes les opérations qui utilisent la clé privée (signature, encryption) sont éxécutées dans le module sécurisée.

En l’absence de solution hardware la seule solution qui te reste, comme tu l’as bien vu, c’est de stocker la clé privée en clair sur ton serveur pour qu’elle soit utilisable au redémarrage. Tu peux limiter les risques en réglant les permissions au plus fin pour que uniquement les applications qui ont besoin de la clé y ait accès, mais ça reste un compromis.

1 Like
3

En même temps si un attaquant obtient un accès à ta machine, y’a de grande chance qu’il puisse aussi juste lire la clef stockée en RAM … certes c’est un poil plus compliqué que lire un fichier sur le disque, mais le gain réel de sécurité n’est pas révolutionnaire comparé à la complexité que ça rajoute …

2 Likes
4

Merci beaucoup pour ta réponse ! J’ai du mal à voir la différence puisque si quelqu’un obtient l’accès à ma machine, il peut alors faire signer quoi que ce soit par le “module”, non ? (Je ne connais pas, mais j’imagine que ça se présente comme un périphérique USB genre Yubikey ?)

5

Merci !

Ok donc je pense que je vais faire ça.

Dernière question : est-ce que dans ce cas c’est grave d’utiliser la clef “par defaut” ? Parce que je n’arrive pas à trouver comment préciser une clef dans la commande borg…

6

Oui tu as raison, si quelqu’un obtient un accès root à ta machine, c’est game over de toute façon. Les modules de type TPM à la base ont été conçus pour la gestion des droits sur les fichiers numériques (piratage de logiciels et de MP3 à l’époque), et vendus comme un amélioration de la sécurité. En fait ça améliore bien la sécurité, mais surtout pour le bénéfice de Microsoft et des ayant-droits des fichiers, pas vraiment pour le propriétaire du PC…

1 Like
7

Pour finir: pour des applis Cloud il y a des services dédiés pour stocker les secrets, comme AWS Secrets Manager our Azure Key Vault. Mais on en revient au même problème: si l’attaquant a le contrôle de ta machine, il peut faire l’appel à l’API qui va bien pour obtenir le secret.

Comme toutes les machines virtuelles sont reliées à un compte utilisateur chez le fournisseur Cloud, elles reçoivent un contexte de sécurité au démarrage ce qui leur permet de s’authentifier auprès du service de gestion des secrets. Pas la peine d’être là au redémarrage pour taper le mot de passe!

1 Like