Dropbear 2018.76 when behaving as client sending sha1 as mac

Matt Johnston matt at ucc.asn.au
Wed Apr 10 21:09:21 AWST 2019


Hi Rohini,

I'm not entirely clear about the problem - is the conneciton failing or is it just selecting hmac-sha2-sha1 which you don't want?

The algorithm chosen will be the first one in the client's list that is also in the server's list. When you do the "copy to the server" is it dropbear as a client that is sending hmac-sha1? Was that compiled with sha2 enabled in the options?

If you can build them with 

#define DEBUG_TRACE 1

in localoptions.h then running with "dropbear -v" and "dbclient -v" will give some debug output, or a tcpdump/wireshark capture should show what's going on too.

Cheers,
Matt

> On Wed 10/4/2019, at 8:15 pm, Chahar, Rohini <Rohini.Chahar at netscout.com> wrote:
> 
> Hi,
>  
> I am experiencing a problem w.r.t dropbear 2018.76. I have the version installed and it is working fine but when I try to do a copy from this to a server that time dropbear is sending mac as hmac-sha1. However when I try to do login via putty that time dropbear behaves as server and uses mac as hmac-sha2-256. 
> In default file it is written that sha2 is default option but it is not coming as default. My understanding was that dropbear sends sha2 as default option and when server do not supports the mac it falls back to sha1.
> Do I need to do some code changes or is this a known problem? Please help me in resolving this issue.
>  
> Regards,
> Rohini

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20190410/445304d6/attachment-0001.htm 


More information about the Dropbear mailing list