On 2020-10-08, Eldritch <eldri...@memeware.net> wrote: > With the recent change to prefer ed25519 keys on the server side [1] > (unless I misunderstood what the change does), I think generating
This only changed the client's order of preference for the various server key types. If a server doesn't offer an Ed25519 key, the client will transparently fall back to one of the other types. > ed25519 keys by default with ssh-keygen makes sense at this point. > > Is there a reason not to do this? I am curious if so, as there's no > discussion on this matter that I could find. Those are mostly user keys. What happens if you upload an Ed25519 public user key to a server that doesn't handle this key type? It won't work. And you're not likely to be presented with a helpful error message. It just doesn't work. At this point, I don't know how many SSH servers are still out there that don't handle Ed25519. I still have an ECDSA key somewhere that I use to log into a machine that still runs... "OpenSSH_6.0p1 Debian-4+deb7u7, OpenSSL 1.0.1t 3 May 2016". There is a lot of networking equipment that allows uploading of a user key for SSH login but may include a comically obsolete version of OpenSSH or some alternative implementation that doesn't do Ed25519. So... is it the right time yet? I don't know, and it's certainly not my decision, but I think that's the background. > --- ssh-keygen.c 9 Sep 2020 03:08:01 -0000 1.420 > +++ ssh-keygen.c 8 Oct 2020 08:21:37 -0000 That's at least missing a corresponding change to the man page. -- Christian "naddy" Weisgerber na...@mips.inka.de
