Politique et compatibilité
Ed25519 convient si le serveur et la politique de sécurité l’acceptent. Utilisez RSA 3072 ou 4096 si la compatibilité ou les règles l’exigent. Une clé RSA n’est pas l’ancienne signature SHA-1 ssh-rsa : RSA moderne utilise aussi SHA-2. Ne réactivez pas globalement les signatures anciennes.
Hybride post-quantique : ssh-mldsa44-ed25519
ssh-mldsa44-ed25519 combine la signature post-quantique ML-DSA-44 avec Ed25519 : falsifier une connexion nécessiterait de casser les deux algorithmes. CH-J Key Generator en Beta 0.1.2 crée ce type de clé, et CH-J Tools ne l'ajoute à un serveur que si celui-ci utilise OpenSSH 10.6 ou une version ultérieure. Les versions antérieures la rejettent ; certaines, comme 10.2p1 dans Ubuntu 26.04, ne reconnaissent qu'une variante expérimentale …@openssh.com que CH-J Tools n'utilise pas. Conservez une clé Ed25519 ou RSA comme solution de repli pour les serveurs et les clients qui ne prennent pas en charge ce type de clé. Le guide accessible via le lien ci-dessous montre comment installer OpenSSH 10.6 à côté du paquet de la distribution.
Générer localement et protéger la clé privée
Choisissez une commande et un nouveau nom de fichier ; n’écrasez pas une clé existante. Définissez une phrase secrète à l’invite. Seul le fichier .pub va sur le serveur ; la clé privée reste sur le client. CH-J Key Generator existe déjà dans la Beta 0.1.0.
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_chj
ssh-keygen -t rsa -b 3072 -f ~/.ssh/id_rsa_chj
ssh-keygen -lf ~/.ssh/id_ed25519_chj.pub -E sha256Installer la clé publique puis tester
Placez la clé publique entière sur une ligne dans ~/.ssh/authorized_keys du compte cible. Sous Linux, vérifiez le propriétaire et généralement les modes 700 pour .ssh et 600 pour authorized_keys. Gardez la session actuelle ouverte et testez une seconde connexion avant de changer l’ancien accès. Clés utilisateur et clés d’hôte ont des rôles distincts.
ls -ld ~/.ssh ~/.ssh/authorized_keys
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_chj user@server.example