Re: ssh-keygen: generate ed25519 keys by default
On 2020/10/08 15:40, Christian Weisgerber wrote: > 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. I don't think that's a show-stopper, people using such equipment likely already need to do non-default things to have OpenSSH connect to it, My typical config for connecting to switches, including some current models running latest available firmware, looks like KexAlgorithms +diffie-hellman-group14-sha1 HostKeyAlgorithms +ssh-rsa (and I still have a few things running where I need to break out an alternative client because openssh won't talk to them at all any more..)
Re: ssh-keygen: generate ed25519 keys by default
On 2020-10-08, Eldritch 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 - 1.420 > +++ ssh-keygen.c 8 Oct 2020 08:21:37 - That's at least missing a corresponding change to the man page. -- Christian "naddy" Weisgerber na...@mips.inka.de
ssh-keygen: generate ed25519 keys by default
With the recent change to prefer ed25519 keys on the server side [1] (unless I misunderstood what the change does), I think generating ed25519 keys by default with ssh-keygen makes sense at this point. Many users prefer the algorithm for its speed, small key size, lack of trust in OpenSSL or RSA, etc. 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. [1] https://marc.info/?l=openbsd-cvs&m=160169852214927&w=2 Index: ssh-keygen.c === RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.c,v retrieving revision 1.420 diff -u -p -r1.420 ssh-keygen.c --- ssh-keygen.c9 Sep 2020 03:08:01 - 1.420 +++ ssh-keygen.c8 Oct 2020 08:21:37 - @@ -60,11 +60,7 @@ #include "ssh-pkcs11.h" #endif -#ifdef WITH_OPENSSL -# define DEFAULT_KEY_TYPE_NAME "rsa" -#else -# define DEFAULT_KEY_TYPE_NAME "ed25519" -#endif +#define DEFAULT_KEY_TYPE_NAME "ed25519" /* * Default number of bits in the RSA, DSA and ECDSA keys. These value can be
