OpenSSH 7.2 added the ability to use SHA-2 instead of SHA-1 during key handshakes with RSA. We added this version to ThinLinc in r31504 for bug 5855. However, we forgot to update our host key handling so that we would allow these new algorithms. This is only an issue when it comes to the agent connection. For the master connection we use the built-in defaults of OpenSSH. This has never really been an issue in practice as modern ssh servers will generally also have support for ecdsa-sha2-nistp256, so lack of ssh-rsa will not prevent the client from connecting. Also, OpenSSH only recently disabled ssh-rsa by default (in version 8.8). However, at least Fedora disabled this even earlier (in Fedora 33). Other distributions might have done the same.
Works well now. Tested with RHEL9 with only an RSA host key. Without this change, the client cannot connect. With this change in place, it negotiates rsa-sha2-512.
General ============================= Tested using server build #2755 on Ubuntu22.04 and client builds #2639 (pre-fix) and #2660 (post-fix). [✔] Pre-fix build exhibit the behavior that sparked the bug. Does not connect to agent and claims no matching host keys. [✔] Post-fix build connects to agent as intended and makes use of the most novel rsa host key available beyond ssh-rsa. Acceptance criteria ============================= [✔] "rsa-sha2-256" and "rsa-sha2-512" are considered when the agent reports an "ssh-rsa" host key - Tested forcing exclusively rsa-sha2-256 or rsa-sha2-512, and both simultaneously. Works with one at a time, and the system prioritizes the most novel one if both are available. Summary ============================= Seems to be working as intended now, with novel rsa host keys beyond ssh-rsa accepted by agent. Closing.
