Re: libssh-0.4.2 server api bug

[Aris Adamantiadis <aris@xxxxxxxxxxxx>]

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
>>     >
>>     >
>>
>>
>>
> 
>