💾 Archived View for thrig.me › blog › 2023 › 10 › 18 › ssh-host-dsa-key.gmi captured on 2024-08-18 at 18:07:43. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-14)
-=-=-=-=-=-=-
Those who ran sysclean(8) after their recent OpenBSD 7.4 update may have noticed that SSH host DSA keys were listed for potential removal.
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_dsa_key.pub
DSA keys have been disabled for some time now, and moreover ssh-keygen no longer generates them.
https://github.com/openbsd/src/commit/fdd80b3518f1be1c7e85d7fcb7df0fdc29f01c0a
Other systems may eventually catch up to this version of OpenSSH.
$ nc -N ::1 22 < /dev/null
SSH-2.0-OpenSSH_9.5
So can the DSA host key files be removed? Maybe. If all your systems use current versions of OpenSSH and you have not enabled ssh-dss in HostKeyAlgorithms, and no client has stored a DSA host key for some reason, then yes. Otherwise, maybe: there could be clients that may still use some putty that fell off some truck who knows how many decades ago that cached the DSA host keys for who knows what reason. Public access servers need to grant more leeway on what is allowed, as it may not be possible for political reasons to get that emeritus faculty to stop using Windows XP a year or two past the sell-by date. Hypothetically. Probably DSA keys are safe to remove, though there probably are sites that still use them. Caching RSA host keys is a lot more common.
Good questions might be "can DSA host key uses be logged?"—possibly by fiddling with the LogLevel?—and "how long should we monitor the logs for users still using DSA?"—months? Or you could disable DSA host keys and see if anyone complains about a host key change. Users may not complain beyond putting a "does not work" sticky note on the monitor of the system that some other sysadmin eventually found months or years later. Hypothetically.
Actually removing the keys on some systems may be problematic if there is automation that recreates the files via some hidden script. RedHat Linux was notorious for pulling stunts like this, and you might end up with your Ansible code fighting some vendor script you did not know about until stupid things started to happen. Hypothetically. Various tricks to try here are to disable the vendor automation (though they will be prone to enable it in software updates, or may invent new automations) or to try setting the configuration file location to /dev/null so that the daemon loads nothing instead of the automatic file location. Ideally try these sorts of changes on a test system first.
If you only have modern systems and do not care about legacy compatibility, the Ciphers, KexAlgorithms, and whatnot could be set to only support modern algorithms. This will prevent much old software from connecting, including possibly libssh2. More sensible might be to firewall off TCP/22 as much as possible to cut down on the log spam from scanner systems. Ask me how I know!
Using only modern ciphers may however lock you out if you only have access to something old to connect with.
Another problem is now you (or someone else, if it's a job with rotation) need to remember to manually update the configuration with new ciphers and whatnot over time. Vendor defaults are probably a better option, if your vendor does sensible things.
OpenSSH does drop support for old key types and ciphers over time, so old systems will eventually not be able to connect.
Rumor has it that FreeBSD has a "legacy OpenSSL" for connecting to outdated and insecure devices with SSL. This could be done with OpenSSH by finding some old version of SSH, getting it to compile on a modern system and then using that to communicate with the legacy system. This is a bit of work, and maybe does not get you security fixes that modern versions have. I'd probably instead put the legacy system on a hopefully secure network and then connect to it via telnet, rsh, or jury rig something up with netcat (or raw TCP sockets, failing that) to get files to and from the system. But I haven't done much with legacy systems besides rarely compiling test code, so ad-hoc transfer methods work for me. Maybe try UUCP for the lols?
Another option is to have a virt running some ancient operating system version with ancient versions of whatever on it, and to use that to connect to the horrible old thing with. A stash of such virts with different operating system versions might be handy if you often need to interact with weird old systems.
There can be security problems with having exploitable software for legacy systems lying around or worse listening on a network port. Not a big risk compared to running something downright dangerous like Chrome, but not no risk. Ideally one would get rid of the legacy systems, but I've done too much sysadmining to know that really isn't always possible. There may have been plans to bribe a data tech into accidentally breaking a particular system that really needed to die. Hypothetically.
tags #openssh #altsysadminrecovery