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 /<[email protected]>/* wrote: >> >> From: Aris Adamantiadis <[email protected]> >> Subject: Re: libssh-0.4.1 breaks application >> To: [email protected] >> 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 /<[email protected]>/* wrote: >>> >>> >>> From: Aris Adamantiadis <[email protected]> >>> Subject: Re: libssh-0.4.1 breaks application >>> To: [email protected] >>> 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 >>> > >>> > >>> >>> >>> >> > >
