1

I read that RSA and EDCSA algorithms are inferior to Ed25519 in terms of speed and space, and for my small Beowulf cluster, I'd like to just use Ed25519. However, when I try to remove, truncate, or otherwise ditch the keys in /etc/ssh, the sshd server rebuilds new ones each time it starts.

I tried the solutions in https://apple.stackexchange.com/questions/342836/disable-ecdsa-ssh-host-keys to no avail. New keys are created each time the server starts. And setting HostKeyAlgorithms to exclude these kinds failed as well.

It would even help if I could get the server to NOT prefer ECDSA -- it seems to use these whenever it can.

4Dummies
  • 173
  • 1
  • 10

2 Answers2

1

I presume you are using OpenSSH? First use ssh -Q key to list all the supported keys in your version. The relevant part in the manual is

-Q cipher | cipher-auth | mac | kex | key | protocol-version
Queries ssh for the algorithms supported for the specified version 2. The available features are: cipher (supported symmetric ciphers), cipher-auth (supported symmetric ciphers that support authenticated encryption), mac (supported message integrity codes), kex (key exchange algorithms), key (key types) and protocol-version (supported SSH protocol versions).

With that information, set explicitly the ones you want in /etc/sshd_config and reload. For example:

PubkeyAcceptedKeyTypes ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
gildux
  • 253
  • 2
  • 14
  • That was interesting -- I did not know about that feature of ssh. And it appears the line you gave was suitable. However, putting that line in sshd_config.d/mysite.conf (both caller and destination sites) did not appear to change what went into authorized-keys. Should such a line be put in ssh_config of caller? It also did not stop sshd from generating new keys. – 4Dummies Jan 17 '23 at 01:22
  • Oh, I misunderstood the question :) Yes caller can also limit the algorithms in use but you cannot impose your choice to the world. SSH works in a negociation way: the server lists what it can accept, the client lists what it can provide, both side agree on one of the denominator to use. I think there's some settings elsewhere we miss. What's your distro and your ssh server version? – gildux Jan 17 '23 at 01:47
  • As you are using antother location, you must check it's loaded via an `Include` statement as discussed at https://superuser.com/a/1703061/161454 – gildux Jan 17 '23 at 01:51
  • both locations are in my garage. I've got them set up as similarly as I can, although caller is Xubuntu 20.04, callee is Fedora 37, both using openssh. (I'm trying to migrate to Fedora for all, but SSH is making me crazy). – 4Dummies Jan 17 '23 at 02:11
  • Even with both sites having markup about using ed25519, the authorized-host key that gets regurned is ecdsa. Is there some way I can verify that my config files are making a difference? – 4Dummies Jan 17 '23 at 02:15
  • Starting [from release 5.1](http://www.openssh.com/txt/release-5.1) there's a check mode: `sudo sshd -T` to see if OK and what will be used after all inclusions. Host keys are normally generated automatically when OpenSSH is first installed or when the computer is first booted, and regenerated at restart if you delete them. Sorry, I don't know how to fine control that generation. However the effective use is dictated by the `HostKeyAlgorithms` setting you may check also https://superuser.com/a/1142569/161454 – gildux Jan 17 '23 at 20:24
  • In linked page they say to no remove the keys because they'll be regenerated anyway. But you can make them invalid and then unusable without regeneration https://apple.stackexchange.com/a/451438 and https://apple.stackexchange.com/a/342840 (I've just learned it too) – gildux Jan 17 '23 at 22:05
  • those links are on a site for Apple products, but I tried them and they failed. Just truncating the ecdsa keys prevents sshd from starting on my Xubuntu system, even if I supply ed25519 keys. There must be more to this. – 4Dummies Jan 19 '23 at 16:44
  • On Fedora, I've tried really hard to blank the ECDSA keys. I have been unable. Every time the system restarts, the daemon will rebuild them or it will fail. And failure only happens when I protected the mangled copies with the ACL "immutable" property. In all the other cases I tried, it deleted broken copies and replaced them. Same goes for RSA keys. – 4Dummies Jan 20 '23 at 01:00
  • ok, so one have to leave with unused site keys ...because Linux packages maintainers want it to be so. – gildux Jan 20 '23 at 11:42
0

I have come to the conclusion there is no answer -- on Fedora, at least.

As mentioned in a comments to guidux' answer, there is a solution for Apple products' ssh server, and I have tried it with success on my Xubuntu systems -- so it seems likely they will work on all Debian-related distributions. However on Fedora these "solutions" either fail, or they prevent the ssh server from starting, and this may apply to all RedHat-related distributions.

4Dummies
  • 173
  • 1
  • 10