risque d'utilisation des clés publiques ssh

10

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

ssh

21

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.

— natacado
source

7

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

— jldugger
source

4

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)

— chris
source

Si vous utilisez LDAP, vous pouvez stocker la clé publique dans le répertoire, puis utiliser (correctifs OpenSSH-LPK) [ code.google.com/p/openssh-lpk/] - cela aide à résoudre le premier problème, bien que vous doivent maintenant créer et distribuer de nouveaux binaires SSH, l'avantage global peut être négatif.

— Zanchey

C'est intéressant, mais il semble que ce serait presque autant de travail que de configurer des kerberos.

— chris

2

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é.

— duffbeer703
source