When connecting to the agent, the client can only use ssh-rsa, ssh-dss and ecdsa-sha2-nistp256 host keys. This is a regression caused by bug 4557, where we moved handling from OpenSSH to tlclient. We've failed to keep tlclient updated with other host key types that newer versions of OpenSSH supports. Ideally, we shouldn't have any knowledge of host key formats in tlclient. Then there wouldn't be any information to keep in sync. The technical hurdle there is that the list of host keys we get from the master might include formats that the client's ssh doesn't support. So we would need to make sure ssh is tolerant of unknown types and just ignores those.
This is not just a future proofing thing. We can already see that the preferred key type of modern systems is not included, i.e. ssh-ed25519.
Everything is now in place, except for the fact that XmlRpc++ doesn't support enumerating structs.
Works well. Tested from Fedora 35 to RHEL 9. I can now see more types listed on the ssh command line, and it goes from picking ecdsa-sha2-nistp256 to ssh-ed25519.
General ========================= Tested using client builds #2639 (pre-fix) and #2660 (post-fix) on Fedora36 and server build #2755 on Ubuntu22.04. The code no longer adheres to a rigid list of key types, but rather what is dynamically available. The pre-fix build clearly exhibits the behavior reported in the bug, in that for intance ED25519 keys are ignored and defaults to for instance ECDSA. Running the post-fix build presents us with ssh-ed25519 additional host key algorithm as evident by the ssh command, and proceeds with ssh-ed25519 over ecdsa-sha2-nistp256 -- should that be next in line -- as reported by comment 5. Acceptance criteria ========================= [✔] All host key types given by the agent should be passed on to ssh Summary ========================= The client now correctly makes use of RSA, ECDSA, and ED25519 type keys, and is designed to automatically handle new types should they appear in the future. Closing.
