Bugzilla – Bug 5018
parsing bug in the ssh host key handling
Last modified: 2014-04-02 09:12:55
You need to
before you can comment on or make changes to this bug.
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
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.