OpenSSH have announced [1] that DSA will be completely removed sometime around 2025/01. While DSA has been disabled by default for quite some time, we still have some code to still support DSA. We should probably follow suit and remove our DSA-patches. [1] https://lists.mindrot.org/pipermail/openssh-unix-dev/2024-January/041132.html
I ran a diff between our patched openssh and the corresponding official release. > diff -u <official source> <patched source> And it looks like there is only one line of code that needs to be reverted in our patched version to disable DSA there.
To clarify the previous comment, we have a patch in place that add DSA to the set of key types that ssh-keyscan should scan for by default, without any additional arguments provided. Hence, reverting the patch does not mean that we are disabling scanning for DSA keys, as the previous comment suggested, we are only changing the default behavior of ssh-keyscan to not include scanning for DSA keys.
We need to look at what we are disabling by not scanning for DSA keys, as would be the case if the patch is reverted. First, let's note that modern versions of our client do not use DSA, usage of it looks to have been removed in ThinLinc 4.1.0. Secondly, the DSA algorithm was disabled nine years ago, in OpenSSH 7.0 [1], and is considered legacy and not safe to use. Hence, most reasonably modern systems do not provide DSA host keys at all. [1] https://www.openssh.com/legacy.html This means that not scanning for DSA host keys could affect users in a scenario where the host system provides DSA host keys while not providing RSA (or more modern alternatives), while connecting with a client version < 4.1.0. That is - It could affect users connecting with an old client to the latest version of the server, where the server is installed on an old legacy system, where the legacy system do not provide any alternative to DSA (such as RSA).
The scenario described in the last two paragraphs in comment 3 is very unlikely to occur, and it should therefore be quite safe to remove the support for DSA (ssh-dss) in our server.
A correction in comment 3, The support for DSA (ssh-dss) was removed in ThinLinc 4.5.0.
For clients < 4.5.0, it looks like they don't really depend on the server's ssh-keyscan (where we are disabling DSA). When configuring the host machine to only provide a DSA hostkey, which then can not be found by /opt/thinlinc/libexec/ssh-keyscan. Then older clients still seem to be able to connect to the server, and they still find the DSA host key. It is possible that this would work differently if the Master and Agent weren't configured on the same machine.
Testing: ======== The host machine was configured to emulate a system that uses some modern algorithms in combination with the legacy DSA algorithm: - DSA - RSA - ECDSA - ED25519 Connections were established successfully with ThinLinc client versions: - 4.0.0 - 4.1.0 - 4.4.0 - 4.5.0 - 4.10.0 - 4.17.0 The behavior of the updated (reverted) ssh-keyscan was also verified by running the following command on the host machine with the updated server installed: > /opt/thinlinc/libexec/ssh-keyscan 127.0.0.1 All hostkeys but the DSA one are output to the terminal, which is the correct behavior. Note that running: > /opt/thinlinc/libexec/ssh-keyscan -t dsa 127.0.0.1 results in the output: > Unknown key type "dsa"
Sanity checked > /opt/thinlinc/libexec/ssh-keyscan -t dsa 127.0.0.1 with the latest Jenkins-build and it looks like ssh-keyscan is not able to read DSA host keys in the new version of OpenSSH we have upgraded to in bug 8389.
I initially intended to be more restrictive when configuring the system, such that it would only use DSA and RSA and ignore the more modern algorithms ECDSA and ED25519. When doing this, I encountered another bug when iterating through client versions. If only RSA is available, clients < 4.15.0 are not able to connect since newer OpenSSH (9.6p1 on the host machine) Use SHA2 instead of SHA1 in conjunction with RSA. This was fixed in bug 7935, see also bug 7535.
> MUST: > We should follow the upstream behavior for handling of DSA host keys. We are no longer patching in custom behavior in the ssh-keyscan that we ship with the ThinLinc server. The handling of DSA host keys has also been removed from our server code, since these can no longer be present due to the changes made in OpenSSH. Note that as of bug 8389, ssh-keyscan can no longer present DSA host keys even when explicitly asked, see comment 8. > It should still be possible to connect with the current client. This is true if the host machine uses modern enough host key algorithms. > It should still be possible to connect with older supported versions of the > client. This is true if the host machine uses algorithms that match what the client can accept during a connection attempt. Even DSA works, see comment 6.
Whoops, forgot to push the changes!
There we go! :)
Tested server build 3676 on Ubuntu 16.04, with master and agent on separate machines. Both machines used algorithms ED2559, RSA, DSA and ECDSA. Tested logging in to the server with client versions 4.0.0, 4.1.0, 4.4.0, 4.5.0 and 4.17.0, worked well for all versions. Originally, I tried testing with the server on CentOS 6. I could not ssh to it from my workstation due to non-matching keytypes, so it seemed to be outdated enough. However, CentOS 6 does not use systemd, which means that ThinLinc does not run on it by default. While it probably is possible to edit the services to run without systemd, I opted not to. To get the issue described in comment 3 (running new server on old machine, connecting with old client), the server machine needs to both use systemd and not support any newer keytypes. This narrows down the criteria for encountering this bug even further, meaning that it should be even less likely to encounter in the wild. Also looked through the code changes, they look good and minimal.
