Re: Dropbear 2018.76 when behaving as client sending sha1 as mac

[Matt Johnston]

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  
> wrote:
> 
> Hi Matt,
>  
> Please find my responses below.
>  
> Regards,
> Rohini
>  
> From: Matt Johnston mailto:m...@ucc.asn.au>> 
> Sent: 10 April 2019 18:39
> To: Chahar, Rohini  <mailto:rohini.cha...@netscout.com>>
> Cc: dropbear@ucc.asn.au <mailto:dropbear@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  <mailto:rohini.cha...@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

RE: Dropbear 2018.76 when behaving as client sending sha1 as mac

[Chahar, Rohini]

Hi Matt,

Please find my responses below.

Regards,
Rohini

From: Matt Johnston 
Sent: 10 April 2019 18:39
To: Chahar, Rohini 
Cc: dropbear@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 
mailto:rohini.cha...@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

Re: Dropbear 2018.76 when behaving as client sending sha1 as mac

[Matt Johnston]

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

Re: Dropbear 2018.76

[Matt Johnston]

Hi Warren,

I think the current tree is ready to release, so hopefully
in the next week. 

There are a few outstanding pull requests but on balance I
think it's better that they wait for the next release -
hopefully at a shorter interval.

Cheers,
Matt


On Wed, Mar 20, 2019 at 12:53:55AM -0400, Russell Warren wrote:
> I've just run into this same problem.
> 
> Any word on a new release to fix the numerous changes since 2018.76?
> 
> Also, anyone care to jump in with a recommendation out of these options?
> 
> 1. Continue to use 2017.75?
> 2. Use 2018.76 with the specified patch
> ?
> 3. Use the current repo tip?
> 
> Thanks!
> Russ
> 
> On Fri, Mar 9, 2018 at 3:19 AM Peter Krefting 
> wrote:
> 
> > Matt Johnston:
> >
> > > This should be fixed in
> > > https://secure.ucc.asn.au/hg/dropbear/rev/0dc3103a5900
> > > 
> >
> > This patch does indeed fix the problem. Thank you!
> >
> > --
> > \\// Peter - http://www.softwolves.pp.se/

Re: Dropbear 2018.76

[Russell Warren]

I've just run into this same problem.

Any word on a new release to fix the numerous changes since 2018.76?

Also, anyone care to jump in with a recommendation out of these options?

1. Continue to use 2017.75?
2. Use 2018.76 with the specified patch
?
3. Use the current repo tip?

Thanks!
Russ

On Fri, Mar 9, 2018 at 3:19 AM Peter Krefting 
wrote:

> Matt Johnston:
>
> > This should be fixed in
> > https://secure.ucc.asn.au/hg/dropbear/rev/0dc3103a5900
> > 
>
> This patch does indeed fix the problem. Thank you!
>
> --
> \\// Peter - http://www.softwolves.pp.se/

[SUSPECTED SPAM]Re: Dropbear 2018.76

[Peter Krefting]

Matt Johnston:

This should be fixed in 
https://secure.ucc.asn.au/hg/dropbear/rev/0dc3103a5900 



This patch does indeed fix the problem. Thank you!

--
\\// Peter - http://www.softwolves.pp.se/

Re: Dropbear 2018.76

[Matt Johnston]

Hi Peter,

This should be fixed in https://secure.ucc.asn.au/hg/dropbear/rev/0dc3103a5900 


Dropbear was advertising both the existing ecdsa size as well as the default 
size (for -R), 
but then the client chose the default size which didn't match the key that had 
been loaded.
Now it only advertises a single size - first preference existing size, 
otherwise the default if no 
key exists.
Thanks for letting me know and debugging.

Cheers,
Matt


> On Mon 5/3/2018, at 4:02 pm, Peter Krefting  wrote:
> 
> Matt Johnston:
> 
>> Yes it should. I can't immediately reproduce it here, what
>> flags are you giving to Dropbear? Is
>> /mnt/nv/dropbear_ecdsa_host_key specified with -r or as a
>> default config path, and are there other keyfiles?
> 
> The daemon is started with "dropbear -R", and the keyfiles are specified at 
> compile-time, using localoptions.h. The full file is included below.
> 
>> ssh -vvv will print the full set of negotiated algorithms,
>> you could send that to me (off-list if you want).
> 
> I have included the output below
> 
>> The relevant revision for that changelog note is
>> https://secure.ucc.asn.au/hg/dropbear/rev/016b86f03e21
>> you could try reverting that to confirm.
> 
> That does not seem to fix the issue, it aborts in the same location, so it 
> seems something else is going on here.
> 
> 
> ===[ localoptions.h ]===
> /* Put host keys in non-volatile storage */
> #define DSS_PRIV_FILENAME "/mnt/nv/dropbear_dss_host_key"
> #define RSA_PRIV_FILENAME "/mnt/nv/dropbear_rsa_host_key"
> #define ECDSA_PRIV_FILENAME "/mnt/nv/dropbear_ecdsa_host_key"
> 
> /* Disable inetd mode */
> #define INETD_MODE 0
> 
> /* Disable X11 forwarding as we do not have any X11. */
> #define DROPBEAR_X11FWD 0
> 
> /* Disable port forwarding and proxying and agent forwarding. */
> #define DROPBEAR_CLI_LOCALTCPFWD 0
> #define DROPBEAR_CLI_REMOTETCPFWD 0
> #define DROPBEAR_SVR_LOCALTCPFWD 0
> #define DROPBEAR_SVR_REMOTETCPFWD 0
> #define DROPBEAR_SVR_AGENTFWD 0
> #define DROPBEAR_CLI_AGENTFWD 0
> #define DROPBEAR_CLI_PROXYCMD 0
> #define DROPBEAR_CLI_NETCAT 0
> 
> /* Disable Twofish to save about 10 kilobytes. */
> #define DROPBEAR_TWOFISH256 0
> #define DROPBEAR_TWOFISH128 0
> 
> /* Disable /etc/motd support since nothing else on the target uses it. */
> #define DO_MOTD 0
> 
> /* Put client keys in non-volatile storage */
> #define DROPBEAR_DEFAULT_CLI_AUTHKEY "/mnt/nv/id_dropbear"
> 
> /* Disable sftp support (as we do not have a binary for sftp installed). */
> #define DROPBEAR_SFTPSERVER 0
> 
> /* Patch it to use the same default PATH as the telnet daemon. This will
> * fix scripts that assume certain tools are in the path. */
> #define DEFAULT_PATH 
> "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
> ===[ end localoptions.h ]===
> 
> ===[ output from ssh - ]===
> $ ssh - root@10.0.30.175
> OpenSSH_7.4p1 Debian-10+deb9u2, OpenSSL 1.0.2l  25 May 2017
> debug1: Reading configuration data /home/peter/.ssh/config
> debug1: /home/peter/.ssh/config line 54: Applying options for 10.0.30.175
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug2: resolving "10.0.30.175" port 22
> debug2: ssh_connect_direct: needpriv 0
> debug1: Connecting to 10.0.30.175 [10.0.30.175] port 22.
> debug1: Connection established.
> debug1: identity file /home/peter/.ssh/id_rsa type 1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/peter/.ssh/id_rsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/peter/.ssh/id_dsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/peter/.ssh/id_dsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/peter/.ssh/id_ecdsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/peter/.ssh/id_ecdsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/peter/.ssh/id_ed25519 type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/peter/.ssh/id_ed25519-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u2
> debug1: Remote protocol version 2.0, remote software version dropbear_2018.76
> debug1: no match: dropbear_2018.76
> debug2: fd 3 setting O_NONBLOCK
> debug1: Authenticating to 10.0.30.175:22 as 'root'
> debug3: hostkeys_foreach: reading file "/home/peter/.ssh/known_hosts"
> debug3: record_hostkey: found key type ECDSA in file 
> /home/peter/.ssh/known_hosts:126
> debug3: load_hostkeys: loaded 1 keys from 10.0.30.175
> debug3: order_hostkeyalgs: prefer hostkeyalgs: 
> 

Re: Dropbear 2018.76

[Peter Krefting]

Matt Johnston:


Yes it should. I can't immediately reproduce it here, what
flags are you giving to Dropbear? Is
/mnt/nv/dropbear_ecdsa_host_key specified with -r or as a
default config path, and are there other keyfiles?


The daemon is started with "dropbear -R", and the keyfiles are 
specified at compile-time, using localoptions.h. The full file is 
included below.



ssh -vvv will print the full set of negotiated algorithms,
you could send that to me (off-list if you want).


I have included the output below


The relevant revision for that changelog note is
https://secure.ucc.asn.au/hg/dropbear/rev/016b86f03e21
you could try reverting that to confirm.


That does not seem to fix the issue, it aborts in the same location, 
so it seems something else is going on here.



===[ localoptions.h ]===
/* Put host keys in non-volatile storage */
#define DSS_PRIV_FILENAME "/mnt/nv/dropbear_dss_host_key"
#define RSA_PRIV_FILENAME "/mnt/nv/dropbear_rsa_host_key"
#define ECDSA_PRIV_FILENAME "/mnt/nv/dropbear_ecdsa_host_key"

/* Disable inetd mode */
#define INETD_MODE 0

/* Disable X11 forwarding as we do not have any X11. */
#define DROPBEAR_X11FWD 0

/* Disable port forwarding and proxying and agent forwarding. */
#define DROPBEAR_CLI_LOCALTCPFWD 0
#define DROPBEAR_CLI_REMOTETCPFWD 0
#define DROPBEAR_SVR_LOCALTCPFWD 0
#define DROPBEAR_SVR_REMOTETCPFWD 0
#define DROPBEAR_SVR_AGENTFWD 0
#define DROPBEAR_CLI_AGENTFWD 0
#define DROPBEAR_CLI_PROXYCMD 0
#define DROPBEAR_CLI_NETCAT 0

/* Disable Twofish to save about 10 kilobytes. */
#define DROPBEAR_TWOFISH256 0
#define DROPBEAR_TWOFISH128 0

/* Disable /etc/motd support since nothing else on the target uses it. */
#define DO_MOTD 0

/* Put client keys in non-volatile storage */
#define DROPBEAR_DEFAULT_CLI_AUTHKEY "/mnt/nv/id_dropbear"

/* Disable sftp support (as we do not have a binary for sftp 
installed). */

#define DROPBEAR_SFTPSERVER 0

/* Patch it to use the same default PATH as the telnet daemon. This will
 * fix scripts that assume certain tools are in the path. */
 #define DEFAULT_PATH 
"/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"

===[ end localoptions.h ]===

===[ output from ssh - ]===
$ ssh - root@10.0.30.175
OpenSSH_7.4p1 Debian-10+deb9u2, OpenSSL 1.0.2l  25 May 2017
debug1: Reading configuration data /home/peter/.ssh/config
debug1: /home/peter/.ssh/config line 54: Applying options for 
10.0.30.175

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.30.175" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.30.175 [10.0.30.175] port 22.
debug1: Connection established.
debug1: identity file /home/peter/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/peter/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/peter/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/peter/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/peter/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/peter/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/peter/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/peter/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u2
debug1: Remote protocol version 2.0, remote software version 
dropbear_2018.76

debug1: no match: dropbear_2018.76
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.30.175:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/peter/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file 
/home/peter/.ssh/known_hosts:126

debug3: load_hostkeys: loaded 1 keys from 10.0.30.175
debug3: order_hostkeyalgs: prefer hostkeyalgs: 
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521

debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: 
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: 

Re: Dropbear 2018.76

[Steffen Nurpmeso]

I want to point out that Konstantin Tokarev was Cc:d in my
message, his name has been stripped by the ML.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Dropbear 2018.76

[Steffen Nurpmeso]

Matt Johnston  wrote:
 |On 2 March 2018 6:17:42 pm AWST, Konstantin Tokarev  \
 |wrote:
 |>02.03.2018, 00:18, "Steffen Nurpmeso" :
 |>>> ok?? Ok, so how about "-o ProxyLocalhost=PORT"?
 |>
 |>There is no such option in openssh
 |
 |I'm not opposed to adding options just for dropbear. Another alternative \
 |that might be more flexible would be 
 |
 |-o keyhostname=example.com localhost:7766
 |
 |With example.com used for known_hosts matching. Then the proxy tcp \
 |destination could be a remote host too if desired. Thoughts?

I do not like the hunk in cli-runopts.c, line 681.  The test is
now useless and depends on the order on the command line.

Regarding yours: isn't that much harder to implement?  The nice
thing about this patch is that it is so small and could be carried
along for over four years without having a look :).  I mean, today
with all those docker images and entire vde2 local networks etc.
the need as such can easily be seen as something ridiculous,
i know...

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Dropbear 2018.76

[Konstantin Tokarev]

02.03.2018, 00:18, "Steffen Nurpmeso" :
> Hello Matt.
>
> Matt Johnston  wrote:
>  |> On Wed 28/2/2018, at 12:59 am, Steffen Nurpmeso  \
>  |> wrote:
>  |> And yes, i am still using such grumpy networks with VMs, so please
>  |> let me post the "git am" mailbox that adds support for proxy-over-
>  |> localhost.
>  ...
>  |Thanks for the patch, though I'm not sure it's worth adding this as \
>  |a special case - can't the same thing be
>  |achieved with dbclient -J "nc localhost port" ?
>
> Yes i think so, but this requires context switching or
> at least quite some I/O that is useless. Some boxes
> also do not have nc(1) by default. And all that just because of
> a little name switch (that is impossible without this patch).
>
>  |Adding proxycommand as a -o option might be worthwhile though, so it \
>  |can pass to scp.
>
> ok?? Ok, so how about "-o ProxyLocalhost=PORT"?

There is no such option in openssh

> Find that attached at your will.
> Ciao,
>
> --steffen
> |
> |Der Kragenbaer, The moon bear,
> |der holt sich munter he cheerfully and one by one
> |einen nach dem anderen runter wa.ks himself off
> |(By Robert Gernhardt)

-- 
Regards,
Konstantin

Re: Dropbear 2018.76

[Matt Johnston]

Hi Peter,
On Thu, Mar 01, 2018 at 10:37:19AM +0100, Peter Krefting wrote:
> After upgrading to 2018.76, I can no longer log in. On the dropbear end, it
> complains about not being able to read the host key (/mnt/nv is the
> non-volatile storage in my target HW):
> 
> Mar  1 11:19:03 gbprobe authpriv.info dropbear[11579]: Child connection from 
> 10.0.30.15:50746
> Mar  1 11:19:03 gbprobe authpriv.info dropbear[11579]: Exit before auth: 
> Couldn't read or generate hostkey /mnt/nv/dropbear_ecdsa_host_key
...
> > - Default generated ECDSA key size is now 256 (rather than 521)
> >  for better interoperability
> 
> But shouldn't it keep working with already existing host keys in the other
> format?

Yes it should. I can't immediately reproduce it here, what
flags are you giving to Dropbear? Is
/mnt/nv/dropbear_ecdsa_host_key specified with -r or as a
default config path, and are there other keyfiles? 
ssh -vvv will print the full set of negotiated algorithms,
you could send that to me (off-list if you want).

The relevant revision for that changelog note is
https://secure.ucc.asn.au/hg/dropbear/rev/016b86f03e21
you could try reverting that to confirm.

> Confusingly, the changelog calls it "local_options.h". Additionally, I found
> that the "localoptions.h" file must be placed in the build tree, not the
> source tree, when doing out-of-tree builds. This makes a lot of sense, but
> took me some time to figure out :-)

Ah, I'll fix the docs.

Thanks,
Matt

Re: Dropbear 2018.76

[Matt Johnston]

> On Wed 28/2/2018, at 12:59 am, Steffen Nurpmeso  wrote:
> And yes, i am still using such grumpy networks with VMs, so please
> let me post the "git am" mailbox that adds support for proxy-over-
> localhost.

Hi Steffen,

Thanks for the patch, though I'm not sure it's worth adding this as a special 
case - can't the same thing be
achieved with dbclient -J "nc localhost port" ?

Adding proxycommand as a -o option might be worthwhile though, so it can pass 
to scp.

Cheers,
Matt

Re: Dropbear 2018.76

[Matt Johnston]

> On Tue 27/2/2018, at 11:28 pm, Konstantin Tokarev  wrote:
>> 
>> - Add 'dbclient -J ' to allow dbclient to connect over an existing socket.
>>   See dbclient manpage for a socat example. Patch from Harald Becker
> 
> Wouldn't it be better to support -o ProxyUseFdPass like in OpenSSH?

Oh I hadn't seen the ProxyUseFdPass option. I'll put it on the todo list for 
the next release.

Cheers,
Matt

Re: Dropbear 2018.76

[Steffen Nurpmeso]

Matt Johnston  wrote:
 |Dropbear 2018.76 is released. As well as the usual

Thank you!

And yes, i am still using such grumpy networks with VMs, so please
let me post the "git am" mailbox that adds support for proxy-over-
localhost.

Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


db-diff.mbox
Description: application/mbox

Re: Dropbear 2018.76

[Konstantin Tokarev]

27.02.2018, 17:54, "Matt Johnston" :
> Hi all,
>
> Dropbear 2018.76 is released. As well as the usual
> improvements and bugfixes this release simplifies
> local configuration options.
> You will probably need to adjust your build configuration.
>
> Rather than modifying options.h, local options are now
> placed in localoptions.h where they will override defaults.
> The header file default_options.h lists the available
> options similar to the old options.h - it should be left
> unmodified.
>
> There are a few other deprecations/changes to take note of.
>
> Cheers,
> Matt
>
> https://matt.ucc.asn.au/dropbear/dropbear.html
> https://dropbear.nl/mirror/dropbear.html
>
> 2018.76 - 27 February 2018
>
> = = = Configuration/compatibility changes
>   IMPORTANT
>   Custom configuration is now specified in local_options.h rather than 
> options.h
>   Available options and defaults can be seen in default_options.h
>
>   To migrate your configuration, compare your customised options.h against the
>   upstream options.h from your relevant version. Any customised options should
>   be put in localoptions.h
>
> - "configure --enable-static" should now be used instead of "make STATIC=1"
>   This will avoid 'hardened build' flags that conflict with static binaries
>
> - Set 'hardened build' flags by default if supported by the compiler.
>   These can be disabled with configure --disable-harden if needed.
>   -Wl,-pie
>   -Wl,-z,now -Wl,-z,relro
>   -fstack-protector-strong
>   -D_FORTIFY_SOURCE=2
>   # spectre v2 mitigation
>   -mfunction-return=thunk
>   -mindirect-branch=thunk
>
>   Spectre patch from Loganaden Velvindron
>
> - "dropbear -r" option for hostkeys no longer attempts to load the default
>   hostkey paths as well. If desired these can be specified manually.
>   Patch from CamVan Nguyen
>
> - group1-sha1 key exchange is disabled in the server by default since
>   the fixed 1024-bit group may be susceptible to attacks
>
> - twofish ciphers are now disabled in the default configuration
>
> - Default generated ECDSA key size is now 256 (rather than 521)
>   for better interoperability
>
> - Minimum RSA key length has been increased to 1024 bits
>
> = = = Other features and fixes
>
> - Add runtime -T max_auth_tries option from Kevin Darbyshire-Bryant
>
> - Add 'dbclient -J ' to allow dbclient to connect over an existing socket.
>   See dbclient manpage for a socat example. Patch from Harald Becker

Wouldn't it be better to support -o ProxyUseFdPass like in OpenSSH?

>
> - Add "-c forced_command" option. Patch from Jeremy Kerr
>
> - Restricted group -G option added with patch from stellarpower
>
> - Support server-chosen TCP forwarding ports, patch from houseofkodai
>
> - Allow choosing outgoing address for dbclient with -b 
> [bind_address][:bind_port]
>   Patch from houseofkodai
>
> - Makefile will now rebuild object files when header files are modified
>
> - Add group14-256 and group16 key exchange options
>
> - curve25519-sha256 also supported without @libssh.org suffix
>
> - Update bundled libtomcrypt to 1.18.1, libtommath to 1.0.1
>   This fixes building with some recent versions of clang
>
> - Set PAM_RHOST which is needed by modules such as pam_abl
>
> - Improvements to DSS and RSA public key validation, found by OSS-Fuzz.
>
> - Don't exit when an authorized_keys file has malformed entries. Found by 
> OSS-Fuzz
>
> - Fix null-pointer crash with malformed ECDSA or DSS keys. Found by OSS-Fuzz
>
> - Numerous code cleanups and small issues fixed by Francois Perrad
>
> - Test for pkt_sched.h rather than SO_PRIORITY which was problematic with 
> some musl
>   platforms. Reported by Oliver Schneider and Andrew Bainbridge
>
> - Fix some platform portability problems, from Ben Gardner
>
> - Add EXEEXT filename suffix for building dropbearmulti, from William Foster
>
> - Support --enable- properly for configure, from Stefan Hauser
>
> - configure have_openpty result can be cached, from Eric Bénard
>
> - handle platforms that return close() < -1 on failure, from Marco Wenzel
>
> - Build and configuration cleanups from Michael Witten
>
> - Fix libtomcrypt/libtommath linking order, from Andre McCurdy
>
> - Fix old Linux platforms that have SYS_clock_gettime but not CLOCK_MONOTONIC
>
> - Update curve25519-donna implementation to current version

-- 
Regards,
Konstantin