Auf dem Rechner können mehrere SSH-keys vorgehalten werden. Wir können also die alten Schlüssel behalten und zusätzliche einen neuen ed25519-Schlüssel generieren. So können wir uns weiterhin auf den Servern einloggen und nach und nach die alten Schlüssel auf den Servern mit ed25519-public-keys austauchen.
Mit dem folgenden Befehl erstellen wir einen neues SSH-Schlüssel-Paar mit dem ed26619-Algorithmus:
ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -C "max@mustermann.de"Dabei werden wir nach einem Passwort gefragt, welches unseren privaten Schlüssel schützt. Hier hat sich im Vergleich zu den alten Algorythmen nichts geändert.
-o : Speichert den private-key im neuen OpenSSH Format (statt im PEM Format). Diese Option wird prinzipliell schon durch den Typ ed25519impliziert. -a : Gibt die Anzahl der KDF-Runden (Key Derivation Function) an. Je höher die Nummer, desto langsamer erfolgt die Verifikation des Passworts und erhöht damit die Widerstandsfähigkeit gegen Brute-Force Angriffen, falls der private-key gestohlen werden sollte.-t : Spezifiziert den Typ des Schlüssels der erstellt werden soll. In unserem Fall ed25519.-f : Gibt den Dateinamen des generierten Schlüssels an. Wenn der Schlüssel automatisch vom SSH-Agenten gefunden werden soll, dann muss er im standard Verzeichnis .ssh abgelegt werden welches sich im home-Verzeichnis des Benutzers befindet.-C : Hier kann ein Kommentar angegeben werden. Er dient rein dem informativen Zweck und kann alles mögliche enthalten. Üblicherweise wird die E-Mail des Schlüssel-Erstellers angegeben z.B. "max@mustermann.de"https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54
Für dem Host selbst erstellen wir ein Schlüsselpaar ohne Passwort:
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N '' und passen dann die Einstellung in /etc/ssh/sshd_config an:
HostKey /etc/ssh/ssh_host_ed25519_keyNeben ed25519 steht in openssl auch der Algorythmus ed25519-sk zur Verfügung. Die -sk Erweiterung steht für security key. ed25519-sk-Schlüsselpaare werden von neuen YubiKeys (Firmware >5.2.3) unterstützt, die FIDO2 konform sind. YubiKeys vor der Firmware 5.2.3 können lediglich mit ecdsa-sk Schlüsselpaaren umgehen.
(Quelle)
https://undeadly.org/cgi?action=article;sid=20191115064850 :
You'll get a public/private keypair back as usual, except in this case, the private key file does not contain a highly-sensitive private key but instead holds a "key handle" that is used by the security key to derive the real private key at signing time.