Re: libssh-0.4.2 server api bug

[Aris Adamantiadis <aris@xxxxxxxxxxxx>]

Hi,

This was resolved in d2bb97c1c6f32c167e1a6093201e01a52bfe0e0d. Thanks
for your feedback on this bug.

Regards,

Aris

Aris Adamantiadis a écrit :
> Hi
> Oops, we missed that bug for the release. I will find a solution.
> 
> Aris
> 
> Eugene Starozhilov a écrit :
>> Hi Aris,
>>
>> The new release libssh-0.4.2 has the same problem as libssh-0.4.1
>> (described below). samplesshd doesn't work with standard LINUX ssh
>> client. Is any chance to get it fixed soon?
>>
>>
>> Thank you,
>> Eugene
>>
>> --- On *Tue, 3/2/10, Aris Adamantiadis /<aris@xxxxxxxxxxxx>/* wrote:
>>
>> From: Aris Adamantiadis <aris@xxxxxxxxxxxx>
>> Subject: Re: libssh-0.4.1 breaks application
>> To: libssh@xxxxxxxxxx
>> Date: Tuesday, March 2, 2010, 1:13 PM
>>
>> Eugene,
>>
>> Now I get what you mean. Indeed, it seems we have a problem, by memory
>> the server uses the same function than the client for the selection of
>> the best matching algorithm, which obviously can't be right.
>>
>> I'll correct this. We have bug-material for the next release ...
>>
>> Aris
>>
>>
>> Eugene Starozhilov a écrit :
>>> Hi Aris,
>>>
>>> When I wrote "Now client and server choose different
>>> encryption algorithms during key negotiation" I meant that
>>> server chose aes256-ctr and client chose aes128-cbc so
>>> client and server just can't communicate.
>>>
>>> According to RFC 4253:
>>>
>>> A name-list of acceptable symmetric encryption algorithms (also
>>>          known as ciphers) in order of preference.  The chosen
>>>          encryption algorithm to each direction MUST be the first
>>>          algorithm on the client's name-list that is also on the
>>>          server's name-list.  If there is no such algorithm, both sides
>>>          MUST disconnect.
>>>
>>>
>>> It seems that server side (libssh-0.4.1) doesn't follow RFC 4253 in
>>> choosing encryption algorithm.
>>>
>>> Regards,
>>> Eugene
>>>
>>>
>>>
>>> --- On *Tue, 3/2/10, Aris Adamantiadis /<aris@xxxxxxxxxxxx>/* wrote:
>>>
>>>
>>>     From: Aris Adamantiadis <aris@xxxxxxxxxxxx>
>>>     Subject: Re: libssh-0.4.1 breaks application
>>>     To: libssh@xxxxxxxxxx
>>>     Date: Tuesday, March 2, 2010, 3:20 AM
>>>
>>>     Hi Eugene,
>>>
>>>     This is due to two fixes issued in 0.4.1:
>>>     -introduction of aes128-ctr, aes192-ctr and aes256-ctr
>>>     -Change in client key selector which gives the client priority on the
>>>     algorithms to choose.
>>>
>>>     I'd say it's a feature and not a bug. aes256-cbc is left for
>>>     compatibility but by default, aes256-ctr is choosen. The latter is
>> more
>>>     secure and fix a cryptographic bug in the cbc version.
>>>
>>>     Do these changes really impact the performances or usability of your
>>>     application ? In last resort, you can set the preferred keys using
>>>     ssh_set_options().
>>>
>>>     Aris
>>>
>>>     Eugene Starozhilov a écrit :
>>>     > Hi,
>>>     >
>>>     > I just moved my application which uses sever libssh API from
>>>     > libssh-0.4.0 to libssh-0.4.1. Now client and server choose different
>>>     > encryption algorithms during key negotiation. This problem can be
>>>     > reproduced using samplesshd as server and ssh as a client.
>>>     >
>>>     > CLIENT (ssh)
>>>     >
>>>     > debug2: mac_init: found hmac-sha1
>>>     >
>>>     > debug1: kex: server->client aes128-cbc hmac-sha1 none
>>>     >
>>>     > debug2: mac_init: found hmac-sha1
>>>     >
>>>     > debug1: kex: client->server aes128-cbc hmac-sha1 none
>>>     >
>>>     > SERVER (samplesshd)
>>>     >
>>>     > [3] Type 20
>>>     >
>>>     > [3] Set output algorithm aes256-ctr
>>>     >
>>>     > [3] Set input algorithm aes256-ctr
>>>     >
>>>     >
>>>     > Any suggestions how to fix the problem will be greatly appreciated.
>>>     > Thanks,
>>>     > Eugene
>>>     >
>>>     >
>>>
>>>
>>>
>>
> 
>