83 votes

Dois-je avoir une phrase de passe pour ma clé SSH RSA ?

Avant de commencer mon travail actuel (dans une petite entreprise), mon bureau n'avait pas de pare-feu sur le réseau et rien n'était jamais sauvegardé. Maintenant que j'ai signé en tant qu'administrateur système dédié / département informatique unique, je fais ce que je peux pour changer cela. Après avoir expliqué à mon patron à quel point nous étions vulnérables, il m'a autorisé à mettre en place des serveurs de sauvegarde, dont l'un se trouve chez lui.

En ce moment, j'essaie de tout configurer pour pouvoir automatiser les sauvegardes quotidiennes. J'envisage d'utiliser rsync via ssh pour ce faire. Pour des raisons de sécurité et pour faciliter l'automatisation, je prévoyais de désactiver la connexion par mot de passe ssh et d'utiliser uniquement la validation par clé rsa. Or, si j'ai défini une phrase de passe rsa, je devrais toujours entrer un mot de passe, ce qui pose problème.

Le fait de ne pas avoir de phrase de passe rsa rend-il les choses beaucoup moins sûres ? Je suis la seule personne dans la société qui a une sorte d'idée sur ce genre de chose, donc je ne suis pas trop inquiet que quelqu'un appelle un terminal sur ma machine (qui est toujours verrouillée lorsque je suis AFK, de toute façon) et ssh-ing dans l'un des serveurs de sauvegarde et de faire des dégâts. Je suis encore très, très nouveau dans le monde de l'administration de systèmes, et c'est la première fois que je fais quelque chose comme ça, et je ne veux pas laisser de trous dans la configuration de sécurité.

Les ordinateurs en question fonctionnent sous Ubuntu 10.10, SME Server et OSX 10.6, si cela peut faire une différence.

102voto

Pricey Points 4504

Comme vous le savez, l'avantage de la phrase de passe est que si quelqu'un est capable de lire votre clé privée, il ne peut pas l'utiliser.

Si quelqu'un est capable d'accéder à cette clé privée, vous devez considérer comme acquis qu'il a accédé aux machines configurées avec la clé publique ou qu'il les a compromises. Des éléments comme .bash_history ou .ssh/config ne font que faciliter les choses, même si votre .ssh/known_hosts est obscurci.

Ne pas avoir de mot de passe sur votre clé n'est pas la fin du monde, voici 3 idées pour essayer et vous aider à vous sécuriser un peu mieux malgré cela. ( Le plus important est le deuxième, lisez-le au moins une fois. )


  1. Ne vous contentez pas d'utiliser la même clé pour toutes les machines et tous les utilisateurs. Générez chaque utilisateur sur chaque machine (qui a besoin de faire ce genre de choses) sa propre paire de clés. Cela vous permettra de garder un contrôle fin sur ce qui est capable de ssh où.

  2. Lorsque vous ajoutez la clé à votre fichier authorized_keys, vous pouvez la verrouiller pour qu'elle ne puisse exécuter qu'une commande spécifique, ou l'utiliser uniquement à partir d'un hôte spécifique.

    Voir man ssh et chercher commande= y de=

    La syntaxe est quelque chose comme :

    from="1.2.3.4",command="/path/to/executable argument" ssh-rsa key name

    c'est-à-dire ajoutez-y 'rsync' et uniquement rsync' pourrait être appelé par votre clé, et seulement de l'adresse IP 1.2.3.4. Les adresses IP multiples peuvent être séparées par , . Les noms d'hôtes sont également pris en charge.

  3. Une autre chose qui me vient à l'esprit est la directive "AllowUser" dans votre sshd_config.

    AllowUsers

    Ce mot-clé peut être suivi d'une liste de modèles de noms d'utilisateurs, séparés par des espaces. S'il est spécifié, la connexion n'est autorisée que pour noms d'utilisateur qui correspondent à l'un des modèles. Les caractères '*' et ' ? être utilisés comme jokers dans les modèles. Seuls les noms d'utilisateurs sont valides ; un ID utilisateur numérique n'est pas reconnu. Par défaut, le login est autorisée pour tous les utilisateurs. Si le motif est de la forme USER@HOST alors USER et HOST sont vérifiés séparément, ce qui limite l'ouverture de sessions à des utilisateurs particuliers depuis des hôtes particuliers.

    Cela garantit essentiellement que l'utilisateur ne peut se connecter qu'à partir d'un certain endroit. (bien qu'il accepte également les caractères génériques). Cela ne résoudra pas tous vos problèmes, mais cela rendra au moins les choses plus difficiles pour les autres.

4voto

Faheem Mitha Points 450

Vous pouvez utiliser quelque chose comme porte-clés pour rendre l'utilisation d'une phrase de passe moins pénible. Cette solution est légèrement plus sûre que l'utilisation d'une connexion sans mot de passe, et peut être utilisée en combinaison avec les autres réponses données ici. La réponse de PriceChild était plutôt bon.

-4voto

Majenko Points 31077

Personnellement, j'utilise DSA et non RSA, principalement parce que c'est ce que j'ai toujours utilisé et que je sais que cela "fonctionne", mais la théorie est la même, je suppose. Vous pourriez remplacer dsa avec rsa dans le ci-dessous.

Sur la source :

$ ssh-keygen -t dsa

Ensuite, copiez le contenu du fichier .ssh/id_dsa.pub dans .ssh/authorized_keys dans le compte utilisateur sur la destination.

Vous devriez alors être en mesure d'effectuer un ssh entre la source et la destination sans mot de passe.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X