Générer correctement sa clé SSH

technotes

En crypto asymétrique, il existe grossièrement deux catégories d’algorithme :

  • Ceux qui exploitent la factorisation des grands nombres premiers (RSA, DSA) - c’est la taille qui compte !
  • Ceux qui se basent sur les courbes elliptiques (clés ECC avec : ECDSA, Ed25519).

Depuis plusieurs années la recommandation est l’utilisation des algorithmes à base de courbes elliptics et côté de l’ANSSI plus spécifique l’ECDSA.

Recommandation de l'ANSSI

La source : le guide de l’ANSSI

Pour nuancer ces propos, il semble peser quelques doutes sur les modèles mathématiques retenus (pour rappel choisi par le NIST et donc potentiellement la NSA #théorieducomplot). Pour ne rien arranger son implémentation ne serait pas trivial (ce qui a permis le célèbre hack de la PS3 en 2010…).

Le consensus est maintenant de se tourner vers ED25519 supporté depuis la version 6.5 d’OpenSSH. Les autres avantages reconnu d’ED25519 sont sa performance et une meilleure robustesse aux attaques par canaux auxiliaires (ce qui peut avoir du sens dans les environnements cloud mutualisés). source

En complément, il est conseillé d’appliquer la fonction de dérivation de clé pour RSA (avec ED25519 c’est natif), sur cette fonction de dérivation on appliquera un nombre de tour de chiffrement (par défaut 16).

Attention la fonction de dérivation impact le temps de connexion au serveur et si la valeur de “LoginGraceTime” a été modifié cela peut engendrer des problèmes de connexion !

En conclusion

  • DSA

On oubli.

  • RSA

Maximum de compatibilité avec une longueur minimum de 2048 (je n’ai pas trouvé de recommendation officielle), ni de contrainte donc autant selectionner une longueur de 4096 ! Pour le nombre de tour de chiffrement, par défaut il est positionné à 16, 64 serait pour les paranoïaques !

ssh-keygen -o -a 64 -t rsa -b 4096 -f id_rsa
  • EDSA

Préconisation de l’ANSSI mais pas validé par la communauté.

  • ED22519

Recommandé mais pas compatible partout, pour le nombre de tour de chiffrement, la valeur 100 semble être le mode paranoïaques.

ssh-keygen -a 100 -t ed25519  -f id_ed25519

Astuce pour lister les algorithmes utilisés sur sa station

for key in ~/.ssh/id_*; do ssh-keygen -l -f "${key}"; done | uniq

256 SHA256:1m2JO+lDINIwfp38cGSjfQNCzPQtthl1Pfr1mfK6aZ4 eric@DESKTOP-JS69KRL (ECDSA)
256 SHA256:xbCWp2EQElijV8uBn1+gB38uUoxcvDRNN/bEEK/iV2o eric@DESKTOP-DUSU067 (ED25519)
256 SHA256:JBrStodYETM9PV9FHcY0U/dZi5twxZ/oNU0EyUwbgXM eric@DESKTOP-JS69KRL (ED25519)
256 SHA256:PmJTTXQWUnl+c7CQQl5S4LOjuaqG5xn/NTG5Qqhc+nw eric@DESKTOP-DUSU067 (ED25519)

Compléments côté serveur

Une fois que nous avons dit cela, sur notre serveur on interdit la connexion par mot de passe

/etc/ssh/sshd_config

PasswordAuthentication no
PubkeyAuthentication yes

Pour aller encore un peu plus loin dans le hardening, il est possible de sélectionner les algorithmes utilisés lors de l’échange de clé et l’authentification des messages :

/etc/ssh/sshd_config

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Pour dépanner les problèmes d’authentification:

/usr/sbin/sshd -d -p 2222
ssh -v -i ~/.ssh/id_backup backup_rocket@51.158.112.234 -p 2222

Transférer la clé publique sur le serveur distant

La commande ssh-copy-id permet d’envoyer une ou plusieurs clés publique et les déclarer dans le fichier authorized_keys vers un hôte distant.

~$ ssh-keygen -a 100 -t ed25519  -f ~/.ssh/id_ed25519_migration

Generating public/private ed25519 key pair.
Created directory '/home/eric/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/eric/.ssh/id_ed25519_migration.
Your public key has been saved in /home/eric/.ssh/id_ed25519_migration.pub.
The key fingerprint is:
SHA256:y/xeJqAwqZ3G8/9YcREt3unNmVxIl67OOgie/QnI2Yg eric@debian-gitlab
The key's randomart image is:
+--[ED25519 256]--+
|            ..  .|
|            ..o..|
|           ..+.+ |
|     .      ..+..|
|    +   S . ..oo+|
|   + +o==o o ..+o|
|  . *Eo=Bo+ =    |
|   . o o *.=.o   |
|      ..oo=+o    |
+----[SHA256]-----+

~$ ssh-copy-id -i ~/.ssh/id_ed25519_migration eric@192.168.2.111

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/eric/.ssh/id_ed25519_migration.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
eric@192.168.2.111's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'eric@192.168.2.111'"
and check to make sure that only the key(s) you wanted were added.

Attention si la clé n’est pas précisée : toutes les clés apparaissant dans ssh-add -L seront envoyées.

Ressources complémentaires :

ssh key hardening

Related