Bug 5018 - parsing bug in the ssh host key handling
Summary: parsing bug in the ssh host key handling
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.2.0
Assignee: Pierre Ossman
URL:
Keywords: hean01_tester, prosaic
Depends on:
Blocks:
 
Reported: 2014-03-10 16:48 CET by Pierre Ossman
Modified: 2014-04-02 09:12 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2014-03-10 16:48:44 CET
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.
Comment 2 Pierre Ossman cendio 2014-03-12 11:38:00 CET
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.
Comment 3 Henrik Andersson cendio 2014-03-18 08:33:50 CET
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.

Note You need to log in before you can comment on or make changes to this bug.