From Rohini.Chahar at netscout.com  Wed Apr 10 20:15:40 2019
From: Rohini.Chahar at netscout.com (Chahar, Rohini)
Date: Wed, 10 Apr 2019 12:15:40 +0000
Subject: Dropbear 2018.76 when behaving as client sending sha1 as mac
Message-ID: <BN6PR01MB2819F87341BA767A8C7F3A91902E0@BN6PR01MB2819.prod.exchangelabs.com>

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/0137338e/attachment.htm 

From matt at ucc.asn.au  Wed Apr 10 21:09:21 2019
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed, 10 Apr 2019 21:09:21 +0800
Subject: Dropbear 2018.76 when behaving as client sending sha1 as mac
In-Reply-To: <BN6PR01MB2819F87341BA767A8C7F3A91902E0@BN6PR01MB2819.prod.exchangelabs.com>
References: <BN6PR01MB2819F87341BA767A8C7F3A91902E0@BN6PR01MB2819.prod.exchangelabs.com>
Message-ID: <53B612A6-EC9C-40D2-802A-85FB60404F7A@ucc.asn.au>

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 

From Rohini.Chahar at netscout.com  Thu Apr 11 12:11:52 2019
From: Rohini.Chahar at netscout.com (Chahar, Rohini)
Date: Thu, 11 Apr 2019 04:11:52 +0000
Subject: Dropbear 2018.76 when behaving as client sending sha1 as mac
In-Reply-To: <53B612A6-EC9C-40D2-802A-85FB60404F7A@ucc.asn.au>
References: <BN6PR01MB2819F87341BA767A8C7F3A91902E0@BN6PR01MB2819.prod.exchangelabs.com>
	<53B612A6-EC9C-40D2-802A-85FB60404F7A@ucc.asn.au>
Message-ID: <BN6PR01MB2819CF9F1CA008E44FB52678902F0@BN6PR01MB2819.prod.exchangelabs.com>

Hi Matt,

Please find my responses below.

Regards,
Rohini

From: Matt Johnston <matt at ucc.asn.au>
Sent: 10 April 2019 18:39
To: Chahar, Rohini <Rohini.Chahar at netscout.com>
Cc: dropbear at ucc.asn.au
Subject: Re: Dropbear 2018.76 when behaving as client sending sha1 as mac

[EXTERNAL EMAIL]
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?
ROHINI >> Dropbear is selecting sha1 and sha2 on its own. My understanding was first sha2 is tried and when the server do not supports it them dropbear move to sha1 but it is not happening. When sending request to server it is sending sha1 only. In default_options.h file comment also says "/* Message integrity. sha2-256 is recommended as a default, sha1 for compatibility */"

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?
ROHINI >> Yes when I am doing copy to server dropbear is selecting sha1. Yes sha2 is enabled in options. I also tried disabling sha1 then dropbear is sending sha2. I do not want to disable sha2 I want it to be the first one used by dropbear. Is there any priority setting which is doing so?

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.
ROHINI >> I captured packets in wireshark and from there only I reached to this conclusion.

Cheers,
Matt


On Wed 10/4/2019, at 8:15 pm, Chahar, Rohini <Rohini.Chahar at netscout.com<mailto: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/20190411/3b524bc6/attachment.htm 

From matt at ucc.asn.au  Thu Apr 11 22:55:44 2019
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 11 Apr 2019 22:55:44 +0800
Subject: Dropbear 2018.76 when behaving as client sending sha1 as mac
In-Reply-To: <BN6PR01MB2819CF9F1CA008E44FB52678902F0@BN6PR01MB2819.prod.exchangelabs.com>
References: <BN6PR01MB2819F87341BA767A8C7F3A91902E0@BN6PR01MB2819.prod.exchangelabs.com>
	<53B612A6-EC9C-40D2-802A-85FB60404F7A@ucc.asn.au>
	<BN6PR01MB2819CF9F1CA008E44FB52678902F0@BN6PR01MB2819.prod.exchangelabs.com>
Message-ID: <853F5614-43C8-4860-A3B0-C0AE47536C98@ucc.asn.au>

Dropbear has sha1 as the first on its priority list. You can change the order of the options in common-algo.c 
https://secure.ucc.asn.au/hg/dropbear/file/tip/common-algo.c#l185

I'll change it so that sha1 has lower priority for a future release.
Currently I don't think there is any security problem with sha1 as a hmac?

Cheers,
Matt

> On Thu 11/4/2019, at 12:11 pm, Chahar, Rohini <Rohini.Chahar at netscout.com> wrote:
> 
> Hi Matt,
>  
> Please find my responses below.
>  
> Regards,
> Rohini
>  
> From: Matt Johnston <matt at ucc.asn.au <mailto:matt at ucc.asn.au>> 
> Sent: 10 April 2019 18:39
> To: Chahar, Rohini <Rohini.Chahar at netscout.com <mailto:Rohini.Chahar at netscout.com>>
> Cc: dropbear at ucc.asn.au <mailto:dropbear at ucc.asn.au>
> Subject: Re: Dropbear 2018.76 when behaving as client sending sha1 as mac
>  
> [EXTERNAL EMAIL]
> 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?
> ROHINI >> Dropbear is selecting sha1 and sha2 on its own. My understanding was first sha2 is tried and when the server do not supports it them dropbear move to sha1 but it is not happening. When sending request to server it is sending sha1 only. In default_options.h file comment also says ?/* Message integrity. sha2-256 is recommended as a default, sha1 for compatibility */?
>  
> 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?
> ROHINI >> Yes when I am doing copy to server dropbear is selecting sha1. Yes sha2 is enabled in options. I also tried disabling sha1 then dropbear is sending sha2. I do not want to disable sha2 I want it to be the first one used by dropbear. Is there any priority setting which is doing so?
>  
> 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.
> ROHINI >> I captured packets in wireshark and from there only I reached to this conclusion.
>  
> Cheers,
> Matt
> 
> 
> On Wed 10/4/2019, at 8:15 pm, Chahar, Rohini <Rohini.Chahar at netscout.com <mailto: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/20190411/32027bba/attachment-0001.htm 

From stokito at gmail.com  Thu May  2 15:57:53 2019
From: stokito at gmail.com (Sergey Ponomarev)
Date: Thu, 2 May 2019 10:57:53 +0300
Subject: Forward a UNIX Socket
Message-ID: <CADR0UcV4wfwML05-0PB-HY8QXpRiZdT1XQXbv=rvA7V=ujvZeg@mail.gmail.com>

Hi,

I need to forward a unix socket (/var/run/ubus) from my router with OpenWrt
to my laptop with Ubuntu.
It looks like dropbear doesn't supports this and I wondered why because it
looks like not a big change.

Is any problems to implement this? Do you have any plans for this?

Regards,
Sergey Ponomarev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20190502/e12ccf40/attachment.htm 

From matt at ucc.asn.au  Thu May  2 20:33:07 2019
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 2 May 2019 20:33:07 +0800
Subject: Forward a UNIX Socket
In-Reply-To: <CADR0UcV4wfwML05-0PB-HY8QXpRiZdT1XQXbv=rvA7V=ujvZeg@mail.gmail.com>
References: <CADR0UcV4wfwML05-0PB-HY8QXpRiZdT1XQXbv=rvA7V=ujvZeg@mail.gmail.com>
Message-ID: <368EA4AC-2FC4-49D2-86C5-C9F1B10AC906@ucc.asn.au>

Hi Sergey,

Dropbear doesn't support it - it would be fine to add, it just didn't exist in OpenSSH when I implemented the other Dropbear forwarding.
I might add it in future though no guarantees - patches gladly accepted! The SSH agent fowarding code is probably very similar already.

Cheers,
Matt



> On Thu 2/5/2019, at 3:57 pm, Sergey Ponomarev <stokito at gmail.com> wrote:
> 
> Hi,
> 
> I need to forward a unix socket (/var/run/ubus) from my router with OpenWrt to my laptop with Ubuntu.
> It looks like dropbear doesn't supports this and I wondered why because it looks like not a big change.
> 
> Is any problems to implement this? Do you have any plans for this?
> 
> Regards,
> Sergey Ponomarev
> 


From kenny at stealthspacecompany.com  Thu Jun 20 11:15:12 2019
From: kenny at stealthspacecompany.com (Kenny Koller)
Date: Thu, 20 Jun 2019 03:15:12 +0000
Subject: Configuration Issues
Message-ID: <SN5P110MB0398762F82C7D3E0B8E290AFB2E40@SN5P110MB0398.NAMP110.PROD.OUTLOOK.COM>

Hi,

I'm using Xilinx's 2019.1 Petalinux system which uses Dropbear 2018.76 by default. The target is
a Zynq 7000 running Linux.

The first issue is that with the open-ssh client the first password attempt fails every time. The
second attempt works. This was before I configured any host/login keys. A console login does not
have this issue.

The second issue is that with the host/login keys in place I continue to be prompted twice when
using ssh. With dbclient I am rejected altogether:

radsys at radsys-nuc:~$ dbclient root at 10.160.33.150 -i ~/.ssh/id_rsa
root at 10.160.33.150's password:
root at 10.160.33.150's password:

dbclient: Connection to root at 10.160.33.150:22 exited: Error reading: Connection reset by peer

My client system is Ubuntu 16.04 with the login (private) key stored as follows. It was generated
with dropbearkey:

radsys at radsys-nuc:~$ ls -al .ssh
drwx------  2 radsys radsys 4096 Jun 19 19:33 .
drwxr-xr-x 35 radsys radsys 4096 Jun 17 19:20 ..
-rw-------  1 radsys radsys  805 Jun 19 19:31 id_rsa

On the server/embedded side I have the public portion of the private key above in authorized_keys
and a host key also generated using dropbearkey.

root at radio:~# ls -al /etc/dropbear
drwxr-xr-x    2 root     root             0 Jun 20 02:25 .
drwxr-xr-x   24 root     root             0 Jun 20 02:26 ..
-rw-------    1 root     root           393 Jun 20 02:25 authorized_keys
-rw-------    1 root     root           805 Jun 20 02:25 dropbear_rsa_host_key

Also, my clock is not set correctly on the embedded system. Is this an issue?


Help would be greatly appreciated.


Thanks,


Kenny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20190620/8cf259b5/attachment.htm 

From matt at ucc.asn.au  Sun Jun 23 16:31:52 2019
From: matt at ucc.asn.au (Matt Johnston)
Date: Sun, 23 Jun 2019 16:31:52 +0800
Subject: Configuration Issues
In-Reply-To: <SN5P110MB0398762F82C7D3E0B8E290AFB2E40@SN5P110MB0398.NAMP110.PROD.OUTLOOK.COM>
References: <SN5P110MB0398762F82C7D3E0B8E290AFB2E40@SN5P110MB0398.NAMP110.PROD.OUTLOOK.COM>
Message-ID: <693B6715-9FD5-4085-8FD4-14CBF73E9DD2@ucc.asn.au>

Hi Kenny,

I don't think I've seen that problem before. Does Dropbear log anything in /var/log/auth.log or similar? 
Or if logging isn't set up on the system, if you run dropbear -F -E it will log to the console.
The clock shouldn't make any difference.

Cheers,
Matt

> On Thu 20/6/2019, at 11:15 am, Kenny Koller <kenny at stealthspacecompany.com> wrote:
> 
> Hi,
> 
> I'm using Xilinx's 2019.1 Petalinux system which uses Dropbear 2018.76 by default. The target is
> a Zynq 7000 running Linux.
> 
> The first issue is that with the open-ssh client the first password attempt fails every time. The
> second attempt works. This was before I configured any host/login keys. A console login does not
> have this issue.
> 
> The second issue is that with the host/login keys in place I continue to be prompted twice when
> using ssh. With dbclient I am rejected altogether:
> 
> radsys at radsys-nuc:~$ dbclient root at 10.160.33.150 <mailto:root at 10.160.33.150> -i ~/.ssh/id_rsa
> root at 10.160.33.150 <mailto:root at 10.160.33.150>'s password: 
> root at 10.160.33.150 <mailto:root at 10.160.33.150>'s password: 
> 
> dbclient: Connection to root at 10.160.33.150 <mailto:root at 10.160.33.150>:22 exited: Error reading: Connection reset by peer
> 
> My client system is Ubuntu 16.04 with the login (private) key stored as follows. It was generated
> with dropbearkey:
> 
> radsys at radsys-nuc:~$ ls -al .ssh
> drwx------  2 radsys radsys 4096 Jun 19 19:33 .
> drwxr-xr-x 35 radsys radsys 4096 Jun 17 19:20 ..
> -rw-------  1 radsys radsys  805 Jun 19 19:31 id_rsa
> 
> On the server/embedded side I have the public portion of the private key above in authorized_keys
> and a host key also generated using dropbearkey.
> 
> root at radio:~# ls -al /etc/dropbear
> drwxr-xr-x    2 root     root             0 Jun 20 02:25 .
> drwxr-xr-x   24 root     root             0 Jun 20 02:26 ..
> -rw-------    1 root     root           393 Jun 20 02:25 authorized_keys
> -rw-------    1 root     root           805 Jun 20 02:25 dropbear_rsa_host_key
> 
> Also, my clock is not set correctly on the embedded system. Is this an issue?
> 
> Help would be greatly appreciated.
> 
> Thanks,
> 
> Kenny

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20190623/df7c95d5/attachment.htm 

From matt at ucc.asn.au  Tue Jun 25 21:20:08 2019
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 25 Jun 2019 21:20:08 +0800
Subject: Configuration Issues
In-Reply-To: <DM2P110MB012292983E3FE5475AAED473B2E30@DM2P110MB0122.NAMP110.PROD.OUTLOOK.COM>
References: <SN5P110MB0398762F82C7D3E0B8E290AFB2E40@SN5P110MB0398.NAMP110.PROD.OUTLOOK.COM>
	<693B6715-9FD5-4085-8FD4-14CBF73E9DD2@ucc.asn.au>
	<DM2P110MB012292983E3FE5475AAED473B2E30@DM2P110MB0122.NAMP110.PROD.OUTLOOK.COM>
Message-ID: <37CF0538-5DEA-4107-A382-3CF6DC9DCA7F@ucc.asn.au>

Hi Kenny,

Is this a modified version of Dropbear? The standard location is /root/.ssh/authorized_keys (or ~/.ssh/authorized_keys for other users), though some distributions change it to /etc/dropbear/authorized_keys
If it isn't printing any message at all I would check that the key in that file is pasted correctly - newlines sometimes cause problems.
The permissions on the parent directory also need to be writable only by the user. By default logging in as root should work.

Cheers,
Matt

> On Tue 25/6/2019, at 12:05 pm, Kenny Koller <kenny at stealthspacecompany.com> wrote:
> 
> Hi Matt,
> 
> Thanks. The double login thing has gone away though I can't explain why due to a number changes that occurred.
> 
> Presently I'm trying to login as root without a password. I use `dbclient root@<ip address> -i ~/.ssh/id_rsa`. This is a private key created by dropbear. On the embedded Linux system I have the public key in /etc/dropbear/authorized_keys. But it continues to prompt me for a password. Running with -F -E simply says that PAM authentication was successful. Permissions on the files in /etc/dropbear are 0600.
> 
> Is there a restriction on root?
> 
> Thanks,
> 
> Kenny
> 
> 
> From: Matt Johnston <matt at ucc.asn.au>
> Sent: Sunday, June 23, 2019 1:31:52 AM
> To: Kenny Koller
> Cc: dropbear at ucc.asn.au
> Subject: Re: Configuration Issues
>  
> Hi Kenny,
> 
> I don't think I've seen that problem before. Does Dropbear log anything in /var/log/auth.log or similar? 
> Or if logging isn't set up on the system, if you run dropbear -F -E it will log to the console.
> The clock shouldn't make any difference.
> 
> Cheers,
> Matt
> 
>> On Thu 20/6/2019, at 11:15 am, Kenny Koller <kenny at stealthspacecompany.com <mailto:kenny at stealthspacecompany.com>> wrote:
>> 
>> Hi,
>> 
>> I'm using Xilinx's 2019.1 Petalinux system which uses Dropbear 2018.76 by default. The target is
>> a Zynq 7000 running Linux.
>> 
>> The first issue is that with the open-ssh client the first password attempt fails every time. The
>> second attempt works. This was before I configured any host/login keys. A console login does not
>> have this issue.
>> 
>> The second issue is that with the host/login keys in place I continue to be prompted twice when
>> using ssh. With dbclient I am rejected altogether:
>> 
>> radsys at radsys-nuc:~$ dbclient root at 10.160.33.150 <mailto:root at 10.160.33.150> -i ~/.ssh/id_rsa
>> root at 10.160.33.150 <mailto:root at 10.160.33.150>'s password: 
>> root at 10.160.33.150 <mailto:root at 10.160.33.150>'s password: 
>> 
>> dbclient: Connection to root at 10.160.33.150 <mailto:root at 10.160.33.150>:22 exited: Error reading: Connection reset by peer
>> 
>> My client system is Ubuntu 16.04 with the login (private) key stored as follows. It was generated
>> with dropbearkey:
>> 
>> radsys at radsys-nuc:~$ ls -al .ssh
>> drwx------  2 radsys radsys 4096 Jun 19 19:33 .
>> drwxr-xr-x 35 radsys radsys 4096 Jun 17 19:20 ..
>> -rw-------  1 radsys radsys  805 Jun 19 19:31 id_rsa
>> 
>> On the server/embedded side I have the public portion of the private key above in authorized_keys
>> and a host key also generated using dropbearkey.
>> 
>> root at radio:~# ls -al /etc/dropbear
>> drwxr-xr-x    2 root     root             0 Jun 20 02:25 .
>> drwxr-xr-x   24 root     root             0 Jun 20 02:26 ..
>> -rw-------    1 root     root           393 Jun 20 02:25 authorized_keys
>> -rw-------    1 root     root           805 Jun 20 02:25 dropbear_rsa_host_key
>> 
>> Also, my clock is not set correctly on the embedded system. Is this an issue?
>> 
>> Help would be greatly appreciated.
>> 
>> Thanks,
>> 
>> Kenny

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