We got a report in issue 15037 on what looks like some kind of bug in our protocol for host keys between ssh and tlclient. ssh prints one fingerprint, and tlclient prints another. This has the effect of preventing users from logging in as we refuse to connect to the wrong agent. A hacky workaround could be to replace /opt/thinlinc/libexec/ssh-keyscan with /bin/true. That way the host key list should be empty and the client will fall back to asking the user.
Fixed in r28601. The triggering cause was an oversized DSA key. Current versions of OpenSSH refuses to create keys larger than 1024 bits because of security concerns, but older versions let you get away with it. This overflowed the message buffer in ssh that was used to pass the key to tlclient, resulting in a cropped key. The new code uses a dynamically allocated buffer. Since OpenSSH refuses to create these keys, the tester can't test this exact scenario. But a 8192 bits RSA key is also large enough to overflow the buffer, so use that.
Generated a 8192 bits RSA host key and tested connection using build 4139 which made client to report about security breach. Upgraded to client build 4290 and everything works as expected.CONFIRM HOST KEY message is not truncated.
