risque d'utilisation des clés publiques ssh

J'ai le serveur A et le serveur B (sauvegarde), et je me demandais, si quelqu'un s'introduit sur le serveur A, cela pourrait-il être potentiellement dangereux de pénétrer sur le serveur B si j'ai configuré une connexion sans mot de passe à l'aide des clés publiques ssh?

J'essaie de configurer rsnapshot.

Merci

Oui, c'est l'un des problèmes des clés SSH sans mot de passe. Si vous stockez une clé privée sur le serveur A qui vous permet de vous connecter au serveur B, l'accès au serveur A est effectivement l'accès au serveur B. (Ce n'est pas l'inverse qui n'est pas vrai - l'accès au serveur B n'entraînerait pas de compromis immédiat du serveur A, en supposant que vous n'avez pas non plus configuré de clés SSH pour autoriser les connexions sans mot de passe dans cette direction.

Il y a quelques choses que vous pouvez faire pour atténuer cela:

• Si le processus n'a pas besoin d'être entièrement automatisé, ajoutez un mot de passe à vos clés SSH. (Cela ne fonctionnera probablement pas pour vous, car vous notez que c'est pour une sauvegarde)
• Pour les connexions sans mot de passe sous votre propre compte à plusieurs machines, je recommande de créer une clé avec mot de passe pour chaque machine sur laquelle vous tapez physiquement et d'utiliser un agent SSH pour stocker la clé en mémoire pendant que vous l'utilisez. Le transfert d'agent devrait vous permettre de "sauter" d'hôte à hôte sans créer de clés sur chaque hôte distant.
• Pour les clés SSH automatisées et sans mot de passe, je recommande de restreindre les commandes que la clé peut exécuter. Dans votre authorized_keysfichier, préfixez chaque clé avec:
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

Il y a 8-9 ans, j'ai travaillé dans un environnement utilisateur partagé avec des centaines d'utilisateurs locaux, et les connexions basées sur les clés SSH ont été désactivées car il n'y avait aucun moyen d'appliquer des politiques de mot de passe sur les clés. Tant que vous contrôlez pleinement le scénario, de nos jours, les clés SSH sont nettement meilleures que l'utilisation de mots de passe.

Oui, la plupart des guides sur Internet arrêtent de faire fonctionner ssh sans mot de passe, plutôt que de le faire fonctionner en toute sécurité. Ce guide montre bien ce qui peut être fait pour réduire les risques. Fondamentalement (pour citer l'article):

• créer un compte de rôle à usage unique pour le travail: un utilisateur dnssyncsur chaque machine
• si possible, rendez les fichiers accessibles en écriture par cet utilisateur, plutôt que de vous fier à être root
• pour les bits qui ont vraiment besoin d'un accès privilégié, créez un script pour le faire et utilisez sudo
• utilisation command=et from=options dans les authorized_keysfichiers pour restreindre les clés sans phrase secrète
• pour effectuer le transfert de fichiers, écrivez un script pour le faire en utilisant rsync, sur la machine réceptrice , afin que l'accès à distance puisse être en lecture seule
• si cela signifie que l'accès à la machine initiatrice est nécessaire à partir de la machine distante, utilisez ssh-agentplutôt que de créer une deuxième clé sans phrase de passe

Il y a quelques problèmes avec les clés ssh:

Aucun moyen centralisé de révoquer une clé.

Aucun moyen d'appliquer des politiques de mot de passe sur les clés (votre clé privée est-elle chiffrée, et si oui, est-elle chiffrée avec un bon mot de passe?).

Ce sont les problèmes que Kerberos résout. Il en introduit d'autres, cependant, à savoir qu'il est plus complexe à mettre en œuvre et nécessite une véritable infrastructure de gestion des utilisateurs à déployer et à gérer.

Dans tous les cas, bien que ssh authorized_keys permette des attaques de type morris-worm , c'est toujours mieux que les services .r et telnet par miles (années-lumière)

Dans tous les environnements que j'ai contrôlés, j'ai toujours été un véritable adepte du minimum de privilèges possible pour les comptes de service.

Dans ce cas, je suggère de veiller à ce que le compte d'utilisateur sur le serveur distant ne soit autorisé à exécuter qu'un petit ensemble d'exécutables étroitement défini. Vous pouvez utiliser plusieurs comptes sur le côté distant et sudo pour y parvenir.

Même dans ce cas, vous êtes toujours soumis aux bogues locaux d'élévation de privilèges, alors soyez méticuleux et surveillez étroitement les bogues de sécurité.