Comment stocker les clés SSH?

67

J'ai récemment commencé à utiliser des clés SSH au lieu de mots de passe (grâce à GitHub, bien sûr), alors n'oubliez pas que ce concept est relativement nouveau pour moi. Actuellement, mes clés se trouvent simplement sous ~ / .ssh, mais je ne suis pas sûr que ce soit une bonne pratique. Par exemple, si j'ai plusieurs machines, je devrai dupliquer mes clés privées, ce que je pense indésirable. Ou bien, si mon disque dur tombe en panne, je perdrai ces clés, ce qui (je suppose) est également indésirable.

Alors, quelles sont les meilleures pratiques pour stocker les clés SSH de manière sécurisée, pratique et fiable?

On dirait que l'utilisation d'une carte à puce est une option (voir Cartes à puce pour stocker les 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 (tels que GitHub, AWS EC2) fournissent des instructions sur la configuration des clés SSH pour l’utilisation du service, mais peu ou pas d’arrière-plan (par exemple, que faire si une clé est déjà générée) de ssh-keygen[1], quelles sont les mesures de sécurité recommandées). Et il est difficile de savoir si cette information est en réalité sans importance ou si vous êtes censé la connaître "par défaut".

Pour résumer les réponses à ce point (mais lisez-les, et si vous avez quelque chose à ajouter - faites-le s'il vous plaît): dans ce cas, il est normal que vous laissiez vos clés privées dans ~ / .ssh, tant que vous le souhaitez. gardez-les 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] Auparavant, GitHub fournissait une aide sur la gestion de plusieurs clés .

Anton Strogonoff
la source
Ce lien semble être cassé help.github.com/multiple-ssh-keys
KJ Prix
@KJ Price, grâce à la Wayback Machine d' Internet Archive , la page est toujours disponible en ligne, mais pas à son lien d'origine. Une copie de la page archivée le 2 septembre 2011 est accessible à l' adresse Plusieurs clés SSH .
pointe de lune

Réponses:

41

Par exemple, si j'ai plusieurs machines, je devrai dupliquer des clés privées, ce qui, à mon avis, n'est pas souhaitable.

Non, en fait tu ne le fais pas. Si vous avez plusieurs machines, vous créez simplement 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.

De plus, si mon disque dur passe au kaput, je vais perdre ma clé privée, ce qui (je suppose) est également indésirable.

Pas vraiment; Si vous perdez votre clé privée, générez-en une nouvelle et téléchargez la clé publique correspondante.

Vous avez raison de dire que dupliquer une clé privée est hautement indésirable. Idéalement, une clé privée doit être généré dans un fichier ( ~/.ssh/id_rsapar exemple) et ne doit jamais laisser ce fichier - qui est, il ne doit jamais être copié, déplacé, et surtout pas transféré sur un réseau. (par exemple, je les exclure des sauvegardes) En raison de la nature des protocoles d'authentification asymétrique, vous devez uniquement vous soucier 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 grave. (Ceci ne doit pas être confondu avec les clés privées de chiffrement asymétrique , telles que les clés GPG, que vous souhaitez probablement conserver.)

David Z
la source
14
Cela ne fonctionne que si vous disposez d'une autre méthode pour accéder aux serveurs auxquels cette clé privée fournit l'accès. Vous pouvez télécharger la nouvelle clé publique uniquement si vous disposez de cet accès de sauvegarde.
ARBRE
2
@TREE: oui, mais d'après mon expérience, il est extrêmement rare de trouver un serveur qui ne fournit pas une méthode d'accès alternative (ou du moins d'ajouter une clé publique supplémentaire sans passer par SSH).
David Z
3
Merci, cela clarifie beaucoup les choses. Vraiment, perdre la clé SSH privée ne semble pas être un problème, car pour tous les services que j'utilise, il semble toujours y avoir un autre moyen d'accéder à un service pour en télécharger un nouveau.
Anton Strogonoff
3
AWS ne fournit aucune autre forme d'accès que la clé privée. Vous devez déconnecter le lecteur et le manipuler pour pouvoir y accéder une fois que vous avez perdu votre clé privée.
Asad Saeeduddin
1
Notez que vous pouvez définir un mot de passe sur votre clé privée si vous souhaitez une autre couche de sécurité.
Sudo
8

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

Essayez le! Pointez votre navigateur sur votre clé privée dans votre répertoire personnel. C'est marrant.

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

un mot sur les clés de protection des mots de passe

  • De nos jours, déchiffrer des mots de passe non randomisés est super rapide. Découvrez le hash cat
    • (Bien que des mots de passe aléatoires et longs, 12 caractères et plus, prennent encore assez de temps pour être brutaux)
    • Ainsi, les clés ssh cryptées AES sont indéchiffrables dans un avenir prévisible, à condition que vous utilisiez de bonnes phrases secrètes longues. Voir les recommandations de github
  • Ainsi, certains sites Web peuvent deviner - saisir votre clé sans JavaScript. Et brute-forcer la clé hors ligne.
  • Et les navigateurs peuvent également consulter votre Presse-papiers avec JS. Par conséquent, le copier-coller de très longues phrases secrètes vous expose également aux attaques plus sophistiquées de javascript.

look_at_keys.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>
HeyWatchThis
la source
17
Pour être clair, le fait que le navigateur puisse lire votre clé privée ne signifie pas qu'un site Web exécuté dans le navigateur le peut.
Ajedi32
6
Mais, si vous injectez un processus dans le processus du navigateur. Ensuite, vous pouvez également prendre le contrôle du navigateur. Donc, cet argument est parfaitement valable.
BigSack
Mais vous devez ensuite pirater le processus qui injecte des processus dans le registre de processus de l'unité de traitement de votre navigateur.
Skid Kadda
8

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

Vous pouvez y stocker des mots de passe, clés SSH et bien plus encore (sur la page officielle de KeePass, vous trouverez des extensions beaucoup plus utiles).
Si vous souhaitez 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 à configurer les clés dans PuTTY, Pageant ou FileZilla.

Je l'utilise moi-même et j'en suis assez content. J'ai plus de 30 serveurs virtuels et serveur racine avec un certain nombre de clés SSH différentes et la seule chose que je dois faire est d'ouvrir KeePass (ce n'est pas mon mot de passe principal) et puis il me suffit de taper dans la console mon mot de passe.

CentrixDE
la source
3

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

  • hors ligne (pas dans le nuage)
  • dans plus d'un endroit
  • en dehors de tout ce qui y est lié, par exemple une clé pour vos données cryptées, stockez-la dans un endroit séparé des données

Je dirais que le meilleur endroit serait:

  • un disque dur externe
  • une clé flash
  • un ordinateur non branché sur internet

Encore mieux, imprimez-le et placez-le dans un coffre-fort résistant au feu.

blabla
la source
4
Sécurité / meilleures pratiques vont de pair avec le côté pratique. Si une stratégie de sécurité bloque la capacité d’utiliser un système, elle sera contournée par l’utilisateur plutôt que par l’attaquant.
zaTricky
1

J'ai un fichier tar qui a la configuration de mon répertoire utilisateur (.bashrc, .ssh / et autres fichiers de configuration) que je conserve dans un endroit sûr. Lorsque j'obtiens un nouveau compte shell, je décompresse le fichier tar.

Vous ne devez placer vos clés privées que sur des serveurs de confiance. Sinon, vous devez créer une nouvelle clé privée sur le serveur uniquement pour ce serveur et lui permettre d'accéder aux éléments auxquels vous souhaitez accéder.

Personnellement, je suis à l'aise de copier mes fichiers .ssh / partout (cela signifie également que par une touche ssh régulière, l'accès ssh est instantanément, car il se trouve déjà dans le fichier allowed_keys).

EightBitTony
la source
J'imagine qu'avoir crypté ~ / .ssh sur une clé USB éviterait de générer et de télécharger une nouvelle clé en cas de défaillance matérielle. Cependant, comme il y a très peu de serveurs auxquels j'utilise des clés SSH (et très peu de machines à partir desquelles je me connecte), la génération de nouvelles clés ne causera pas beaucoup de frais supplémentaires.
Anton Strogonoff
2
Ce sont des chevaux pour les cours et cela dépend de la raison pour laquelle vous utilisez les clés. Je ne vois pas d'inconvénient à copier une clé privée ssh sur un lien SSH déjà chiffré. Mais si vous ne faites pas confiance à la machine cible et ne savez pas qui a un accès root, vous ne devez rien mettre sur le serveur que vous ne pouvez pas vous permettre de perdre.
EightBitTony
Vous ne voulez pas mettre votre clé privée sur le serveur de quelqu'un d'autre. Toute personne ayant un accès racine sur ce serveur peut lire votre clé privée puis se faire passer pour vous sur des systèmes auxquels vous accédez avec cette clé privée. Vous ne devriez mettre votre clé publique que pour accéder au serveur. Et ne pensez pas que la phrase secrète vous aidera beaucoup si vous l’utilisez sur une machine distante pour déchiffrer une clé privée.
Codeguy007
Vous pouvez transférer ssh-agent sur ssh. De cette façon, vous n'avez pas besoin de stocker la clé privée sur le serveur ou d'envoyer votre phrase secrète sur le net. stackoverflow.com/questions/12257968/…
Codeguy007
1

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

ssh -i identity_file [email protected]

Description complète ( man ssh):

-i fichier_identité

Sélectionne un fichier dans lequel l'identité (clé privée) pour l'authentification par clé publique est lue. La valeur par défaut est ~ / .ssh / identity pour la version 1 du protocole et ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa, ~ / .ssh / id_ed25519 et ~ / .ssh / id_rsa pour la version 2 du protocole. Les fichiers d'identité peuvent également être spécifié hôte par 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 spécifié par la directive CertificateFile, ssh tentera également de charger les informations de certificat à partir du nom de fichier obtenu en ajoutant -cert.pub aux noms de fichiers d'identité.

Mon approche de la sécurité est de diviser les informations en informations privées et générales. Je ne veux pas chiffrer toute ma partition d'origine, c'est pourquoi je copie des fichiers secrets (comme ceux de ~/.ssh) dans une partition chiffrée.

Je pense que cela donne une sécurité assez efficace, car les logiciels malveillants ne trouveront rien dans ~ / .ssh, et probablement, ils n'analyseront pas l'intégralité de votre système ou vos profils de shell pour trouver cet emplacement.

-F configfile 

définit le chemin d'accès au fichier de configuration.

PS je créerais un alias alias ssh='ssh -i ... -F ...'et le mettrais dans votre profil.

PPS Je n’ai pas encore vérifié cela et je ne sais pas comment d’autres programmes (comme git) fonctionneront avec ces paramètres ssh.

Yaroslav Nikitenko
la source