libssh-0.4.2 server api bug

[Eugene Starozhilov <estarozhilov@xxxxxxxxx>]

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