Upstream OpenSSH are flagging that they are about to drop support for the "ssh-rsa" method: > It is now possible[1] to perform chosen-prefix attacks against the > SHA-1 algorithm for less than USD$50K. For this reason, we will be > disabling the "ssh-rsa" public key signature algorithm by default in a > near-future release. Better alternatives are available, even with the same keys on disk. OpenSSH 7.2 or newer is ideally required. RHEL 7 has 7.4, so it's fine. But RHEL 6 has the ancient 5.3 so it will not be possible to connect to such systems in the future. We need to consider if we should just follow upstream and drop support, keep supporting it despite upstream, or add an option to re-enable it if users need to. We also need to consider longer support for ssh-rsa in our ssh-keyscan as older clients might still be used. OpenSSH only talks about host keys, but I would guess that public key authentication is also affected in the same way. Also note bug 5539 for 4.5.0 where ssh-dsa support was dropped. We dropped support right away in the client, but kept support in keyscan.
(In reply to Pierre Ossman from comment #0) > Also note bug 5539 for 4.5.0 where ssh-dsa support was dropped. We dropped > support right away in the client, but kept support in keyscan. Apparently, upstream has kept support in ssh-keyscan. So no need for local modifications here.
Argh! Apparently you cannot force SHA-1 for neither host keys nor public keys in the server, which makes testing this a pain. I guess I'll have to spin up something with an old OpenSSH server.
Ubuntu 16.04 is still too new, but CentOS 6 is sufficiently old that it lacks the newer ssh-rsa methods. On paper, it doesn't support the new ECDSA/ECDH stuff, though. But it seems Red Hat has back ported it, so you can still add such host keys: https://access.redhat.com/solutions/711953
Works well now. Tested using a CentOS 6 machine and a Fedora 35 client: > * Client should refuse to connect to host¹ that only support SHA-1 for RSA > host key exchange Yup. Tested both master and agent connection. For the agent connection I started vsmagent whilst sshd was only configured for ssh-rsa. I then reconfigured it to also support ECDSA. That way, the master connection succeeds, but the agent connection fails. > * Client should refuse to authenticate to host that only support SHA-1 for > RSA public key authentication Yup. > * A clear error message should be shown in the above cases Yup. In all cases it shows an error message stating that there is a compatibility issue with the server.
General ====================================== Testing of this bug has been done on CentOS6 -- reason being the inability of OpenSSH to break down host key algorithms, allowing us to isolate and test combinations of the hash and encryption algorithms, as mentioned in comment 4 and comment 5 -- using ThinLinc server official release 4.11, and Fedora36 employing developer clients #2639 (pre-fix) and #2660 (post-fix). Acceptance criteria ====================================== [✔] Client should refuse to connect to host that only support SHA-1 for RSA host key exchange. - Allowing only RSA host keys: pre-fix : successful connection post-fix: failed connection - Allowing RSA and ECDSA host keys: pre-fix : successful connection post-fix: successful connection - Reproduced the effect mentioned in comment 10, by not restarting vsmagent after allowing additional host key algorithms beyond RSA. Client connects to master, but fails while proceeding to agent; successful connection after restarting vsmagent. [✔] Client should refuse to authenticate to host that only support SHA-1 for RSA public key authentication. - Allowing only RSA host keys: pre-fix : successful connection post-fix: failed connection - Allowing RSA and ECDSA host keys: pre-fix : successful connection post-fix: successful connection - Reproduced the effect mentioned in comment 10, by not restarting vsmagent after allowing additional host key algorithms beyond RSA. Client connects to master, but fails while proceeding to agent; successful connection after restarting vsmagent. [✔] A clear error message should be shown in the above cases. - There's an updated error message dialog, in addition to the log error. Summary ====================================== The acceptance criteria are fulfilled: ThinLinc servers supporting solely ssh-rsa host key algorithms are not accepted by clients, neither using password nor public key authentications, and the error message dialog has been updated. Closing.
