88 votes

Comment stocker les clés SSH ?

J'ai commencé à utiliser des clés SSH au lieu de mots de passe tout récemment (grâce à GitHub, bien sûr), alors gardez à l'esprit que je suis assez nouveau dans ce concept. Actuellement, mes clés se trouvent simplement dans ~/.ssh, mais je ne suis pas sûr que ce soit une bonne pratique. Par exemple, si j'ai plusieurs machines, je devrais dupliquer mes clés privées, ce qui n'est pas souhaitable. Ou, si mon disque dur tombe en panne, je perdrai ces clés, ce qui (je suppose) n'est pas souhaitable non plus.

Quelles sont donc les meilleures pratiques pour stocker les clés SSH de manière sûre, pratique et fiable ?

Il semble que l'utilisation d'une carte à puce soit une option (voir Cartes à puce pour le stockage des clés gpg/ssh (Linux) - de quoi ai-je besoin ? ), est-ce le meilleur ?

Mise à jour : La raison de la question était que de nombreux services (comme GitHub, AWS EC2) fournissent des guides sur la façon de configurer les clés SSH pour l'utilisation du service, mais peu ou pas de contexte (comme, que faire si vous avez déjà une clé générée par ssh-keygen [1], quelles sont les mesures de sécurité recommandées). Et il n'est pas clair si ces informations sont en fait sans importance, ou si vous êtes censé les connaître "par défaut".

Pour résumer les réponses jusqu'à ce point (mais lisez-les s'il vous plaît, et si vous avez quelque chose à ajouter, faites-le) : il semble que dans ce cas, il n'y ait pas de problème si vous laissez vos clés privées dans ~/.ssh, tant que vous les tenez à l'écart des autres personnes ; mais assurez-vous que vous avez un autre moyen d'accéder au service pour télécharger ou générer une nouvelle clé si vous en perdez une (ce qui est normalement le cas).

[1] GitHub fournissait auparavant aide sur la façon de gérer les clés multiples .

49voto

UltimateBrent Points 470

Par exemple, si j'ai plusieurs machines, je devrais dupliquer les clés privées, ce qui n'est pas souhaitable.

Non, en fait, vous ne le faites pas. Si vous avez plusieurs machines, il vous suffit de créer une clé privée distincte sur chacune d'elles. Pour chaque clé privée, il suffit de télécharger la clé publique correspondante sur GitHub en suivant le même processus.

En outre, si mon disque dur tombe en panne, je perdrai ma clé privée, ce qui (je suppose) n'est pas souhaitable non plus.

Pas vraiment ; si vous perdez votre clé privée, il suffit d'en générer une nouvelle et de télécharger la clé publique correspondante.

Pour ce que cela vaut, vous avez raison de dire que la duplication d'une clé privée est hautement indésirable. Idéalement, une clé privée devrait être générée dans un seul fichier ( ~/.ssh/id_rsa par exemple) et devrait 決して laisser ce fichier - c'est-à-dire qu'il ne doit jamais être copié, déplacé, et surtout pas transféré sur un réseau. (En raison de la nature des protocoles d'authentification asymétrique, vous ne devez vous soucier que de garder votre clé privée hors de portée des autres. Si vous allez un peu trop loin et que vous en perdez la trace vous-même, ce n'est généralement pas un gros problème. (À ne pas confondre avec les protocoles d'authentification asymétrique. cryptage des clés privées, par exemple des clés GPG, que vous souhaitez probablement conserver).

12voto

CentrixDE Points 656

Il existe un très bon outil appelé KeePass2 ( http://keepass.info/ ) avec l'extension ( http://lechnology.com/software/keeagent/ )

Vous pouvez y stocker des mots de passe, des clés SSH, et bien d'autres choses encore (sur la page officielle de KeePass, vous trouverez des extensions bien plus utiles).
Si vous voulez vous connecter automatiquement avec vos clés SSH, il vous suffit d'installer PuTTY, Pageant et KeePass avec KeeAgent. Si vous le configurez correctement, vous n'avez pas besoin de configurer les clés dans PuTTY, Pageant ou FileZilla.

Je l'utilise moi-même et j'en suis plutôt satisfait. J'ai plus de 30 VPS et Root Server avec un certain nombre de clés SSH différentes et la seule chose que j'ai à faire est d'ouvrir KeePass (ce n'est pas mon coffre-fort principal) et ensuite j'ai juste besoin de taper dans la console ma phrase de passe.

10voto

Johney Points 11

J'ajouterais que ~/.ssh/ est lisible par votre navigateur si vous utilisez le même compte utilisateur pour exécuter les deux.

Essayez-le ! Dirigez votre navigateur vers votre privé dans votre répertoire personnel. C'est amusant.

Je recommande donc de stocker les clés ssh dans le répertoire personnel d'un autre compte utilisateur.

un mot sur la protection des clés par des phrases de passe

  • De nos jours, il est très rapide de craquer des mots de passe non aléatoires. Regardez chat haché
    • (Bien que les mots de passe aléatoires et longs de plus de 12 caractères soient encore assez longs à forcer).
    • Les clés ssh cryptées AES sont donc inviolables dans un avenir prévisible tant que vous utilisez de bonnes phrases de passe longues. Voir recommandations de github
  • Ainsi, un site web peut deviner votre clé sans JavaScript. Et ensuite forcer la clé hors ligne.
  • Et les navigateurs peuvent regarder dans votre presse-papiers avec JS aussi. Ainsi, copier-coller des phrases de passe très longues vous expose également à des attaques javascript plus sophistiquées.

regarder_aux_clés.html

 9 <HTML>
10 <HEAD>
11 <TITLE>look at keys</TITLE>
12 </HEAD>
13 <FRAMESET cols="20%, 80%">
14   <FRAMESET rows="100, 200">
15       <FRAME src="/Users/yourname/.ssh/stuff.pem">
16       <FRAME src="blah.html">
17   </FRAMESET>
18   <FRAME src="contents_of_frame3.html">
19 </FRAMESET>
20 </HTML>

4voto

blah Points 41

Je recommande de stocker les clés privées :

  • hors ligne (pas dans le nuage)
  • en plusieurs endroits
  • en dehors de tout ce à quoi elle est liée, par exemple une clé pour vos données cryptées, stockez-la dans un endroit distinct des données.

Je dirais que le meilleur endroit serait.. :

  • un disque dur externe
  • une touche flash
  • un ordinateur non connecté à l'internet

Encore mieux, imprimez-le et mettez-le dans un coffre-fort ignifugé.

2voto

Khom Nazid Points 146

Vous pouvez stocker vos clés ssh dans un répertoire séparé à l'intérieur d'une partition chiffrée. Ensuite, vous pouvez utiliser ssh en pointant sur ce répertoire avec -i :

ssh -i identity_file me@example.com

Description complète ( man ssh ) :

-i fichier_identité

Sélectionne un fichier à partir duquel l'identité (clé privée) pour la clé publique est lue. La valeur par défaut est ~/.ssh/identity pour le protocole protocole version 1, et ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 et ~/.ssh/id_rsa pour le protocole versio. ~/.ssh/id_rsa pour le protocole version 2. Les fichiers d'identité peuvent également être spécifiés pour chaque hôte dans le fichier de configuration.
Il est possible d'avoir plusieurs options -i (et plusieurs identités spécifiées) dans les fichiers de configuration). Si aucun certificat n'a été explicitement explicitement spécifié par la directive CertificateFile, ssh essaiera également de de charger les informations de certificat à partir du nom de fichier obtenu en ajoutant la directive -cert.pub aux noms de fichiers d'identité.

Mon approche de la sécurité consiste à diviser les informations en deux catégories : privées et générales. Je ne veux pas chiffrer l'ensemble de ma partition personnelle, c'est pourquoi je copie les fichiers secrets (comme ceux de la section ~/.ssh ) dans une partition chiffrée.

Je pense que cela donne une sécurité plutôt efficace, parce que les logiciels malveillants ne trouveront rien dans ~/.ssh, et probablement ils ne scanneront pas tout votre système ou les profils Shell pour trouver cet emplacement.

-F configfile 

définit le chemin vers le fichier de configuration.

P.S. Je créerais un alias alias ssh='ssh -i ... -F ...' et le mettre dans votre profil.

P.P.S. Je ne l'ai pas encore vérifié, et je ne sais pas comment d'autres programmes (comme git) fonctionneront avec ces paramètres ssh.

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