1 67614987 2020-06-03 op For a long time I've been procrastinating on this. Even though there
2 67614987 2020-06-03 op is no compelling reason (from what I've understood -- I'm not a
3 67614987 2020-06-03 op cryptographer) to upgrade from my current 4096-bit RSA key to a shiny
4 67614987 2020-06-03 op new ed25519 key, today I've just made the first step towards the
5 67614987 2020-06-03 op removal of the "old" RSA key.
7 67614987 2020-06-03 op (A note must be made: not every ssh implementation supports ed25519
8 67614987 2020-06-03 op keys. Even some keyring may not support it yet.)
10 67614987 2020-06-03 op The thing is that my current ssh public key is in a lot of places:
11 67614987 2020-06-03 op home devices, friends machines, remote servers, and even some web
12 67614987 2020-06-03 op sites... more than I can count and be *absolutely sure* I'm not
13 67614987 2020-06-03 op forgetting something, so a complete switch is not possible.
15 67614987 2020-06-03 op It's possible, however, to start using a new key without deleting the
16 67614987 2020-06-03 op first: as you may already know, in your ssh config you can use
17 67614987 2020-06-03 op `IdentityFile` (see `ssh_config(5)`). The thing that I didn't knew
18 67614987 2020-06-03 op was that, by default, ssh checks multiple files, not only `id_rsa`
19 67614987 2020-06-03 op when logging. This seems cool, and in fact it lets you save lines in
20 67614987 2020-06-03 op the configuration.
22 67614987 2020-06-03 op So, to keep it short, what I did was as simple as
25 a3ab6f61 2020-09-22 op ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
28 67614987 2020-06-03 op and then adding the new public key to some servers. You can check
29 67614987 2020-06-03 op with `ssh -v foo@bar` that ssh attempt to use various keys
32 a3ab6f61 2020-09-22 op ; ssh -v foo@bar
33 a3ab6f61 2020-09-22 op OpenSSH_8.3, LibreSSL 3.2.0
34 a3ab6f61 2020-09-22 op debug1: Reading configuration data /home/op/.ssh/config
36 a3ab6f61 2020-09-22 op debug1: Offering public key: /home/op/.ssh/id_rsa RSA SHA256:...
37 a3ab6f61 2020-09-22 op debug1: Authentications that can continue: ...
38 a3ab6f61 2020-09-22 op debug1: Trying private key: /home/op/.ssh/id_dsa
39 a3ab6f61 2020-09-22 op debug1: Trying private key: /home/op/.ssh/id_ecdsa
40 a3ab6f61 2020-09-22 op debug1: Trying private key: /home/op/.ssh/id_ecdsa_sk
41 a3ab6f61 2020-09-22 op debug1: Offering public key: /home/op/.ssh/id_ed25519 ED25519 SHA256:...
42 a3ab6f61 2020-09-22 op debug1: Server accepts key: /home/op/.ssh/id_ed25519 ED25519 SHA256:...
43 a3ab6f61 2020-09-22 op debug1: Authentication succeeded (publickey).
47 67614987 2020-06-03 op (lines elided to keep them short and readable)
49 67614987 2020-06-03 op In this example, you can see that the ssh client first tries the
50 67614987 2020-06-03 op `id_rsa` key, but it didn't succeeded, then tries the (non existant in
51 67614987 2020-06-03 op my machine) `id_{dsa,ecdsa,ecdsa_sk}` and, finally, the `id_ed5519`
54 67614987 2020-06-03 op In the end, the real reason that was keeping me from updating the key
55 67614987 2020-06-03 op was just the assumption that I needed to either replace the key in
56 67614987 2020-06-03 op every place or use the appropriate `IdentityFile` per-host. Turns
57 67614987 2020-06-03 op out, this assumption is wrong and now I'm quite happy, with the
58 67614987 2020-06-03 op majority of the devices I connect to frequently already switched to
59 67614987 2020-06-03 op use my new ed25519 key, all without touching my local configuration :)
