Re: Problem using reverse ssh tunnel (remote port forwading)

2018-05-29 Thread Matt Johnston
Hi Ben,

Does the device log anything from Dropbear in /var/log/auth.log or similar? If 
you "telnet localhost 10022" does it print anything?

Cheers,
Matt

> On Fri 25/5/2018, at 11:05 pm, Ben Kinsella  
> wrote:
> 
> I have various devices on a private network behind a router, and I typically 
> use “ssh -R” to access them.
> i.e. On the device I run
> $ ssh -fN -R :10022:localhost:22 user@relayserver
> Then I can ssh in via relayserver.
>  
> This works for several different device types.
> However, it is not working for a particular device with dropbear v2017.75.
> The initial “ssh -R” command works (I can confirm with netstat on 
> relayserver), but when I attempt to connect I get an error:
> $ ssh -p 10022 root@localhost
> ssh_exchange_identification: Connection closed by remote host
>  
> Any suggestions?
>  
> Regards,
> Ben.



Re: Dropbear incompatible with current python Twisted

2018-06-05 Thread Matt Johnston
The most likely cause would be that Twisted doesn't handle firstPacketFollows 
properly, which seems to be the case looking at 
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/ssh/transport.py#L869
 
Can you add that to the Twisted bug report?

Cheers,
Matt


> On Tue 5/6/2018, at 1:12 am, Michael Ducharme  wrote:
> 
> I recently upgraded our Zenoss system to 6.1.2 which includes a newer version 
> of Twisted python framework. This new version of Twisted no longer connects 
> to dropbear on our Ubiquiti radios.
> 
> When Twisted tries to connect, the connection is lost while authenticating, 
> and dropbear logs the error:
> 
> Jun  4 10:29:02 dropbear[28183]: Child connection from 206.red.ac.ted:60338
> Jun  4 10:29:04 dropbear[28183]: Exit before auth: Integrity error
> Jun  4 10:29:07 dropbear[28195]: Child connection from 206.red.ac.ted:60342
> Jun  4 10:29:09 dropbear[28195]: Exit before auth: Integrity error
> 
> I've been able to reproduce this issue with the latest release of twisted, 
> 18.4.0, which I installed on another server by itself. This issue did not 
> happen on the 2 or 3 year old version of Zenoss we were upgrading from, which 
> presumably used an older version of Twisted.
> 
> I submitted a bug report with twisted 
> (https://twistedmatrix.com/trac/ticket/9464 
> ) but thought I would ask here on 
> the off chance that it is due to a dropbear bug.



Re: dropbear: "Failed loading .. " host key files warning messages

2018-02-22 Thread Matt Johnston
Thank you CamVan, I've applied the patch now.

Cheers,
Matt

> On Wed 21/2/2018, at 5:54 am, Camvan T Nguyen  wrote:
> 
> In our environment, we generate an RSA host key in /var/lib/dropbear and 
> start the dropbear service with the following command:
> 
> /usr/sbin/dropbear -i -r /var/lib/dropbear/dropbear_rsa_host_key -B
> 
> We are getting the following Warning messages:
> 
> Feb 20 06:08:50 witherspoon dropbear[1406]: Failed loading 
> /etc/dropbear/dropbear_rsa_host_key
> Feb 20 06:08:50 witherspoon dropbear[1406]: Failed loading 
> /etc/dropbear/dropbear_dss_host_key
> Feb 20 06:08:50 witherspoon dropbear[1406]: Failed loading 
> /etc/dropbear/dropbear_ecdsa_host_key
> 
> This is because in our environment, we don't generate the 3 types of host 
> keys in /etc/dropbear. Dropbear will first load the host key specified by the 
> -r option and then will also try to load all 3 types of host keys from the 
> default path /etc/dropbear. We propose the following patch be made to 
> dropbear svr-runopts.c such that dropbear will only load the host keys from 
> the default /etc/dropbear path if a key is not specified by the -r option.
> 
> 
> From b2048847702e00df8d404896323857f89cda215e Mon Sep 17 00:00:00 2001
> From: CamVan Nguyen 
> Date: Tue, 20 Feb 2018 15:34:00 -0600
> Subject: [PATCH 1/1] Only load dropbear default host keys if a key is not
> specified
> 
> ---
> svr-runopts.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/svr-runopts.c b/svr-runopts.c
> index 3d97023..38a1b75 100644
> --- a/svr-runopts.c
> +++ b/svr-runopts.c
> @@ -510,17 +510,20 @@ void load_all_hostkeys() {
> m_free(hostkey_file);
> }
> 
> + /* Only load default host keys if a host key is not specified by the user */
> + if (0 == svr_opts.num_hostkey_files) {
> #if DROPBEAR_RSA
> - loadhostkey(RSA_PRIV_FILENAME, 0);
> + loadhostkey(RSA_PRIV_FILENAME, 0);
> #endif
> 
> #if DROPBEAR_DSS
> - loadhostkey(DSS_PRIV_FILENAME, 0);
> + loadhostkey(DSS_PRIV_FILENAME, 0);
> #endif
> 
> #if DROPBEAR_ECDSA
> - loadhostkey(ECDSA_PRIV_FILENAME, 0);
> + loadhostkey(ECDSA_PRIV_FILENAME, 0);
> #endif
> + }
> 
> #if DROPBEAR_DELAY_HOSTKEY
> if (svr_opts.delay_hostkey) {
> --
> 1.8.2.2
> 
> 
> Thanks, 
> CamVan Nguyen
> POWER Firmware Tools Development & Support, STG
> 512-286-7756 T/L: 363-7756



Re: User enumeration in Dropbear 2018.76 and earlier

2018-08-20 Thread Matt Johnston
On Mon 20/8/2018, at 5:50 pm, Matthijs R. Koot  wrote:
> 
> The user enumeration issue in OpenSSH [0] also exists in Dropbear 2018.76
> and earlier; at least going back to w/v2013.58 (didn't test with earlier
> versions yet). It is specifically related to this code in svr-auth.c [1]:
> [0] http://seclists.org/oss-sec/2018/q3/124
> [1] https://github.com/mkj/dropbear/blob/master/svr-auth.c#L175-L188

Hi Matthijs,

I can confirm Dropbear has the same problem, probably all versions. I should 
have a patch in the next couple of days.

This allows someone to remotely know whether a particular username exists or 
not on a server. In some circumstances that could be a problem, though by 
itself it doesn't allow exploitation of a server.

Some background, OpenSSH and Dropbear don't share authentication code but they 
both took a similar approach to handling authentication request packets. The 
SSH_MSG_USERAUTH message structure varies depending on the "method" field [ZZ], 
so the subsequent fields only get read after the username has been handled - 
that needs to be handled carefully. I might have looked at the OpenSSH auth 
code when first implementing Dropbear's, though it doesn't really look familar 
now.

Cheers,
Matt


[ZZ] https://tools.ietf.org/html/rfc4252#section-7
eg
  byte  SSH_MSG_USERAUTH_REQUEST
  stringuser name
  stringservice name
  stringmethod name  ("publickey", "password" etc)
   method specific fields



Re: The website is down

2018-08-25 Thread Matt Johnston
Working again now, LACP stopped working between some switches.

https://dropbear.nl/mirror/ is the geographically separate mirror.

Cheers,
Matt

On 25 August 2018 6:02:04 pm AWST, Roy Tam  wrote:
>Dear Cody,
>
>github code mirror is still accessible: https://github.com/mkj/dropbear
>
>2018-08-25 4:44 GMT+08:00 Cody Scott :
>> The website and download links are down.
>>
>> https://matt.ucc.asn.au/dropbear/releases/
>>
>>


Re: potential bug in atomicio?

2018-07-17 Thread Matt Johnston
On Wed, Jul 11, 2018 at 05:26:17PM -0300, Daniel Gutson wrote:
> Hi,
> 
>considering this:
> 
> https://github.com/mkj/dropbear/blob/d740dc548924f2faf0934e5f9a4b83d2b5d6902d/atomicio.c#L55
...
> What if res is negative less than -1, for example -2 ? Shouldn't be a check
> there that res is > 0 ?

Hi Daniel,

atomicio() is always to be called with f == read or f == write which both
won't return a value <-1. Have you found a platform that doesn't do that?
I'd probably write it as "ret < 0" myself but it was a
straight copy from OpenSSH's tree.

Cheers,
Matt


Re: ifndef_wrapper.sh required sed with "-E" which isn't available with old sed version.

2018-07-24 Thread Matt Johnston
On Mon, Jul 23, 2018 at 01:08:54PM +0800, Samuel Hsu wrote:
> As titled, can we use "sed -r" instead of "sed -E".

Hi Samuel,

Thanks, I hadn't noticed that problem. I've pushed a change
to uses non-extended regexes which should work everywhere.

https://secure.ucc.asn.au/hg/dropbear/rev/0196f4f83fee

Cheers,
Matt


Re: Dropbear 2018.76

2018-03-08 Thread Matt Johnston
Hi Peter,

This should be fixed in https://secure.ucc.asn.au/hg/dropbear/rev/0dc3103a5900 
<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 <pe...@softwolves.pp.se> 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

Re: Dropbear 2018.76

2018-03-01 Thread 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 server exit when idle?

2018-03-09 Thread Matt Johnston
Hi Dave,

My first approach would be to run "timeout 600 dropbear -F
-E".  Established sessions won't be killed since they each
session is a forked process. That assumes "timeout" exists
on the system busybox etc.

If you want to modify the code put a check after the
select() in main_noinetd(). As-is it seems fairly specific
so mightn't be worth merging, though maybe there's a more
general way to do it.

Cheers,
Matt

On Thu, Mar 08, 2018 at 02:41:12PM +, Dave Haynes wrote:
> We have a small range of embedded linux devices used in security systems. We
> are undertaking a gradual process to harden the default security, and one of
> our first tasks has been replace the legacy telnet server with dropbear for
> diagnostic access.
> 
> We have compiled dropbear and have it running well, set up to only allow one
> session using a patch found on this list.
> 
> We are now considering if it would be worthwhile/useful to modify dropbear
> to exit after a period with no active connections. So dropbear runs at boot,
> but exits after (say) 10 minutes with no login. The devices can be remotely
> rebooted via other means, so there are no access issues for authorised
> users.
> 
> Does anyone see any reason this wouldn't be a useful approach? Anyone
> patched anything similar before we start hacking about, or any pointers
> where to start?
> 
> (We could give the system a task to terminate dropbear, but it would seem
> neater to produce a self contained solution.)
> 
> -- 
> Dave Haynes
> RF Design Consultant - Wireless Solutions Ltd.
> 


Re: Dropbear ssh tunneling segfault

2018-03-21 Thread Matt Johnston
I suspect selinux is blocking something, after dropbear forks to run the shell. 
Can you find where selinux keeps its logs?
When you run 'su' it enters a less restrictive context than normal root, so it 
runs ok.

I guess you need to create a selinux policy for the dropbear service - i don't 
have much experience with that though, sorry.

https://source.android.com/security/selinux/device-policy

Cheers,
Matt

On 21 March 2018 9:20:38 pm AWST, Hayk Beglaryan  
wrote:
>Dear Matt,
>
>Thanks for fast reply. 
>[1] Yes I run dropbear from adb shell and it’s works correctly. My
>steps are followings: 
>   $ adb connect [device ip]
>   $ adb shell
>   # su
>   # dropbear -E -R
>
>[2] Please find requested logfile1.txt attached.
>
>[3] Running "ssh -i ssh_rsa_key root@localhost -p 56048 df” doesn’t
>work at all.
>
>Regard,
>Hayk 


Dropbear 2018.76

2018-02-27 Thread 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

- 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


Re: Dropbear 2018.76

2018-02-28 Thread 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

2018-02-28 Thread 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: Login attempt for nonexistent user

2018-10-31 Thread Matt Johnston
Hi Laurent,

My best guess is that it was built on lubuntu which uses glibc, but the Udoo 
board doesn't have the required /lib/somewhere/libnss*.so libraries - those get 
chosen at runtime based on /etc/nsswitch.conf. Building using a uclibc cross 
compiler would avoid that - how did you build it? Also which distribution does 
Udoo use?

If you can install strace on the Udoo board you can see what files are being 
tried with
strace -f -F -o logfile -s 300 dropbear -vFE

Cheers,
Matt


> On Tue 30/10/2018, at 5:28 pm, Laurent Bourdel  wrote:
> 
> 
> with correct subject :
> 
> Hi,
> 
> I fail to login with ssh client to dropbox
> 
> I use Udoo ARM board with busybox to install ssh server
> 
> I cross compiled dropbear under VirtualBox lubuntu and install binary to 
> board ( /bin & /sbin)
> 
> I generate RSA key (ssh-keygen -t rsa ) under lubuntu and copied  content to 
> /home/root/.ssh/authorized_keys on Udoo board
> 
> I run on Udoo board : dropbear -vFE
> 
> On VM lubuntu : ssh  -vvv root@192.168.0.2
> 
> I add trace on dropbear sources and found problem come with function getpwnam 
> to read /etc/password with 
> 
> errno=0;
> pw = getpwnam(username);
> 
> dropbear_log(LOG_WARNING,"LBR %s %d %s",__FILE__ ,__LINE__, strerror(errno));
> if (!pw) {
> return;
> }
> 
> [157] Jan 01 01:06:50 LBR common-session.c 595 No such file or directory



Re: dbclient can't connect to cisco

2018-11-16 Thread Matt Johnston


> On Fri 16/11/2018, at 2:26 am, Nik Soggia  wrote:
> 
> So in the end if I delay the kexinit until there is some data on the wire I 
> will pull the rabbit out of the cylinder.

The problem is that waiting for the remote banner is still adding a round trip 
of delay. That's fine for a local network, but me -> dropbear.nl is half a 
second, that's no good.

Cheers,
Matt

Re: dbclient can't connect to cisco

2018-11-14 Thread Matt Johnston
Hi Nik,

> 
> dbclient sends "SSH-2.0-dropbear_2018.76\r\n" and kexinit
> cisco sends "SSH-2.0-Cisco-1.25\r\n"
> then cisco waits "ip ssh time-out" seconds and then closes the TCP socket.
> 
> my conjecture is that cisco empties its receive buffer after sendind the 
> identification string and then waits for the lost kexinit.
> To prove my idea I added a sleep() after the first write_packet(), and 
> dbclient was able to connect to cisco (ios 12.4 and 15.1).

Yes, it seems some Cisco SSH versions are buggy. Older IOS is possibly OK (I 
did a bit of investigation about a year ago when someone reported similar). 

I'm not keen on changing dbclient, the current implementation saves a network 
roundtrip. It's perfectly reasonable according to the spec. If you have Cisco 
support could you report it to them?

Cheers,
Matt

rfc4253:
5.2.  New Client, Old Server

   Since the new client MAY immediately send additional data after its
   identification string (before receiving the server's identification
   string), ...




Re: dbclient can't connect to cisco

2018-11-14 Thread Matt Johnston
On Wed, Nov 14, 2018 at 06:20:59PM +0300, Konstantin Tokarev wrote:
> Note that OpenSSH enables a couple of workarounds for Cisco-1.*
> 
> https://github.com/openssh/openssh-portable/blob/master/compat.c#L88

The tricky thing is that dbclient can't do anything to work around
it here. We haven't yet received the version banner when we
send the first key exchange packet.

Cheers,
Matt


Re: Strange behaviour surrounding "ssh -T ..." and non-zero exit

2018-11-14 Thread Matt Johnston
Hi Mike,

> On Sat 10/11/2018, at 12:52 am, W. Michael Petullo  wrote:
> 
> 
> Here is a more practical example which demonstrates the problem:
> 
> $ echo false | dbclient -T r...@host.example.com
> $ echo $?
> 0

I think this should now _really_ be fixed with
https://secure.ucc.asn.au/hg/dropbear/rev/79eef94ccea9

dbclient was ignoring all packets for channels that were in the process of 
being closed, which included exit status messages.

Cheers,
Matt

Re: Strange behaviour surrounding "ssh -T ..." and non-zero exit

2018-11-09 Thread Matt Johnston
Hi Michael,

On 2018-11-09 3:48 pm, W. Michael Petullo wrote:
>> I am using Dropbear v2017.75 as found on OpenWrt.
>> 
>> echo input | ssh -T h; echo $?
>> 
>> Despite the error occurring, the above command line prints `0' rather
>> than `1.' Since this triggers the error, I would expect the latter
>> instead.
> 
> After looking at the code, it appears this block in common-channel.c is
> the culprit (line 346):

> I think ssh is reaching the EOF on stdin, and then this block causes 
> the
> channel to close before it reads the exit code from the distant end.

I think this problem might be fixed in v2018.76, 
https://secure.ucc.asn.au/hg/dropbear/rev/0c16b4ccbd54#l4.46 

Now the exit code check happens before the line you noted. Somehow that 
got missed in CHANGES.

Cheers,
Matt

Dropbear 2019.78

2019-03-27 Thread Matt Johnston
Hi all,

Dropbear 2019.78 is released. There was a regression
in dbclient 2019.77, terminal modes would not be reset when
the client exited. The server has no changes.

Cheers,
Matt


2019.78 - 27 March 2019

- Fix dbclient regression in 2019.77. After exiting the terminal would be left
  in a bad state. Reported by Ryan Woodsmall


https://matt.ucc.asn.au/dropbear/dropbear.html
https://dropbear.nl/mirror/
Signing key F734 7EF2 EE2E 07A2 6762  8CA9 4493 1494 F29C 6773


Re: Dropbear 2019.77

2019-03-24 Thread Matt Johnston
Beware that dbclient in 2019.77 has a regression, it won't 
reset TTY modes on exit. That's fixed in
https://secure.ucc.asn.au/hg/dropbear/rev/4b01f4826a29

Cheers,
Matt

On Sat, Mar 23, 2019 at 10:02:49PM +0800, Matt Johnston wrote:
> Hi all,
> 
> At long last Dropbear 2019.77 is released. Most changes are
> bug fixes, with a few small features. There are security
> fixes to avoid revealing the existence of valid usernames.
> 
> This release also merges the fuzzing branch. In a
> normal build this should have no effect on operation.
> 
> There are a few larger changes that are ready to merge
> that will have to wait for the next release - I wanted to
> get this bugfix out of the way first.
> 
> Download at
> https://matt.ucc.asn.au/dropbear/dropbear.html
> mirror
> https://dropbear.nl/mirror/dropbear.html
> 
> Cheers,
> Matt
> 
> 2019.77 - 23 March 2019
> 
> - Fix server -R option with ECDSA - only advertise one key size which will be 
> accepted.
>   Reported by Peter Krefting, 2018.76 regression.
> 
> - Fix server regression in 2018.76 where multiple client -R forwards were all 
> forwarded 
>   to the first destination. Reported by Iddo Samet.
> 
> - Make failure delay more consistent to avoid revealing valid usernames, set 
> server password 
>   limit of 100 characters. Problem reported by usd responsible disclosure team
> 
> - Change handling of failed authentication to avoid disclosing valid 
> usernames,
>   CVE-2018-15599. 
> 
> - Fix dbclient to reliably return the exit code from the remote server.
>   Reported by W. Mike Petullo
> 
> - Fix export of 521-bit ECDSA keys, from Christian Hohnstädt
> 
> - Add -o Port=xxx option to work with sshfs, from xcko
> 
> - Merged fuzzing code, see FUZZER-NOTES.md
> 
> - Add a DROPBEAR_SVR_MULTIUSER=0 compile option to run on 
>   single-user Linux kernels (CONFIG_MULTIUSER disabled). From Patrick Stewart
> 
> - Increase allowed username to 100 characters, reported by W. Mike Petullo
> 
> - Update config.sub and config.guess, should now work with RISC-V
> 
> - Cygwin compile fix from karel-m
> 
> - Don't require GNU sed (accidentally in 2018.76), reported by Samuel Hsu
> 
> - Fix for IRIX and writev(), reported by Kazuo Kuroi
> 
> - Other fixes and cleanups from François Perrad, Andre McCurdy, Konstantin 
> Demin,
>   Michael Jones, Pawel Rapkiewicz


Dropbear 2019.77

2019-03-23 Thread Matt Johnston
Hi all,

At long last Dropbear 2019.77 is released. Most changes are
bug fixes, with a few small features. There are security
fixes to avoid revealing the existence of valid usernames.

This release also merges the fuzzing branch. In a
normal build this should have no effect on operation.

There are a few larger changes that are ready to merge
that will have to wait for the next release - I wanted to
get this bugfix out of the way first.

Download at
https://matt.ucc.asn.au/dropbear/dropbear.html
mirror
https://dropbear.nl/mirror/dropbear.html

Cheers,
Matt

2019.77 - 23 March 2019

- Fix server -R option with ECDSA - only advertise one key size which will be 
accepted.
  Reported by Peter Krefting, 2018.76 regression.

- Fix server regression in 2018.76 where multiple client -R forwards were all 
forwarded 
  to the first destination. Reported by Iddo Samet.

- Make failure delay more consistent to avoid revealing valid usernames, set 
server password 
  limit of 100 characters. Problem reported by usd responsible disclosure team

- Change handling of failed authentication to avoid disclosing valid usernames,
  CVE-2018-15599. 

- Fix dbclient to reliably return the exit code from the remote server.
  Reported by W. Mike Petullo

- Fix export of 521-bit ECDSA keys, from Christian Hohnstädt

- Add -o Port=xxx option to work with sshfs, from xcko

- Merged fuzzing code, see FUZZER-NOTES.md

- Add a DROPBEAR_SVR_MULTIUSER=0 compile option to run on 
  single-user Linux kernels (CONFIG_MULTIUSER disabled). From Patrick Stewart

- Increase allowed username to 100 characters, reported by W. Mike Petullo

- Update config.sub and config.guess, should now work with RISC-V

- Cygwin compile fix from karel-m

- Don't require GNU sed (accidentally in 2018.76), reported by Samuel Hsu

- Fix for IRIX and writev(), reported by Kazuo Kuroi

- Other fixes and cleanups from François Perrad, Andre McCurdy, Konstantin 
Demin,
  Michael Jones, Pawel Rapkiewicz


Re: MAX_USERNAME_LEN set too low

2019-03-01 Thread Matt Johnston
Hi Mike,

The limit's arbitrary so 32 would be fine. Maybe even something like 100.
I'll increase it for the next release.

Cheers,
Matt

> On Fri 1/3/2019, at 8:28 am, W. Michael Petullo  wrote:
> 
> Dropbear's auth.h defines MAX_USERNAME_LEN as 25 and provides the
> commentary "arbitrary for the moment."
> 
> The useradd utility from shadow-utils on Linux supports usernames with
> up to 32 characters.
> 
> This means that some valid users cannot make use of SSH, namely users
> for which len(username) is larger than 25 but less than 32.
> 
> 32 seems pretty common. Can we modify Dropbear to use 32 instead of 25?
> 
> -- 
> Mike
> 
> :wq



Re: How to get dbclient?

2019-03-14 Thread Matt Johnston
Hi Gilles,

The main() for each of those is in svr-main.c and cli-main.c respectively. 

https://secure.ucc.asn.au/hg/dropbear/file/tip/cli-main.c#l45

The Makefile is a bit convoluted so that it can also build them all into a 
single binary.
https://secure.ucc.asn.au/hg/dropbear/file/tip/Makefile.in#l69

Cheers,
Matt

> On Wed 13/3/2019, at 5:31 am, Gilles  wrote:
> 
> The INSTALL file in dropbear-2018.76 says
> 
> - Compile:
> 
>   make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"
> 
> Should there be a dropbear.c file and a dbclient.c file? I do not see them.
> 
> I am looking for the dbclient program.
> 
> Thanks to Matt for all his nice work.
> 
> ~ Gilles
> 



Re: Dropbear 2018.76

2019-03-20 Thread 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
> <https://secure.ucc.asn.au/hg/dropbear/rev/0dc3103a5900>?
> 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
> > > <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 when behaving as client sending sha1 as mac

2019-04-11 Thread 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: Configuration Issues

2019-06-23 Thread Matt Johnston
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  
> 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@radsys-nuc:~$ dbclient root@10.160.33.150  
> -i ~/.ssh/id_rsa
> root@10.160.33.150 's password: 
> root@10.160.33.150 's password: 
> 
> dbclient: Connection to root@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@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@radio:~# ls -al /etc/dropbear
> drwxr-xr-x2 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



Re: Forward a UNIX Socket

2019-05-02 Thread Matt Johnston
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  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
> 



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

2019-04-10 Thread 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 and new host keys?

2019-12-11 Thread Matt Johnston
Hi Joakim,

The server needs to be stopped and restarted. If this is for new keys at
first-boot you could look at the -R option.

Cheers,
Matt

On Wed, Dec 11, 2019 at 03:38:36PM +, Joakim Tjernlund wrote:
> Is there a way to tell a running dropbear server to reread host keys if the 
> keys has changed?
> 
>  Jocke 


Re: dropbear and new host keys?

2019-12-16 Thread Matt Johnston


> On Fri 13/12/2019, at 2:14 am, Joakim Tjernlund 
>  wrote:
> 
> On Thu, 2019-12-12 at 18:34 +0100, Hans Harder wrote:
>> 
>>>  The bigger issue here is why not reread keys at every new session? That 
>>> seems to like the right thing to do in any case? 
>> 
>> Performance...

I don't _think_ there would be any performance problem reloading key files for 
each session - compared with the key exchange it's not compute intensive. It's 
better to keep it simple rather than introduce cache invalidation by file 
timestamps where it isn't needed. I'd been considering moving non-inetd 
dropbear to use fork/self-exec instead of plain fork() for improved address 
space randomisation, that would probably require loading keys each time too.

That said if I were in the same situation I'd just run "kill `cat 
/var/run/dropbear.pid; service dropbear start" or similar when writing keyfiles 
- job done.

Cheers,
Matt

Re: Dropbear processes getting into uninterruptible I/O process "D" state

2019-10-15 Thread Matt Johnston
Hi Binny,

I think regardless of what Dropbear's doing with pipes (closed sessions etc), 
there is probably something wrong with the Linux kernel.
As far as I know userspace can't trigger D state even intentionally (I'd be 
interested if anyone knows a way though).
-K is unrelated, that just sends some SSH traffic at a certain interval.

If you can reproduce it, "echo t > /proc/sysrq-trigger" might be helpful - you 
can look at "dmesg" for stack traces of all threads and see what the stuck 
processes are doing in the kernel.
Was there anything unusual in dmesg on the problematic machine?

Cheers,
Matt




> On Mon 14/10/2019, at 12:44 pm, Jeshan, Binny  
> wrote:
> 
> Dear Matt,
>  
> Thank you for your response. Here is our situation said below...
> This has happened to one or two of those users out of a thousand such devices 
> that are deployed. We have never seen this reported since many years now. 
> When the issue was reported, we could only take out the below logs from the 
> user unit. User is in an end customer deployment.
> We do not use NFS, therefore when we checked the disk stats of all processes, 
> nothing was holding on to it, and all other disk r/w operations were working 
> normal. 
> We do not have strace in our target device to debug, nor the problem is 
> reproducible to us easily. It happened only once, and to really debug the 
> problem we have to simulate such condition in our lab. 
>  
> As of now after reading some user guides, I wonder if the below precaution 
> should be added. But I am not sure whether it will help when such situations 
> where Open pipes exist in the process. I believe they are from 
> common_session_init() and session_loop(). 
>  
> Will my approach be right if I use this below flag -K in my situation of drop 
> bear process?  I have a feeling that the Open IPC pipes is also doing sort of 
> an I/O operation that leads to this state of D. And the said user has a habit 
> of not closing the SSH session properly with an exit or logout from the 
> terminal, leaving it to idle-close or abrupt close the terminal.
>  
> -K timeout_seconds
> Ensure that traffic is transmitted at a certain interval in seconds. This is 
> useful for working around firewalls or routers that drop connections after a 
> certain period of inactivity. The trade-off is that a session may be closed 
> if there is a temporary lapse of network connectivity. A setting if 0 
> disables keepalives.
>  
> Please advise your thoughts with the above. I am still working on recreating 
> the problem by just forcing these pipes that are kept open to be there 
> forever in that state. Any other suggestions may help.
>  
>  
> Thanks for your help again,
> Binny
>  
> From: Matt Johnston mailto:m...@ucc.asn.au>> 
> Sent: Wednesday, October 9, 2019 6:56 PM
> To: Jeshan, Binny  <mailto:binny.jes...@netscout.com>>; dropbear@ucc.asn.au 
> <mailto:dropbear@ucc.asn.au>; rwoodsm...@gmail.com 
> <mailto:rwoodsm...@gmail.com>
> Subject: Re: Dropbear processes getting into uninterruptible I/O process "D" 
> state
>  
> This message originated outside of NETSCOUT. Do not click links or open 
> attachments unless you recognize the sender and know the content is safe.
> Hi Binny,
> 
> I don't think it's related to 2019.78
> 
> Usually D state means something else is wrong on the system, bad NFS mounts 
> or IO devices. Can you strace the stuck processes?
> 
> Cheers,
> Matt
> 
> On 9 October 2019 10:53:56 am GMT+07:00, "Jeshan, Binny" 
> mailto:binny.jes...@netscout.com>> wrote:
> Dear all in the mailing list,
>  
> We are seeing a problem with 2018.76 version of the dropbear SSH server which 
> exhibits the following:
>  
>  
> The processes go into uninterruptible “D” state and lies there, couldn’t be 
> killed nor shutdown.
> 
>  
> The stuck processes in the bad state show the below behavior of two open 
> pipes that are not closed.
>  
> 
>  
> The last process with PID 394 seems to work fine, and has no open IPCs.
>  
> When I look at the release notes of 2019.78, I see this: “2019.78 - 27 March 
> 2019
>  
> - Fix dbclient regression in 2019.77. After exiting the terminal would be left
>   in a bad state. Reported by Ryan Woodsmall
> “
>  
> Is the problem that we see is same as you fixed? Please suggest. Your 
> feedback and ideas will help.
>  
>  
> Thanks
> Binny



Re: [PATCH] Add Ed25519 keys support

2020-03-11 Thread Matt Johnston
Thank you Vladislav, I've merged this now via github, 
https://secure.ucc.asn.au/hg/dropbear/rev/d32bcb5c557d

It's a nice clean and thorough implementation.

Cheers,
Matt 


> On Fri 6/3/2020, at 10:45 pm, Vladislav Grishenko  
> wrote:
> 
> Hello,
>  
> Initially inspired by Péter Szabó work from 2017, but made with general 
> approach:
>  
> ·Curve25519/Ed25519 implementation based on TweetNaCl version 
> 20140427, old Google's curve25519_donna dropped as unnecessary, saves a lot 
> of size.
> ·SHA512 reused from LibTomCrypt, no need to keep own copy
> ·Sign/Verify require no additional memory allocation
> ·Dropbear's API made ~similar to LibTomCrypt devel to ease possible 
> switch, if necessary. Anyway, LibTomCrypt is based on TweetNaCl as well.
> ·Default private key path is 
> key/etc/dropbear/dropbear_ed25519_host_key
> ·Implemented general import from / export to OpenSSH private keys, 
> can be reused for other key types on necessary
> ·Implemented *25519 fuzzers, but still need corresponding data from 
> dropbear-fuzzcorpus 
> ·Man, license, commens updated to fit Ed25519
>  
> So far, DROPBEAR_CURVE25519 increases dropbear binary by ~2,5Kb on X86-64 vs 
> ~8Kb of current curve25519_donna implementation.
> DROPBEAR_ED25519 adds ~7,5Kb to dropbear and ~1kB to dropbearconvert for 
> OpenSSH import/export.
>  
> Related PR against current sources is here 
> https://github.com/mkj/dropbear/pull/91 
> , patches are attached.
> Review and/or any suggestios will be highly appreciated.
>  
> Thank you and
> Best Regards, Vladislav Grishenko
> 
> <0001-Add-support-for-Ed25519-as-a-public-key-type.patch><0002-Add-curve25519-and-ed25519-fuzzers.patch><0003-Add-import-and-export-of-Ed25519-keys.patch>



Re: [PATCH 0 of 1] Fix build

2020-03-27 Thread Matt Johnston
> On Thu 26/3/2020, at 6:45 pm, Alexander Dahl  wrote:
> 
> Gentle ping on this patch.

Hi Alex,

Sorry for the delay, it's merged now.

Cheers,
Matt


Re: bug: stdio pipe is root owned so reopening it fails

2020-05-01 Thread Matt Johnston
Hi Szabolcs,

Ah, that's a bit nasty. I guess the difference is that OpenSSH runs the daemon 
as the user, while Dropbear runs as root.

The procfs manpage mentions the problem. 
http://man7.org/linux/man-pages/man5/proc.5.html
  Note that for file descriptors referring to inodes (pipes and
  sockets, see above), those inodes still have permission bits
  and ownership information distinct from those of the
  /proc/[pid]/fd entry, and that the owner may differ from the
  user and group IDs of the process.  An unprivileged process
  may lack permissions to open them, as in this example:

  $ echo test | sudo -u nobody cat
  test
  $ echo test | sudo -u nobody cat /proc/self/fd/0
  cat: /proc/self/fd/0: Permission denied
Not really sure of a good workaround.

Cheers,
Matt


> On Fri 1/5/2020, at 2:46 am, Szabolcs Nagy  wrote:
> 
> hello, when dropbear server runs on host
> 
> $ echo hi | ssh user@host 'cat'
> 
> works as expected (so reading stdin works), but
> 
> $ echo hi | ssh user@host 'cat /proc/self/fd/0'
> 
> fails with EPERM (the open syscall in cat that is).
> 
> it seems the /proc file is user owned but it's a magic symlink
> to a pipe that is owned by root so reopening it fails:
> 
> $ ssh user@host 'stat -L /proc/self/fd/0'
>  File: /proc/self/fd/0
>  Size: 0   Blocks: 0  IO Block: 4096   fifo
> Device: bh/11d  Inode: 7193Links: 1
> Access: (0600/prw---)  Uid: (0/root)   Gid: (0/root)
> Access: 2020-04-30 18:29:01.0
> Modify: 2020-04-30 18:29:01.0
> Change: 2020-04-30 18:29:01.0
> 
> i haven't seen this behaviour with openssh and affects some
> scripts that use /dev/stdin, /dev/stdout, /dev/stderr
> (which just point to /proc/self/fd/{1,2,3})
> 
> if there is a simple workaround i'd like to hear about it.
> thanks



Re: dbclient v2019.78: proxyJump

2020-05-04 Thread Matt Johnston
Hi Adrian,

With dropbear you should be able to list the hosts comma separated

dbclient -i /mydir/id_rsa  username1@server1,username2@server2

Does that work? It should do something equivalent to the first one though, 
unless I've missed something.

Cheers,
Matt

> On Sun 3/5/2020, at 11:38 pm, Adrian Fiergolski  
> wrote:
> 
> Hi,
> 
> I am having troubles connecting to another host though a ssh proxy. The
> command:
> 
> $>dbclient -i /my_dir/id_rsa -J "dbclient -i /my_dir/id_rsa
> username1@server1" username2@server2
> 
> and  
> 
> $>dbclient -i /my_dir/id_rsa -J "dbclient -t -i /my_dir/id_rsa
> username1@server1" username2@server2
> 
> return:
> 
> dbclient: Failed reading termmodes
> dbclient: Connection to username1@server1:22 exited: Failed to set
> raw TTY mode
> dbclient: Connection to username2@server2:22 exited: Remote closed
> the connection
> 
> I have also tried 
> 
> $>dbclient -i /my_dir/id_rsa -J "dbclient -T -i /my_dir/id_rsa
> username1@server1" username2@server2
> 
> but it doesn't connect to the server2 neither.
> 
> The connection to the first host
> 
> dbclient -i /my_dir/id_rsa username1@server1
> 
> works properly.
> 
> What am I doing wrong? How to connect to the final server through the
> ssh proxy using dropbear?
> 
> Regards,
> 
> Adrian
> 
> 



Re: scp command exemple

2020-05-12 Thread Matt Johnston
Hi Bruno,

That syntax should work. What platform is it? Have you tried typing it manually 
in case there were strange unicode characters copy/pasted?

Cheers,
Matt


> On Tue 12/5/2020, at 6:26 pm, bruno  wrote:
> 
> Hello, anyone has an exemple of scp dropbear use ?
> 
> it seems that :
> 
> scp my_file root@targetserver:/tmp/   
> 
> result is
> 
> scp connection to root@my_file existed connect failed : error resolving
> "my_file" port "22". name does not resolve
> 
> Not the same syntax as a standard scp command ?
> 
> any help ?
> 



Re: Timeout settings

2020-03-18 Thread Matt Johnston
Hi Daniel,

-K is equivalent to the OpenSSH ClientAliveInterval. The server will send 
traffic to check that the connection is open.

-I will disconnect if there is no traffic for a certain time interval. It won't 
try to send any traffic over the connection, it just passively looks at what 
traffic is being sent.

Note that it seems that currently -K messages will cause the -I idle timer to 
reset which isn't right, there's a pull request 
https://github.com/mkj/dropbear/pull/90 which I will merge soon.

Cheers,
Matt


> On Wed 18/3/2020, at 7:22 pm, Dániel Fancsali  wrote:
> 
> Hello,
> 
> First of all, let me just say this: awesome piece of software. Cheers!
> 
> I am, however, a bit confused about the idle/keepalive settings. I have been 
> working with OpenSSH quite a bit, and do understand the concepts around 
> ServerAlive and ClientAlive as well as the TCPKeepAlive settings. But I still 
> struggle to wrap my head around -K and -I in dropbear. It's a tad bit unclear 
> which one maps to which one; or in other words, which one happends on what 
> layer.
> 
> Maybe, my mistake here is trying to understand those in the context of the 
> OpenSSH settings, but on some level, it's the same protocol.
> 
> So, looking at the code, I think this is what happens:
> - Setting -Kx will send an ssh packed every x seconds, and if there's no 
> answer 3 times in a row, it considers the connection to be dead. So this is 
> essentially ServerAlive/ClientAlive mechanism.
> - Specifying -Iy would say, if there's no incoming or outgoing data for y 
> seconds, it considers the connection dead. So this is sort of the others side 
> of the TCP keepalive coin.
> 
> Is my understanding correct? If not, can someone please shed some light on 
> this for me?
> 
> Regards,
> Daniel



Re: Hiding dropbear output on boot up

2020-03-18 Thread Matt Johnston
Hi Tania,

I think you could probably add "> /dev/null 2> /dev/null" after one of the 
ipconfig commands in /usr/share/initramfs-tools/scripts/functions, though I'm 
not too familiar with how they all fit together. (Or if it's dhclient for ipv6 
printing the output, get rid of the "-v" for dhclient).

You could report a Debian bug for the initramfs package, they might have a 
better idea of a fix for it.
https://packages.debian.org/stretch/dropbear-initramfs

Cheers,
Matt

> On Wed 18/3/2020, at 8:09 pm, Tania Hagan  wrote:
> 
> Hi Dropbear, 
> 
> I have setup dropbear and busybox on a Ubuntu 18.04 desktop with LUKS 
> encryption.  This works wonderfully except the IP-Config displays over the 
> unlock disk prompt causing confusion with users.  Is there a way to either 
> hide this output or have it display before the LUKS unlock disk prompt?
> 
> Thank you very much for any help.
> Tania



Re: SSH key exchange fails 30-70% of the time on Netgear X4S R7800

2020-03-19 Thread Matt Johnston
Hi,

The first thing I'd try would be to build with -O0 compilation flags to rule 
out compiler optimisations doing something strange. 

Cheers,
Matt


> On Thu 19/3/2020, at 3:42 pm, Horshack ‪‬  wrote:
> 
> Update - I cloned and built the dbclient source so I could enable the debug 
> tracing facility to get more information about the 'Bad hostkey signature'. 
> The intermittent failure is detected in recv_msg_kexdh_reply() -> 
> buf_rsa_verify() -> mp_cmd(). If I bypass the buf_rsa_verify() call then the 
> session proceeds normally without issue, which indicates everything else in 
> the key exchange is working 100% of the time. I'll dig deeper to see why the 
> signed host key sent by the server is wrong.
> 
> From: Horshack ‪‬
> Sent: Wednesday, March 18, 2020 9:36 AM
> To: dropbear@ucc.asn.au 
> Subject: SSH key exchange fails 30-70% of the time on Netgear X4S R7800
>  
> Hi,
> 
> I have a strange issue on my Netgear X4S R7800. Running either DD-WRT or 
> OpenWrt, approximately 30-70% of my SSH login attempts fail. For OpenSSH 
> clients the error reported is "error in libcrypto". For the PuTTY client the 
> error is more descriptive - "Signature from server's host key is invalid". 
> The failure occurs even when using the OpenSSH client built in to OpenWrt 
> itself (ie, SSH'ing into the router from the router via an existing remote 
> SSH session).
> 
> The failure appears to be at the tail end of the key exchange, before 
> authentication. I've tried varying the cipher (aes128-ctr / aes256-ctr), the 
> MAC (hmac-sha1 / hmac-sha2-256), and the key exchange algo (curve25519-sha256 
> / curve25519-sha...@libssh.org / diffie-hellman-group14-sha256 / 
> diffie-hellman-group14-sha1) but the intermittent failure still occurs. The 
> frequency of failure is about the same for all these configuration options 
> except for diffie-hellman-group14-sha256, which fails much more frequently - 
> it sometimes takes hundreds of attempts to succeed. Perhaps that will provide 
> a clue to the underlying cause.
> 
> Once an SSH login succeeds the connection is stable. However if I initiate a 
> manual rekey operation via ~R then the key re-exchange fails. The router is 
> otherwise very stable with no noticeable issues.
> 
> I'm an embedded firmware engineer but have never worked on DD-WRT/OpenWrt 
> firmware or dropbear. I have a conceptual understanding of the key exchange 
> algo but haven't looked at the actual code of any implementation including 
> Dropbear's. I'm seek ideas on how to troubleshoot this issue. Considering the 
> problem is intermittent I'm thinking it's some variant in the key 
> generation/exchange algorithm that's failing due to some issue with the 
> router, or a more remote possibility, an issue with the Dropbear 
> implementation.
> 
> Here are pastebin links to the PuTTY full debug logs (w/raw data dumps) for 
> both the failure and success cases:
> Failure Case: https://pastebin.com/MS2BtFmW 
> Success Case: https://pastebin.com/c4j66Ga9 
> 
> The only message I see from dropbear for a failed connection attempt is:
> 
> authpriv.info dropbear[15948]: Child connection from 192.168.1.249:54819
> authpriv.info dropbear[15948]: Exit before auth: Disconnect received
> 
> 
> Thanks!



Re: SSH key exchange fails 30-70% of the time on Netgear X4S R7800

2020-03-24 Thread Matt Johnston
Good work narrowing down a test case there.
That's an interesting finding - I guess it might be worth posting on OpenWRT 
lists/forum to try find other testers.
Could it be power related if the tight multiplication loop is stressing it 
somehow? It doesn't seem to be using the Neon instruction for anything apart 
from loads/stores though - is there something that the compiler should be doing 
mixing Neon and non-Neon operations?

Cheers,
Matt

(Your emails got held up being over 100kB, I've trimmed the reply below and let 
them through. Apologies to everyone for the stale old one that got let through 
with them just now, I wasn't looking closely)

> On Tue 24/3/2020, at 11:23 am, Horshack ‪‬  wrote:
> 
> I was able to isolate the issue to just a handful of assembly instructions 
> within fast_s_mp_sqr(), related to the squaring loop. I broke that code out 
> into a separate utility that reproduces the issue within a few seconds. The 
> failure is somewhat sensitive to the data pattern and very sensitive to 
> timing, indicating a likely memory/data path issue within my particular 
> router. I'm guessing it's the IPQ8065 and not the SDRAM because I can get it 
> to fail with a tiny data set easily fits within DCACHE. I can alter the 
> frequency of the failure with a single ARM memory barrier instruction, which 
> at first implied a superscalar data ordering condition but the memory barrier 
> also alters the timing through the DCACHE so that is likely the effect it's 
> having. I was able to exclude the VFP/Neon register corruption as the cause 
> with some test code. I also excluded any context switch-speciifc issue by 
> measuring the # of context switches in /proc//status and catching a 
> failure where no switches had occurred. I also modified the affinity so the 
> utility runs on just one processor to rule out a specific core having the 
> issue.
> 
> I put the source and binary of my utility on github - if anyone on this 
> mailing list has this model router can you give it a try if possible? You 
> only need the ipq8065-sqrbug (binary) and run-ipq8065-sqrbug.sh (script). 
> Here's the link to the repository: 
> https://github.com/horshack-dpreview/ipq8065-sqrbug 
> <https://github.com/horshack-dpreview/ipq8065-sqrbug>
> 
> 
> From: Horshack ‪‬ mailto:horsh...@live.com>>
> Sent: Saturday, March 21, 2020 7:54 AM
> To: dropbear@ucc.asn.au <mailto:dropbear@ucc.asn.au>  <mailto:dropbear@ucc.asn.au>>
> Subject: SSH key exchange fails 30-70% of the time on Netgear X4S R7800
>  
> Including mailing list for my last two messages below...
> 
> Begin forwarded message:
> 
>> From: Horshack ‪‬ 
>> Date: March 21, 2020 at 7:35:18 AM PDT
>> To: Matt Johnston 
>> Cc: "dropbear@ucc.asn.au" 
>> Subject: Re:  SSH key exchange fails 30-70% of the time on Netgear X4S R7800
>> 
>> 
>> Disassembly of fast_s_mp_sqr() and other libtommath functions reveals gcc is 
>> utilizing the arm NEON SIMD instructions and registers for calculations 
>> involved with libtommath's mp_word scalar. Based on the 64-bit word 
>> corruption I see I'm guessing the SIMD registers aren't being 
>> preserved/restored properly somewhere, probably during a context switch, 
>> specifically s16–s31 (d8–d15, q4–q7), which AAPCS says must be preserved and 
>> which I see being used in the disassembly of fast_s_mp_sqr(). I'lll write 
>> some test code later today to see if this is the case, and if so, try to 
>> track down where and why the registers aren't being preserved.
>> 
>> From: Horshack ‪‬ 
>> Sent: Saturday, March 21, 2020 1:11 AM
>> To: Matt Johnston 
>> Cc: dropbear@ucc.asn.au 
>> Subject: Re: SSH key exchange fails 30-70% of the time on Netgear X4S R7800
>>  
>> I have one of the failure paths isolated down to a single corrupt 64-bit 
>> word in memory, which required a significant amount of code instrumentation 
>> to achieve. I implemented a code execution history buffer that gets filled 
>> at various checkpoints within s_mp_exptmod() and some of the modules called 
>> by it. To facilitate this history mechanism I packaged all of 
>> s_mp_exptmod()'s local variables inside a structure , which consists of 
>> saving the local scalar vars in addition to crc32's of all the mp_int data 
>> structures with a separate crc32 of the mp_int.dp payload (data). When a 
>> failure occurs, ie one or more of the three back-to-back debug invocations 
>> of s_mp_exptmod yields a mismatching signed key result, I  dump out the 
>> history elements for each of the invocations to determine the first code 
>> checkpoint where failing invocation departed from the known correct 
>> invocation.

*snipped*




Re: android access

2020-03-08 Thread Matt Johnston
Hi Ruben,

Not sure about that particular android program but Filezilla usually works as 
an alright sftp program.

Cheers,
Matt


> On Sun 8/3/2020, at 2:42 am, Ruben Safir  wrote:
> 
> Hello
> 
> Hello - I am sure this has been asked but I couldn't find an answer with
> a web search..
> 
> can one access org.galexander/Files on android through an applications.
> I wanted to sshfs a bunch of files to my tablet for a trip and it is so
> damn hard it it angering.
> 
> Ruben
> -- 
> So many immigrant groups have swept through our town
> that Brooklyn, like Atlantis, reaches mythological
> proportions in the mind of the world - RI Safir 1998
> http://www.mrbrklyn.com
> DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
> 
> http://www.nylxs.com - Leadership Development in Free Software
> http://www.brooklyn-living.com
> 
> Being so tracked is for FARM ANIMALS and extermination camps,
> but incompatible with living as a free human being. -RI Safir 2013



Re: Cannot Connect to Dropbear Server of Openwrt in QEMU

2020-10-20 Thread Matt Johnston
Hi,

Given in tcpdump there was no response at all (not even a rejection), my guess 
is there is a firewall on the OpenWrt host that drops all port 22 packets.
Are firewall rules listed if you go "iptables -vnL" , or in a config file?

Cheers,
Matt

> On Tue 20/10/2020, at 1:50 pm, 许大仙  wrote:
> 
> Hi!
> Sorry to disturb you.
> I meet some problems when I try to connect  to Dropbear Server of Openwrt.
> So I really need your help.
> 
> Here's the thing:
> 1. I run QEMU with Openwrt(guest) for emulating an ARM system on ubuntu 
> 18.04(host).
> Run the following commands on ubuntu 18.04:
> qemu-system-aarch64 -net nic,vlan=0 -net nic,vlan=1 -net user,vlan=1 \
> -m 1024 -smp 2 -cpu cortex-a57 -M virt -nographic \
> -kernel openwrt-19.07.3-armvirt-64-Image-initramfs \
> -drive if=none,file=disk.img,format=raw,id=hd0 \
> -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
>  -net nic,model=e1000
> Details: https://openwrt.org/docs/guide-user/virtualization/qemu 
> .
> 
> 2. But I can not access dropbear of Openwrt through ssh in my host 
> machine——ubuntu 18.04.
> SSH timeout:
> 
> Dropbear Service of Openwrt in QEMU:
> 
> 
> 3. I tried to use tcpdump to capture packages in Openwrt and found that 
> dropbear did not respond to any data packet received on port 22.
> Captured packages:
> 
> 
> This is so strange. Could you give me some possible reasons?
> Under what circumstances will Dropbear not reply to the packet?
> 
> 
> Additional Information:
> 1. Config of dropbear
> 
> 2.  User Networking of QEMU
> https://wiki.qemu.org/Documentation/Networking 
> 
> 
> 



Re: Dropbear Compilation on IRIX 6.5 broken again (2020.80)

2020-10-07 Thread Matt Johnston
Hi Kazuo,

It's a gnu extension, equivalent to

chansess->original_command = chansess->cmd ? chansess->cmd : m_strdup("");

I've pushed a fix now, I prefer a plain "if" statement.

Cheers,
Matt

> On Thu 8/10/2020, at 8:59 am, Kazuo Kuroi  wrote:
> 
> Hi folks,
> 
> MIPSPro 7.4.4m on IRIX doesn't like svr-chansession.c again:
> 
> cc-1029 c99: ERROR File = svr-chansession.c, Line = 696
>   An expression is expected at this point.
> 
> chansess->original_command = chansess->cmd ? : m_strdup("");
>  ^
> 
> cc-1053 c99: ERROR File = svr-chansession.c, Line = 696
>   A colon is expected at this point.
> 
> chansess->original_command = chansess->cmd ? : m_strdup("");
> ^
> 
> 2 errors detected in the compilation of "svr-chansession.c".
> make: *** [svr-chansession.o] Error 2
> make: *** Waiting for unfinished jobs
> 
> I'm not sure how to exactly fix that, if anyone has any suggestions I can try 
> that would be helpful, otherwise I can give access to a box if needed!
> 
> Thanks as always for keeping these changes upstream.
> 
> There's also a minor issue of the build system setting inappropriate flags 
> for MIPSPro, such as -Wextra and -Wsystem-headers and such. I can work with 
> someone to add a definition for MIPSPro to set the CFLAGS properly, I have a 
> complete list around here somewhere. For now I just deleted those CFLAGS.
> 
> Best Regards,
> 
> Kazuo Kuroi
> 
> 



Re: OpenWRT Dropbear v2020.80: Exit before auth: No matching algo kex

2020-10-23 Thread Matt Johnston
Hi Piotr,

Dropbear 2020.79 had some changes to the code that parses algorithms, it now is 
more strict about its MAX_PROPOSED_ALGO = 20 limit.
Not intentionally, but as a side-effect.

sshj advertises 30 different ciphers.

I've increased the limit to 50 in 
https://hg.ucc.asn.au/dropbear/rev/7c0fcd19e492 and it also prints a message if 
it is reached.

Someone else hit this same problem - I'll try and get a new release out soon.

Cheers,
Matt

> On Fri 23/10/2020, at 2:33 am, Piotr Jurkiewicz 
>  wrote:
> 
> Hi,
> 
> when trying to connect to OpenWRT router (mipsel_24kc architecture) with 
> PyCharm (uses sshj v0.29.0 client library) I started to get the following 
> error:
> 
>Exit before auth from : No matching algo kex
> 
> I remember that couple of month ago it worked fine. I have downgraded 
> Dropbear package on the router to version from the previous OpenWRT release 
> (v2020.78) and indeed I am able to connect to it.
> 
> I have tried removing the ed25519 hostkey in v2020.80, but it does not help.
> 
> Below I am pasting hex dumps of negotiation on both versions:
> 
> Dropbear v2020.80 (No matching algo kex):
> 
>   53 53 48 2d 32 2e 30 2d  53 53 48 4a 5f 30 2e 32 SSH-2.0- SSHJ_0.2
> 0010  39 2e 30 0d 0a   9.0..
>  53 53 48 2d 32 2e 30 2d  64 72 6f 70 62 65 61 72 SSH-2.0- 
> dropbear
>0010  0d 0a 00 00 01 84 07 14  be 21 14 d9 76 eb d7 98  
> .!..v...
>0020  a7 14 cd b1 ee ce 91 14  00 00 00 82 63 75 72 76  
> curv
>0030  65 32 35 35 31 39 2d 73  68 61 32 35 36 2c 63 75 e25519-s 
> ha256,cu
>0040  72 76 65 32 35 35 31 39  2d 73 68 61 32 35 36 40 rve25519 
> -sha256@
>0050  6c 69 62 73 73 68 2e 6f  72 67 2c 64 69 66 66 69 libssh.o 
> rg,diffi
>0060  65 2d 68 65 6c 6c 6d 61  6e 2d 67 72 6f 75 70 31 e-hellma 
> n-group1
>0070  34 2d 73 68 61 32 35 36  2c 64 69 66 66 69 65 2d 4-sha256 
> ,diffie-
>0080  68 65 6c 6c 6d 61 6e 2d  67 72 6f 75 70 31 34 2d hellman- 
> group14-
>0090  73 68 61 31 2c 6b 65 78  67 75 65 73 73 32 40 6d sha1,kex 
> guess2@m
>00A0  61 74 74 2e 75 63 63 2e  61 73 6e 2e 61 75 00 00 att.ucc. 
> asn.au..
>00B0  00 20 73 73 68 2d 65 64  32 35 35 31 39 2c 72 73 . ssh-ed 
> 25519,rs
>00C0  61 2d 73 68 61 32 2d 32  35 36 2c 73 73 68 2d 72 a-sha2-2 
> 56,ssh-r
>00D0  73 61 00 00 00 33 63 68  61 63 68 61 32 30 2d 70 sa...3ch 
> acha20-p
>00E0  6f 6c 79 31 33 30 35 40  6f 70 65 6e 73 73 68 2e oly1305@ 
> openssh.
>00F0  63 6f 6d 2c 61 65 73 31  32 38 2d 63 74 72 2c 61 com,aes1 
> 28-ctr,a
>0100  65 73 32 35 36 2d 63 74  72 00 00 00 33 63 68 61 es256-ct 
> r...3cha
>0110  63 68 61 32 30 2d 70 6f  6c 79 31 33 30 35 40 6f cha20-po 
> ly1305@o
>0120  70 65 6e 73 73 68 2e 63  6f 6d 2c 61 65 73 31 32 penssh.c 
> om,aes12
>0130  38 2d 63 74 72 2c 61 65  73 32 35 36 2d 63 74 72 8-ctr,ae 
> s256-ctr
>0140  00 00 00 17 68 6d 61 63  2d 73 68 61 31 2c 68 6d hmac 
> -sha1,hm
>0150  61 63 2d 73 68 61 32 2d  32 35 36 00 00 00 17 68 ac-sha2- 
> 256h
>0160  6d 61 63 2d 73 68 61 31  2c 68 6d 61 63 2d 73 68 mac-sha1 
> ,hmac-sh
>0170  61 32 2d 32 35 36 00 00  00 04 6e 6f 6e 65 00 00 a2-256.. 
> ..none..
>0180  00 04 6e 6f 6e 65 00 00  00 00 00 00 00 00 00 00 ..none.. 
> 
>0190  00 00 00 fd 9d 4e 7a a7  2d 49   .Nz. -I
> 0015  00 00 08 d4 07 14 71 12  38 a7 62 81 7d 79 63 ca ..q. 8.b.}yc.
> 0025  3c fb a3 f1 1e 8c 00 00  02 9c 63 75 72 76 65 32 <... ..curve2
> 0035  35 35 31 39 2d 73 68 61  32 35 36 2c 63 75 72 76 5519-sha 256,curv
> 0045  65 32 35 35 31 39 2d 73  68 61 32 35 36 40 6c 69 e25519-s ha256@li
> 0055  62 73 73 68 2e 6f 72 67  2c 64 69 66 66 69 65 2d bssh.org ,diffie-
> 0065  68 65 6c 6c 6d 61 6e 2d  67 72 6f 75 70 2d 65 78 hellman- group-ex
> 0075  63 68 61 6e 67 65 2d 73  68 61 32 35 36 2c 65 63 change-s ha256,ec
> 0085  64 68 2d 73 68 61 32 2d  6e 69 73 74 70 35 32 31 dh-sha2- nistp521
> 0095  2c 65 63 64 68 2d 73 68  61 32 2d 6e 69 73 74 70 ,ecdh-sh a2-nistp
> 00A5  33 38 34 2c 65 63 64 68  2d 73 68 61 32 2d 6e 69 384,ecdh -sha2-ni
> 00B5  73 74 70 32 35 36 2c 64  69 66 66 69 65 2d 68 65 stp256,d iffie-he
> 00C5  6c 6c 6d 61 6e 2d 67 72  6f 75 70 2d 65 78 63 68 llman-gr oup-exch
> 00D5  61 6e 67 65 2d 73 68 61  31 2c 64 69 66 66 69 65 ange-sha 1,diffie
> 00E5  2d 68 65 6c 6c 6d 61 6e  2d 67 72 6f 75 70 31 2d -hellman -group1-
> 00F5  73 68 61 31 2c 64 69 66  66 69 65 2d 68 65 6c 6c sha1,dif fie-hell
> 0105  6d 61 6e 2d 67 72 6f 75  70 31 34 2d 73 68 61 31 man-grou p14-sha1
> 0115  2c 64 69 66 66 69 65 2d  68 65 6c 6c 6d 61 6e 2d ,diffie- hellman-
> 0125  67 72 6f 75 70 31 34 2d  73 68 61 32 35 36 2c 64 group14- sha256,d
> 0135  69 66 66 69 65 2d 68 65  6c 6c 6d 61 6e 2d 67 72 iffie-he llman-gr
> 

Re: OpenWRT Dropbear v2020.80: Exit before auth: No matching algo kex

2020-10-23 Thread Matt Johnston
Forcing diffie-hellman-group1-sha1 shouldn't usually be necessary. 
The only case would be for servers prior to 2018.76 that compiled with all 
other default options disabled.

Cheers,
Matt

> On Fri 23/10/2020, at 9:00 pm, Tang Jiye  wrote:
> 
> Hi Walter,
> 
> What if I want to use ecdh and ecdsa for kex and signing while 
> diffie-hellman-group1-sha1 is disabled.
> 
> It should work as well right ?
> 
> Jiye
> 
> Walter Harms mailto:wha...@bfs.de>> 于2020年10月23日周五 上午5:24写道:
> This is caused by changes in ssh_config. You can try:
>   ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 USER@TARGET 
> 
> or persistent in ssh_config 
> KexAlgorithms=+diffie-hellman-group1-sha1 
> 
> your mileage may vary etc.
> 
> re,
>  wh
> 
> Von: Dropbear [dropbear-boun...@ucc.asn.au 
> ] im Auftrag von Piotr Jurkiewicz 
> [piotr.jerzy.jurkiew...@gmail.com ]
> Gesendet: Donnerstag, 22. Oktober 2020 20:33
> An: dropbear@ucc.asn.au 
> Betreff: OpenWRT Dropbear v2020.80: Exit before auth: No matching algo kex
> 
> Hi,
> 
> when trying to connect to OpenWRT router (mipsel_24kc architecture) with
> PyCharm (uses sshj v0.29.0 client library) I started to get the
> following error:
> 
>  Exit before auth from : No matching algo kex
> 
> I remember that couple of month ago it worked fine. I have downgraded
> Dropbear package on the router to version from the previous OpenWRT
> release (v2020.78) and indeed I am able to connect to it.
> 
> I have tried removing the ed25519 hostkey in v2020.80, but it does not help.
> 
> Below I am pasting hex dumps of negotiation on both versions:
> 
> Dropbear v2020.80 (No matching algo kex):
> 
>   53 53 48 2d 32 2e 30 2d  53 53 48 4a 5f 30 2e 32 SSH-2.0- SSHJ_0.2
> 0010  39 2e 30 0d 0a   9.0..
>    53 53 48 2d 32 2e 30 2d  64 72 6f 70 62 65 61 72 SSH-2.0-
> dropbear
>  0010  0d 0a 00 00 01 84 07 14  be 21 14 d9 76 eb d7 98 
> .!..v...
>  0020  a7 14 cd b1 ee ce 91 14  00 00 00 82 63 75 72 76 
> curv
>  0030  65 32 35 35 31 39 2d 73  68 61 32 35 36 2c 63 75 e25519-s
> ha256,cu
>  0040  72 76 65 32 35 35 31 39  2d 73 68 61 32 35 36 40 rve25519
> -sha256@
>  0050  6c 69 62 73 73 68 2e 6f  72 67 2c 64 69 66 66 69 libssh.o
> rg,diffi
>  0060  65 2d 68 65 6c 6c 6d 61  6e 2d 67 72 6f 75 70 31 e-hellma
> n-group1
>  0070  34 2d 73 68 61 32 35 36  2c 64 69 66 66 69 65 2d 4-sha256
> ,diffie-
>  0080  68 65 6c 6c 6d 61 6e 2d  67 72 6f 75 70 31 34 2d hellman-
> group14-
>  0090  73 68 61 31 2c 6b 65 78  67 75 65 73 73 32 40 6d sha1,kex
> guess2@m
>  00A0  61 74 74 2e 75 63 63 2e  61 73 6e 2e 61 75 00 00 att.ucc.
> asn.au..
>  00B0  00 20 73 73 68 2d 65 64  32 35 35 31 39 2c 72 73 . ssh-ed
> 25519,rs
>  00C0  61 2d 73 68 61 32 2d 32  35 36 2c 73 73 68 2d 72 a-sha2-2
> 56,ssh-r
>  00D0  73 61 00 00 00 33 63 68  61 63 68 61 32 30 2d 70 sa...3ch
> acha20-p
>  00E0  6f 6c 79 31 33 30 35 40  6f 70 65 6e 73 73 68 2e oly1305@
> openssh.
>  00F0  63 6f 6d 2c 61 65 73 31  32 38 2d 63 74 72 2c 61 com,aes1
> 28-ctr,a
>  0100  65 73 32 35 36 2d 63 74  72 00 00 00 33 63 68 61 es256-ct
> r...3cha
>  0110  63 68 61 32 30 2d 70 6f  6c 79 31 33 30 35 40 6f cha20-po
> ly1305@o
>  0120  70 65 6e 73 73 68 2e 63  6f 6d 2c 61 65 73 31 32 penssh.c
> om,aes12
>  0130  38 2d 63 74 72 2c 61 65  73 32 35 36 2d 63 74 72 8-ctr,ae
> s256-ctr
>  0140  00 00 00 17 68 6d 61 63  2d 73 68 61 31 2c 68 6d hmac
> -sha1,hm
>  0150  61 63 2d 73 68 61 32 2d  32 35 36 00 00 00 17 68 ac-sha2-
> 256h
>  0160  6d 61 63 2d 73 68 61 31  2c 68 6d 61 63 2d 73 68 mac-sha1
> ,hmac-sh
>  0170  61 32 2d 32 35 36 00 00  00 04 6e 6f 6e 65 00 00 a2-256..
> ..none..
>  0180  00 04 6e 6f 6e 65 00 00  00 00 00 00 00 00 00 00 ..none..
> 
>  0190  00 00 00 fd 9d 4e 7a a7  2d 49   .Nz. -I
> 0015  00 00 08 d4 07 14 71 12  38 a7 62 81 7d 79 63 ca ..q. 8.b.}yc.
> 0025  3c fb a3 f1 1e 8c 00 00  02 9c 63 75 72 76 65 32 <... ..curve2
> 0035  35 35 31 39 2d 73 68 61  32 35 36 2c 63 75 72 76 5519-sha 256,curv
> 0045  65 32 35 35 31 39 2d 73  68 61 32 35 36 40 6c 69 e25519-s ha256@li
> 0055  62 73 73 68 2e 6f 72 67  2c 64 69 66 66 69 65 2d bssh.org 
>  ,diffie-
> 0065  68 65 6c 6c 6d 61 6e 2d  67 72 6f 75 70 2d 65 78 hellman- group-ex
> 0075  63 68 61 6e 67 65 2d 73  68 61 32 35 36 2c 65 63 change-s ha256,ec
> 0085  64 68 2d 73 68 61 32 2d  6e 69 73 74 70 35 32 31 dh-sha2- nistp521
> 0095  2c 65 63 64 68 2d 73 68  61 32 2d 6e 69 73 74 70 ,ecdh-sh a2-nistp
> 00A5  33 38 34 2c 65 63 64 68  2d 73 68 61 32 2d 6e 69 384,ecdh -sha2-ni
> 00B5  73 74 70 32 35 36 2c 

Re: "Bad public key options" (Was: Dropbear 2020.79)

2020-06-17 Thread Matt Johnston


> On Tue 16/6/2020, at 9:58 am, Guilhem Moulin  wrote:
>> - […] x11 forwarding are now disabled by default.
> 
> I have no opinion about disabling this at compile-time, however the
> current implementation locks out (“Bad public key options”) users with
> ‘no-X11-forwarding’ in their authorized_keys(5) files.

Thanks, I'll apply that and organise a bug fix release (waiting to see if there 
are an other immediate regressions).

For Debian I think it might be worth keeping x11 forwarding enabled.
I disabled x11 forwarding because most embedded platforms (Dropbear's most 
common usecase (?)) wouldn't have any use for it. On a general distro it can be 
useful.

Cheers,
Matt

Re: Dropbear 2020.79

2020-06-17 Thread Matt Johnston
There are various examples at https://github.com/fabriziobertocci/dropbear-epka

Cheers,
Matt


> On Wed 17/6/2020, at 6:38 pm, Hans Harder  wrote:
> 
> Does anybody have an example of the external public-key authentication api
> Sounds interesting, but I am not sure how to use this...
> 
> thx
> Hans
> 
> On Mon, Jun 15, 2020 at 5:53 PM Matt Johnston  <mailto:m...@ucc.asn.au>> wrote:
> Hi all,
> 
> Dropbear 2020.79 is now released. Particular thanks to Vladislav Grishenko
> for adding ed25519 and chacha20-poly1305 support which have
> been wanted for a while.
> 
> This release also supports rsa-sha2 signatures which will be
> required by OpenSSH in the near future - rsa with sha1 will
> be disabled. This doesn't require any change to
> hostkey/authorized_keys files.
> 
> Required versions of libtomcrypt and libtommath have been
> increased, if the system library is older Dropbear can use
> its own bundled copy.
> 
> As usual downloads are at
> https://matt.ucc.asn.au/dropbear/dropbear.html 
> <https://matt.ucc.asn.au/dropbear/dropbear.html>
> https://mirror.dropbear.nl/mirror/dropbear.html 
> <https://mirror.dropbear.nl/mirror/dropbear.html>
> 
> Cheers,
> Matt
> 
> 2020.79 - 15 June 2020
> 
> - Support ed25519 hostkeys and authorized_keys, many thanks to Vladislav 
> Grishenko.
>   This also replaces curve25519 with a TweetNaCl implementation that reduces 
> code size.
> 
> - Add chacha20-poly1305 authenticated cipher. This will perform faster than 
> AES
>   on many platforms. Thanks to Vladislav Grishenko
> 
> - Support using rsa-sha2 signatures. No changes are needed to 
> hostkeys/authorized_keys
>   entries, existing RSA keys can be used with the new signature format 
> (signatures
>   are ephemeral within a session). Old ssh-rsa signatures will no longer
>   be supported by OpenSSH in future so upgrading is recommended.
> 
> - Use getrandom() call on Linux to ensure sufficient entropy has been 
> gathered at startup.
>   Dropbear now avoids reading from the random source at startup, instead 
> waiting until
>   the first connection. It is possible that some platforms were running 
> without enough 
>   entropy previously, those could potentially block at first boot generating 
> host keys.
>   The dropbear "-R" option is one way to avoid that.
> 
> - Upgrade libtomcrypt to 1.18.2 and libtommath to 1.2.0, many thanks to 
> Steffen Jaeckel for
>   updating Dropbear to use the current API. Dropbear's configure script will 
> check 
>   for sufficient system library versions, otherwise using the bundled 
> versions.
> 
> - CBC ciphers, 3DES, hmac-sha1-96, and x11 forwarding are now disabled by 
> default.
>   They can be set in localoptions.h if required.
>   Blowfish has been removed.
> 
> - Support AES GCM, patch from Vladislav Grishenko. This is disabled by 
> default,
>   Dropbear doesn't currently use hardware accelerated AES.
> 
> - Added an API for specifying user public keys as an authorized_keys 
> replacement.
>   See pubkeyapi.h for details, thanks to Fabrizio Bertocci
> 
> - Fix idle detection clashing with keepalives, thanks to jcmathews
> 
> - Include IP addresses in more early exit messages making it easier for 
> fail2ban
>   processing. Patch from Kevin Darbyshire-Bryant
> 
> - scp fix for CVE-2018-20685 where a server could modify name of output files
> 
> - SSH_ORIGINAL_COMMAND is set for "dropbear -c" forced command too
> 
> - Fix writing key files on systems without hard links, from Matt Robinson
> 
> - Compatibility fixes for IRIX from Kazuo Kuroi
> 
> - Re-enable printing MOTD by default, was lost moving from options.h. Thanks 
> to zciendor
> 
> - Call fsync() is called on parent directory when writing key files to ensure 
> they are flushed
> 
> - Fix "make install" for manpages in out-of-tree builds, from Gabor Z. Papp
> 
> - Some notes are added in DEVELOPER.md
> 



Dropbear 2020.79

2020-06-15 Thread Matt Johnston
Hi all,

Dropbear 2020.79 is now released. Particular thanks to Vladislav Grishenko
for adding ed25519 and chacha20-poly1305 support which have
been wanted for a while.

This release also supports rsa-sha2 signatures which will be
required by OpenSSH in the near future - rsa with sha1 will
be disabled. This doesn't require any change to
hostkey/authorized_keys files.

Required versions of libtomcrypt and libtommath have been
increased, if the system library is older Dropbear can use
its own bundled copy.

As usual downloads are at
https://matt.ucc.asn.au/dropbear/dropbear.html
https://mirror.dropbear.nl/mirror/dropbear.html

Cheers,
Matt

2020.79 - 15 June 2020

- Support ed25519 hostkeys and authorized_keys, many thanks to Vladislav 
Grishenko.
  This also replaces curve25519 with a TweetNaCl implementation that reduces 
code size.

- Add chacha20-poly1305 authenticated cipher. This will perform faster than AES
  on many platforms. Thanks to Vladislav Grishenko

- Support using rsa-sha2 signatures. No changes are needed to 
hostkeys/authorized_keys
  entries, existing RSA keys can be used with the new signature format 
(signatures
  are ephemeral within a session). Old ssh-rsa signatures will no longer
  be supported by OpenSSH in future so upgrading is recommended.

- Use getrandom() call on Linux to ensure sufficient entropy has been gathered 
at startup.
  Dropbear now avoids reading from the random source at startup, instead 
waiting until
  the first connection. It is possible that some platforms were running without 
enough 
  entropy previously, those could potentially block at first boot generating 
host keys.
  The dropbear "-R" option is one way to avoid that.

- Upgrade libtomcrypt to 1.18.2 and libtommath to 1.2.0, many thanks to Steffen 
Jaeckel for
  updating Dropbear to use the current API. Dropbear's configure script will 
check 
  for sufficient system library versions, otherwise using the bundled versions.

- CBC ciphers, 3DES, hmac-sha1-96, and x11 forwarding are now disabled by 
default.
  They can be set in localoptions.h if required.
  Blowfish has been removed.

- Support AES GCM, patch from Vladislav Grishenko. This is disabled by default,
  Dropbear doesn't currently use hardware accelerated AES.

- Added an API for specifying user public keys as an authorized_keys 
replacement.
  See pubkeyapi.h for details, thanks to Fabrizio Bertocci

- Fix idle detection clashing with keepalives, thanks to jcmathews

- Include IP addresses in more early exit messages making it easier for fail2ban
  processing. Patch from Kevin Darbyshire-Bryant

- scp fix for CVE-2018-20685 where a server could modify name of output files

- SSH_ORIGINAL_COMMAND is set for "dropbear -c" forced command too

- Fix writing key files on systems without hard links, from Matt Robinson

- Compatibility fixes for IRIX from Kazuo Kuroi

- Re-enable printing MOTD by default, was lost moving from options.h. Thanks to 
zciendor

- Call fsync() is called on parent directory when writing key files to ensure 
they are flushed

- Fix "make install" for manpages in out-of-tree builds, from Gabor Z. Papp

- Some notes are added in DEVELOPER.md



Re: Address binding question

2020-12-22 Thread Matt Johnston
Hi Emil,

That syntax should work. In my shell here (zsh) I have to put "[127.0.0.1]:22" 
in quotes, could that be the problem?

What commandline do you see if you look at "ps aux"?

Cheers,
Matt

> On Tue 22/12/2020, at 9:13 am, Emil Christopher Solli Melar 
>  wrote:
> 
> Hello! I use Dropbear server v2019.78.
> My goal is to only make it bind to localhost so I don't have to block it with 
> a firewall / iptables.
> It's run like this: /dropbear -i -r /var/lib/dropbear/dropbear_rsa_host_key 
> -p [127.0.0.1]:22 -p [::1]:22 -s
> 
> I have tried to search via google but the documentation states that this is 
> how you bind to specific addresses. I also tried -p 127.0.0.1:22 
>  without the brackets.
> 
> I can confirm that the process is running using ps, but netstat shows:
> tcp0  0 :::22   :::*LISTEN
> 
> What am I missing here? It seems to bind to all no matter what.
> Thanks!
> -- 
> Emil Christopher Solli Melar



Re: MIN_RSA_KEYLEN compare goes wrong

2020-10-29 Thread Matt Johnston
Hi Hans,

Sorry I missed replying to this message a while ago.

What program created the key? As far as I can tell the test
is correct, the top bit might be unset?

Cheers,
Matt

On Thu, Aug 27, 2020 at 07:36:26AM +0200, Hans Harder wrote:
> HI,
> 
> I noticed that I got warnings that the RSA key was too short.
> Further investigation showed that I was using a 1024 bits RSA key but
> the mp_count_bits function return 1023 count (probably 0 based)
> 
> in rsa.c  it states:if (mp_count_bits(key->n) < MIN_RSA_KEYLEN)
> 
> Is this intentional  or should I just define the MIN_RSA_KEYLEN as
> 1023 instead of the 1024 now in sysoptions.h
> 
> Hans


Re: Does Dropbear know what a ~/.ssh/config file is?

2021-01-06 Thread Matt Johnston
Hi Sean,

I don't currently have plans to implement a config file, but I'd be happy to 
take a patch if someone wants to make it work.
I think it would need to be a separate config file to OpenSSH's, some 
unsupported options might be important.

Personally I've tended to make ~/bin scripts to ssh (dbclient) to hosts I use.

Sorry for the noise with the other reply, that was meant to be off-list.

Cheers,
Matt



> On Mon 4/1/2021, at 4:54 pm, Sean Warner  wrote:
> 
> Hi Matt,
> 
> And as for my problem.. do you have any plans to add a user config file that 
> can take hostname, port and identity details like openssh?
> 
> Cheers,
> 
> Flex
> 
> On Mon, 4 Jan 2021, 05:41 Matt Johnston,  <mailto:m...@ucc.asn.au>> wrote:
> Sounds like your problem is with android not Dropbear :)
> 
> On 4 January 2021 4:57:30 am AWST, Ruben Safir  <mailto:ru...@mrbrklyn.com>> wrote:
> dropbear is a waste of time and it doesn't even work.
> 
> I don't know why it is Fing Hard for the table with android can't have
> an openssh daman running so we can tranfer files on and off the image.
> 
> Everything about android is designed to just lock out the user.
> 
> 
> 
> On 1/3/21 8:57 AM, Sean Warner wrote:
> Hello,
> 
>  
> 
> I am ssh'ing from Server-A to Server-B. Dropbear client/server is on
> Server-A and openssh client/server is on Server-B. ~/.ssh/ncp_key_dropbear
> in Server-A is of the correct Dropbear format.
> 
>  
> 
> I can ssh from A to B like this:
> 
> # cd ~/.ssh
> 
> # ssh -i ncp_key_dropbear root@192.168.1.124 <mailto:root@192.168.1.124> -p 22
> 
>  
> 
> In Dropbear is it possible in to create a ~/.ssh/config file on Server-A
> like this:
> 
> Host ncp
> User root
> Port 22
> IdentityFile ~/.ssh/ncp_key_dropbear
> HostName 192.168.1.124
> 
>  
> 
> . and then ssh like this?
> 
> # ssh ncp
> 
>  
> 
> When I do that on a host running OpenWrt I get the error:
> 
>  
> 
> root@OpenWrt:~/.ssh# ssh ncp
> 
>  
> 
> ssh: Connection to root@ncp:22 exited: Connect failed: Error resolving 'ncp'
> port '22'. Name does not resolve
> 
>  
> 
> Actually I get the same error even if I change the Port, in the config file,
> to 1022 even though the sshd on the remote host is also listening on port
> 1022.
> 
>  
> 
> I CAN set up a config file on Server-B, that has an openssh client, and I
> can ssh from B to A like this and it works:
> 
> # ssh openwrt
> 
>  
> 
> Thank you,
> 
>  
> 
> Flex
> 
> 
> 



Re: [PATCH] Introduce extra delay before closing unauthenticated sessions

2021-01-24 Thread Matt Johnston
On Wed 20/1/2021, at 8:15 pm, Thomas De Schampheleire 
 wrote:
> 
>> # HG changeset patch
>> Introduce extra delay before closing unauthenticated sessions
> 
> Any comments on this patch?
> 

Hi Thomas,

Sorry for the delay getting back to you. I've applied the patch, it seems like 
it could be good as a simple brute force countermeasure. I'm sure a lot of the 
SSH bots are using varying source IPs from botnets etc, but there doesn't seem 
much harm in an extra delay.

I'll add an option to disable it at runtime just in case it ends up causing 
problems (resource usage of waiting connections would be my concern).

Thanks,
Matt

Re: Does Dropbear know what a ~/.ssh/config file is?

2021-01-03 Thread Matt Johnston
Sounds like your problem is with android not Dropbear :)

On 4 January 2021 4:57:30 am AWST, Ruben Safir  wrote:
>dropbear is a waste of time and it doesn't even work.
>
>I don't know why it is Fing Hard for the table with android can't have
>an openssh daman running so we can tranfer files on and off the image.
>
>Everything about android is designed to just lock out the user.
>
>
>
>On 1/3/21 8:57 AM, Sean Warner wrote:
>> Hello,
>> 
>>  
>> 
>> I am ssh'ing from Server-A to Server-B. Dropbear client/server is on
>> Server-A and openssh client/server is on Server-B.
>~/.ssh/ncp_key_dropbear
>> in Server-A is of the correct Dropbear format.
>> 
>>  
>> 
>> I can ssh from A to B like this:
>> 
>> # cd ~/.ssh
>> 
>> # ssh -i ncp_key_dropbear root@192.168.1.124 -p 22
>> 
>>  
>> 
>> In Dropbear is it possible in to create a ~/.ssh/config file on
>Server-A
>> like this:
>> 
>> Host ncp
>> User root
>> Port 22
>> IdentityFile ~/.ssh/ncp_key_dropbear
>> HostName 192.168.1.124
>> 
>>  
>> 
>> . and then ssh like this?
>> 
>> # ssh ncp
>> 
>>  
>> 
>> When I do that on a host running OpenWrt I get the error:
>> 
>>  
>> 
>> root@OpenWrt:~/.ssh# ssh ncp
>> 
>>  
>> 
>> ssh: Connection to root@ncp:22 exited: Connect failed: Error
>resolving 'ncp'
>> port '22'. Name does not resolve
>> 
>>  
>> 
>> Actually I get the same error even if I change the Port, in the
>config file,
>> to 1022 even though the sshd on the remote host is also listening on
>port
>> 1022.
>> 
>>  
>> 
>> I CAN set up a config file on Server-B, that has an openssh client,
>and I
>> can ssh from B to A like this and it works:
>> 
>> # ssh openwrt
>> 
>>  
>> 
>> Thank you,
>> 
>>  
>> 
>> Flex
>> 
>> 
>
>
>-- 
>So many immigrant groups have swept through our town
>that Brooklyn, like Atlantis, reaches mythological
>proportions in the mind of the world - RI Safir 1998
>http://www.mrbrklyn.com
>DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
>
>http://www.nylxs.com - Leadership Development in Free Software
>http://www.brooklyn-living.com
>
>Being so tracked is for FARM ANIMALS and extermination camps,
>but incompatible with living as a free human being. -RI Safir 2013


Re: restrict access

2021-05-20 Thread Matt Johnston
On Thu, May 20, 2021 at 02:29:20PM +, Walter Harms wrote:
> Thx for the fast response,
> for the background: little system, far-far-away land, but some script-kiddie 
> is filling the log ...
> so no iptables or other fancy stuff. Seems i have to change that, somehow. 
> 
> @matt:
> in case i get something working ... 
> i am thinking about fnmatch and inet_ntoa would that be acceptable ?

I'm not really sure it's the job of Dropbear to be doing
that filtering. Though I wonder if it might make sense to
optionally not bother logging failed SSH auth attempts,
given how many there are...

Cheers,
Matt


Re: restrict access

2021-05-20 Thread Matt Johnston
Hi Walter,

Dropbear doesn't have IP restrictions built in. You could use
iptables/nftables, or tcpwrappers etc if you're running
Dropbear in inetd mode.

Cheers,
Matt

On Thu, May 20, 2021 at 01:23:28PM +, Walter Harms wrote:
> Hello List,
> actually i expected this would be a FAQ but i can not find an answer:
> How can i restrict the  hosts that are allowed to access the
> dropbear server ?
> 
> re,
>  wh


Re: Dropbear 2019.77

2021-06-29 Thread Matt Johnston
On Tue 29/6/2021, at 9:47 pm, roy...@gmail.com wrote:
> 
>> That itself wouldn't be a problem if we could just crypt all incoming 
>> password attempts before checking a username's existence - the problem is 
>> that the password crypt algorithm can vary per user, so the time will vary 
>> too. We have to guess which algorithm to use for unknown users. So rather 
>> than adding some complicated logic I just limited the password length.
> 
> OK I got it. But does the risk become higher if I change
> DROPBEAR_MAX_PASSWORD_LEN to higher value. for example, 200?

If a successful login for a 200 char password takes longer than ~250ms 
(svr-auth.c send_msg_userauth_failure()) then it's probably possible to figure 
if usernames exist on a system. That may or may not be a security problem 
depending on the situation. The length will depend on the speed and crypt 
algorithms of the system.

Cheers,
Matt

Re: Dropbear 2019.77

2021-06-29 Thread Matt Johnston
Hi Roy,

On Tue 29/6/2021, at 7:18 pm, roy...@gmail.com wrote:
> 
>> - Make failure delay more consistent to avoid revealing valid usernames, set 
>> server password
>>  limit of 100 characters. Problem reported by usd responsible disclosure team
> 
> What is the technical reason of limiting server password length to
> such a low value? It is even shorter than Windows PATH_MAX which I
> think this doesn't make any sense.
> 
>> - Change handling of failed authentication to avoid disclosing valid 
>> usernames,
>>  CVE-2018-15599.

The problem with longer passwords is that the time taken to calculate a 
password crypt is dependent on the length of the password. Passwords longer 
than a certain length will take longer to crypt than the failure delay time - 
100 characters was less than what I tried empirically.

That itself wouldn't be a problem if we could just crypt all incoming password 
attempts before checking a username's existence - the problem is that the 
password crypt algorithm can vary per user, so the time will vary too. We have 
to guess which algorithm to use for unknown users. So rather than adding some 
complicated logic I just limited the password length.

Cheers,
Matt

Re: Password authentication fails

2021-07-27 Thread Matt Johnston
Hi Dan,

MacOS uses PAM for password auth. As well as --enable-pam for
configure it needs

#define DROPBEAR_SVR_PASSWORD_AUTH 0
#define DROPBEAR_SVR_PAM_AUTH 1

in localoptions.h at build time. 

Not sure that Homebrew sets the localoptions.h
https://github.com/Homebrew/linuxbrew-core/blob/master/Formula/dropbear.rb

I've used Dropbear on 10.15 but haven't tried newer MacOS, laptop
is out of updates. I don't know of anything that would break
it though.

Cheers,
Matt


On Tue, Jul 27, 2021 at 03:47:49PM -0700, Dan Stromberg wrote:
> Hi people.
> 
> I'm attempting to set up dropbear ssh on a mac, for testing something.
> 
> For some reason, password authentication consistently fails for the account
> I'm trying: testacct.  If I set up RSA authentication for testacct, that
> works fine, but I need to use a password for the testing.
> 
> I have OpenSSH set up and running on the same system, so I have dropbear on
> an alternate port: tcp/.
> 
> If I log into testacct with a password, on tcp/22 (that is, using OpenSSH),
> things work fine.
> 
> My dropbear invocation and messages look like:
> $ /usr/local/sbin/dropbear -p 127.0.0.1: -E -R -F
> cmd output started 2021 Tue Jul 27 03:41:43 PM PDT
> [3228] Jul 27 15:41:43 Not backgrounding
> [3237] Jul 27 15:41:47 Child connection from 127.0.0.1:53525
> [3237] Jul 27 15:41:50 Bad password attempt for 'testacct' from
> 127.0.0.1:53525
> [3237] Jul 27 15:41:53 Bad password attempt for 'testacct' from
> 127.0.0.1:53525
> [3237] Jul 27 15:41:55 Exit before auth from <127.0.0.1:53525>: (user
> 'testacct', 2 fails): Exited normally
> 
> And from the clients I see:
> $ ssh -p  testacct@127.0.0.1
> testacct@127.0.0.1's password:
> Permission denied, please try again.
> testacct@127.0.0.1's password:
> Permission denied, please try again.
> testacct@127.0.0.1's password:
> 
> $ dbclient -p  testacct@127.0.0.1
> Host '127.0.0.1' is not in the trusted hosts file.
> (ssh-ed25519 fingerprint sha1!!
> 6f:b7:50:8c:82:87:ce:bf:cc:fd:e3:48:63:12:60:9d:39:17:e2:97)
> Do you want to continue connecting? (y/n) y
> testacct@127.0.0.1's password:
> testacct@127.0.0.1's password:
> testacct@127.0.0.1's password:
> 
> What do I need to do to get dropbear server to allow password-based
> authentication?
> 
> BTW, I am using Dropbear v2020.81 from homebrew on macOS 11.5.1.
> 
> Thanks!


Dropbear 2022.82

2022-04-01 Thread Matt Johnston
Hi all,

Dropbear 2022.82 is released at last, with various
improvements and some relatively minor fixes. Thanks to
everyone who provided code, bug reports, suggestions and
other help. 

Releases can be downloaded from
https://matt.ucc.asn.au/dropbear/dropbear.html

It looks like the Dropbear Mercurial repository
(hg.ucc.asn.au) isn't getting used much any more. Perhaps it
is finally time to move the canonical source to git/github.
If anyone is still using the Mercurial repo please let me
know. 

Cheers,
Matt

2022.82 - 1 April 2022

Features and Changes:
  Note >> for compatibility/configuration changes

- Implemented OpenSSH format private key handling for dropbearconvert.
  Keys can be read in OpenSSH format or the old PEM format.
  >> Keys are now written in OpenSSH format rather than PEM.
  ED25519 support is now correct. DSS keys are still PEM format.

- Use SHA256 for key fingerprints

- >> Reworked -v verbose printing, specifying multiple times will increase
  verbosity. - is equivalent to the old DEBUG_TRACE -v level, it
  can be configured at compile time in localoptions.h (see default_options.h)
  Lower -v options can be used to check connection progress or algorithm
  negotiation.
  Thanks to Hans Harder for the implementation

  localoptions.h DEBUG_TRACE should be set to 4 for the same result as the
  previous DEBUG_TRACE 1.

- Added server support for U2F/FIDO keys (ecdsa-sk and ed25519-sk) in
  authorized_keys. no-touch-required option isn't allowed yet.
  Thanks to Egor Duda for the implementation

- autoconf output (configure script etc) is now committed to version control.
  >> It isn't necessary to run "autoconf" any more on a checkout.

- sha1 will be omitted from the build if KEX/signing/MAC algorithms don't
  require it. Instead sha256 is used for random number generation.
  See sysoptions.h to see which algorithms require which hashes.

- Set SSH_PUBKEYINFO environment variable based on the authorized_keys
  entry used for auth. The first word of the comment after the key is used
  (must only have characters a-z A-Z 0-9 .,_-+@)
  Patch from Hans Harder, modified by Matt Johnston

- Let dbclient multihop mode be used with '-J'.
  Patch from Hans Harder

- Allow home-directory relative paths ~/path for various settings
  and command line options.
  *_PRIV_FILENAME DROPBEAR_PIDFILE SFTPSERVER_PATH MOTD_FILENAME
  Thanks to Begley Brothers Inc

  >> The default DROPBEAR_DEFAULT_CLI_AUTHKEY has now changed, it now needs
  a tilde prefix.

- LANG environment variable is carried over from the Dropbear server process
  From Maxim Kochetkov

- Add /usr/sbin and /sbin to $PATH when logging in as root.
  Patch from Raphaël Hertzog
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903403

- Added client option "-o DisableTrivialAuth". This can be used to prevent
  the server immediately accepting successful authentication (before any auth
  request) which could cause UI confusion and security issues with agent
  forwarding - it isn't clear which host is prompting to use a key.
  Thanks to Manfred Kaiser from Austrian MilCERT

- Add -q client option to hide remote banner, from Hans Harder

- Add -e option to pass all server environment variables to child processes.
  This should be used with caution.
  Patch from Roland Vollgraf (github #118)

- >> Use DSCP for QoS traffic classes. Priority (tty) traffic is now set to
  AF21 "interactive". Previously TOS classes were used, they are not used by
  modern traffic classifiers. Non-tty traffic is left at default priority.

- >> Disable dh-group1 key exchange by default. It has been disabled server
  side by default since 2018.

- >> Removed Twofish cipher

- Dropbear now re-executes itself rather than just forking for each connection
  (only on Linux). This allows ASLR to randomise address space for each
  connection as a security mitigation. It should not have any visible impact
  - if there are any performance impacts in the wild please report it.

Fixes:

- Fix flushing channel data when pty was allocated (github #85)
  Data wasn't completely transmitted at channel close.
  Reported and initial patch thanks to Yousong Zhou

- Check authorized_keys permissions as the user, fixes NFS squash root.
  Patch from Chris Dragan (github #107)

- A missing home directory is now non-fatal, starting in / instead

- Fixed IPv6 [address]:port parsing for dbclient -b
  Reported by Fabio Molinari

- Improve error logging so that they are logged on the server rather than being
  sent to the client over the connection

- Max window size is increased to 10MB, more graceful fallback if it's invalid.

- Fix correctness of Dropbear's handling of global requests.
  Patch from Dirkjan Bussink

- Fix some small bugs found by fuzzers, null pointer dereference crash and leaks
  (post authentication)

- $HOME variable is used before /etc/passwd when expanding paths such as
  ~/.ssh/

Re: Dropbear's usage of 'first_kex_packet_follows' may fail on broken SSH implementations

2022-01-19 Thread Matt Johnston
On Wed, Jan 19, 2022 at 04:23:29PM +0100, Thomas De Schampheleire wrote:
> I recently encountered connection issues when using dropbear as client 
> (2020.81)
> to certain SSH implementations. In both cases, the issue was related to the 
> host
> key verification. It took me a while to find the cause, and I send this mail
> mainly to help other Dropbear users that may have such problem.
> 
> The symptoms I encountered were for one case (a proprietary SSH server
> implementation):

Hi Thomas,

Thanks for the write up. I _think_ in the case of Dropbear
as a client it might be possible to defer sending the key
exchange until the server's version identification is
received, without incurring any extra round trip latency. I
will see if I can implement that. That would use an
allowlist of implementations known to correctly handle
first_kex_packet_follows.

If you could let me know the proprietary version with
problems it would be handy (off list is fine).

Thanks,
Matt


Re: listening service without MMU?

2022-06-25 Thread Matt Johnston

On 2022-06-24 11:26 am, johnea wrote:


I've run across a number of other references since that timeframe that
indicate that dropbear can run on no-MMU platforms using uClibc.

Searching hasn't really led to a conclusive answer. So, could you
please confirm:

Can dropbear run as a listening service on Cortex-M3 with no-MMU?


Previously I would say no - usually it would need to run from inetd that 
executes a separate dropbear server process for each connection.
That is required because on a MMUless system the normal fork() doesn't 
create separate memory spaces for each program, so they interfere with 
each other.


But! In Dropbear 2022.82 it was changed to re-execute itself [1], so it 
is possible that it would work OK on a MMUless system. You could see if 
that works - there might be other assumptions that I have missed. Make 
sure you try a few concurrent connections.


Cheers,
Matt

[1]
- Dropbear now re-executes itself rather than just forking for each 
connection

  (only on Linux). This allows ASLR to randomise address space for each
  connection as a security mitigation. It should not have any visible 
impact

  - if there are any performance impacts in the wild please report it.


Re: Dropbear difficulties due to outdated version?

2022-06-24 Thread Matt Johnston

On 2022-06-25 7:49 am, James Miller wrote:

I set up a small low-resource VPS a few years ago to use mainly as a
light-use xmpp server. I got Dropbear operating there so I could admin
it. Dropbear seemed a good choice since system resources were so
anemic. I recall it being quite challenging to get key-pair
authentication to finally work there, though I can't recall many
details about how I finally succeeded.


Most likely would be OpenSSH requiring sha2 for RSA signatures. If you 
can use

ecdsa keys instead those should work OK.

Alternatively to keep using RSA, set

Host old-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

in your .ssh/config for the client which will allow the older sha1 RSA 
signatures.
Which OpenSSH version is it? https://www.openssh.com/releasenotes.html 
has details

of what has been deprecated.

Matt


The VPS runs Ubuntu 16.04 (EMS), so the version of Dropbear there is a
bit outdated (v2017.75). Since that release was made, various changes
have happened to openssh that may, I assume, make it incompatible with
this version of Dropbear. I am using ssh when I try to connect to the
VPS, btw.


Re: Error forwarding unix domain socket

2022-06-24 Thread Matt Johnston

Sorry for the late reply.

Dropbear doesn't currently support unix domain socket forwarding.

Cheers,
Matt

On 2022-06-07 3:57 pm, Heiko Thiery wrote:

Hi,

Does anyone know if it is possible to do a ssh forwarding on unix
domain sockets when using dropbear?

When I try I get the following error:

channel 2: open failed: unknown channel type:


Re: unexpected restriction on the number of concurrent SSH logins

2022-06-08 Thread Matt Johnston

Thanks for the report.

This was a regression in the re-exec changes, I've pushed a fix to
https://github.com/mkj/dropbear/commit/544f28a05165eb97e18cc03fc8990da842ec3a94

The childpipe file descriptor is used to notify the parent listener that
auth has completed, but I'd missed that the inetd path (used for 
re-exec) ignores that.


Cheers,
Matt

On 2022-06-08 6:28 am, Matthias Lang wrote:

Hi,

My colleague Thomas noticed some unexpected behaviour in recent
dropbear versions. It unexpectedly limits concurrent logins, apparently
to MAX_UNAUTH_CLIENTS.

I expected that setting to limit how many pre-authorisation clients
can connect, but have no effect on the number of authorised
clients. That's how versions dropbear prior to c7b7c9a99 behave.

I checked the mailing list archives back to January. Nothing.

Steps to reproduce on a normal x86 debian box below.

Matt

--
0. Perfectly normal x86 linux box, not some weird embedded system

   uname -a
   Linux hec 5.17.0-1-amd64 #1 SMP PREEMPT Debian 5.17.3-1
(2022-04-18) x86_64 GNU/Linux

1. Build c7b7c9a99 with this in localoptions.h:

   #define MAX_UNAUTH_CLIENTS 2

   make clean && ./configure && make

2. Set up key file and start SSH server

   ./dropbearkey -t rsa -f rsa_host_key
   sudo ./dropbear -E -p 8000 -F -r ./rsa_host_key

3. Test having three parallel SSH sessions open:

ssh -p 8000 127.0.0.1// in one xterm. works.
ssh -p 8000 127.0.0.1// in a second xterm. also works.
ssh -p 8000 127.0.0.1// fails
kex_exchange_identification: Connection closed by remote host

4. Rebuild with ebb4018889

make clean && ./configure && make

Retry step 3. Now it works fine.

(5. Rebuild c7b7c9a99 with #define DROPBEAR_REEXEC 0. Also works fine. 
So

it looks like REEXEC is doing something something different with either
file descriptors or a count of the connections.)

--

--eot--


Re: I can't access the dropbear mailing list archives

2022-06-08 Thread Matt Johnston

Hi Matt,

The server had a missing mount, archives are working again now.
(A few recent messages didn't make the archives, I'll forward/reply them 
in).


Thanks for letting me know.

Cheers,
Matt


On 2022-06-08 6:12 am, Matthias Lang wrote:

Hi,

According to

   https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/dropbear

archives of the mailing list are at

   https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear

That link doesn't work for me, I get a 403 Forbidden "You don't have
permission to access this resource".

The first page also suggests Gmane as an alternative, but AFAICT, that 
was

shut down some time ago. MARC works, though:

   https://marc.info/?l=dropbear=1=2

Matt


Re: Only do connection if I already know the destination?

2022-11-21 Thread Matt Johnston

On 2022-11-21 11:05 pm, M Rubon wrote:

I have an automated remote script that connects to a set of known
servers.  I never want be prompted to add a new host key if the server
is missing from .ssh/known_hosts.   If the key is missing, the client
should just immediately exit.

Dropbear seems to give me the option of relaxing the host key checks
(-y -y).  Is there an option to make them more strict?


I don't think there's any way to do that at the moment.

Cheers,
Matt



M

p.s. OpenSSH client option "StrictHostKeyChecking yes" is basically
what I am looking for.


Re: Authenticating to dropbear using ecdsa-sha2-nistp256

2022-11-10 Thread Matt Johnston
On Tue, Nov 08, 2022 at 04:57:40PM +0200, Rogan Dawes wrote:
> I have created an SSH private key in my M1 Mac's Secure Enclave, and am
> using it to SSH to various targets. Those using OpenSSH work fine, and I am
> prompted to unlock the SE. However, those using dropbear do not work,
> giving me the following result on the client:
> 
> debug1: Offering public key: ecdsa-sha2-nistp256 ECDSA SHA256:XXX agent

> The targets that I have available are OpenWrt 21.02.1 running Dropbear
> v2020.81 and 22.03.0 running Dropbear v2022.82.

Ah, OpenWRT doesn't include ecdsa support (for size
reasons) - only remembered that now. You'll have to use rsa
or ed25519 instead if possible.

It's possible to rebuild their package with the DROPBEAR_ECC
openwrt config option.

Cheers,
Matt


Re: Authenticating to dropbear using ecdsa-sha2-nistp256

2022-11-10 Thread Matt Johnston
On 2022-11-11 11:50 am, Rogan Dawes wrote:

> I was under the impression that the ssh protocol included a handshake step 
> where supported algorithms were exchanged, and keys that do not match are 
> eliminated?

For public key auth the client sends each public key it has to offer,
the server sends a "key OK" message if it's accepted, and then the
client sends its signature. So Dropbear on openwrt gets the ecdsa key
offer and sends a failure response since it doesn't accept that ecdsa
key type. 

Matt

Dropbear 2024.85

2024-04-25 Thread Matt Johnston
Hi all,

Dropbear 2024.85 is released. It fixes a couple of build
regressions in 2024.84. There is no need to upgrade if
2024.84 built OK for your configuration.

https://matt.ucc.asn.au/dropbear/releases/dropbear-2024.85.tar.bz2

Cheers,
Matt

2024.85 - 25 April 2024

  This release fixes build regressions in 2024.84

- Fix build failure when SHA1 is disabled, thanks to Peter Krefting

- Fix build failure when DROPBEAR_CLI_PUBKEY_AUTH disabled, thanks to
  Sergey Ponomarev

- Update debian/ directory with changed paths


Re: Compiling Dropbear with Tru64 on DEC Alpha

2024-03-18 Thread Matt Johnston
Hi Mark, 

I haven't used tru64 for a while, but if you send a log I can have a
look. 

Cheers,
Matt 

On 2024-03-18 5:49 pm, Mark Butt wrote:

> Hello, 
> 
> I have a DEC AlphaServer 4100 with Tru64 5.1B-6.  This is a small side 
> project that I am working on.  When searching for a compatible modern or 
> modern-ish SSH server that would compile on Alpha, I came across the page for 
> Dropbear.  Tru64 5.1 is listed in the platforms section of 
> https://matt.ucc.asn.au/dropbear/dropbear.html but I have not had much luck 
> getting it to compile using either Compaq C or GCC (4.7.4).  
> 
> This may very well be a problem with my build environment or build process.  
> I was wondering if anyone had recently compiled Dropbear on Alpha? 
> If you think it should work, or work with a little effort, I can provide some 
> more details around the errors that I am getting. 
> 
> Thanks and have a great day! 
> -M

Re: [PATCH] Fix compile when disabling SHA-1

2024-04-05 Thread Matt Johnston

Thanks, I've applied it.

Matt

On 2024-04-05 3:37 pm, Peter Krefting wrote:

Fixes compile when disabling SHA-1 with

  #define DROPBEAR_SHA1_HMAC 0
  #define DROPBEAR_RSA_SHA1 0
  #define DROPBEAR_DH_GROUP14_SHA1 0

while keeping SHA-256 enabled.

Should also fix the opposite, but that is not a recommended
configuration.
---
 src/svr-runopts.c |   4 

diff --git a/src/svr-runopts.c b/src/svr-runopts.c
index e8e2f4e64bb..c4f83c111ae 100644
--- a/src/svr-runopts.c
+++ b/src/svr-runopts.c
@@ -610,8 +610,12 @@ void load_all_hostkeys() {

 #if DROPBEAR_RSA
if (!svr_opts.delay_hostkey && !svr_opts.hostkey->rsakey) {
+#if DROPBEAR_RSA_SHA256
disablekey(DROPBEAR_SIGNATURE_RSA_SHA256);
+#endif
+#if DROPBEAR_RSA_SHA1
disablekey(DROPBEAR_SIGNATURE_RSA_SHA1);
+#endif
} else {
any_keys = 1;
}


Dropbear 2024.84

2024-04-04 Thread Matt Johnston
Hi all,

Dropbear 2024.84 is released. It has a few new features and
various fixes, contributed by numerous people over the past
year+.

Download it from 
https://matt.ucc.asn.au/dropbear/releases/dropbear-2024.84.tar.bz2
or https://mirror.dropbear.nl/mirror/releases/dropbear-2024.84.tar.bz2
The tarball is reproducible from git with release.sh

Cheers,
Matt


2024.84 - 4 April 2024

Features and Changes:
  Note >> for compatibility/configuration changes

- >> Only use /etc/shadow when a user has :x: as the crypt in /etc/passwd.
  This is the documented behaviour of passwd(5) so should be consistent with
  other programs. Thanks to Paulo Cabral for the report.
  Note that any users without x as the crypt will not be able
  to log in with /etc/shadow, in cases were the existing configuration
  differs.

- Support -o StrictHostKeyChecking, patch from Sergey Ponomarev

- Support -o BatchMode, from Sergey Ponomarev and Hans Harder

- Support various other -o options compatible with OpenSSH, from
  Sergey Ponomarev. Includes -o PasswordAuthentication

- Add dbclient config file support, ~/.ssh/dropbear_config
  Thanks to tjkolev
  Disabled by default, set #define DROPBEAR_USE_SSH_CONFIG 1

- Add support for unix socket forwarding (destination) on
  the server, thanks to WangYi for the implementation

- Add option to bind to interface, from Diederik De Coninck

- Ignore unsupported arguments in dropbearkey, allow running
  binary as 'ssh-key'. From Sergey Ponomarev

- Save a public key file on generation with dropbearkey.
  -C can be used for a comment, and choose a default key
  type (ed25519 first preference).
  Thanks to Sergey Ponomarev

- Allow inetd to run in non-syslog modes. Thanks to Laurent Bercot
  for the report

- Allow user's own gid in PTY permissions, lets Dropbear work as non-root
  even if /dev/pts isn't mounted with gid=5

- src/distrooptions.h can now be used as another config file.
  This can be used by distributions for customisations (separate
  to the build directory's localoptions.h)

Fixes:

- "dbclient host >> output" would previously overwrite "output", instead of
  appending. Thanks for the report from eSotoIoT

- Add "Strict KEX" support. This mitigates a SSH protocol flaw which lets
  a MITM attacker silently remove packets immediately after the
  first key exchange. At present the flaw does not seem to reduce Dropbear's
  security (the only packet affected would be a server-sig-algs extension,
  which is used for compatibility not security).
  For Dropbear, chacha20-poly1305 is the only affected cipher.
  Both sides of the connection must support Strict KEX for it to be used.

  The protocol flaw is tracked as CVE-2023-48795, details
  at https://terrapin-attack.com . Thanks to the researchers Fabian Bäumer,
  Marcus Brinkmann, and Jörg Schwenk. Thanks to OpenSSH for specifying
  strict KEX mode.

- Fix blocking while closing forwarded TCP sessions. Noticable
  when many connections are being forwarded. Reported and
  tested by GektorUA. Github #230

- Don't offer RSA (then fail) if there is no RSA key. Regression in 2020.79
  Github #219

- Fix missing response to remote TCP requests when it is disabled.
  Patch from Justin Chen. Github #254

- Fix building with DROPBEAR_RSA disabled

- /proc/timer_list is no longer used for entropy, it was a bottleneck.
  Thanks to Aleksei Plotnikov for the report.

- Don't unconditionally enable DROPBEAR_DSS

- Make banner reading failure non-fatal

- Fix DROPBEAR_SVR_MULTIUSER. This appears to have been broken since when it
  was added in 2019. If you're using this let me know (it might be removed
  if I don't hear otherwise). Thanks to davidatrsp

- Fix Y2038 issues

Infrastructure:

- Move source files to src/ subdirectory. Thanks to tjkolev

- Remove more files with "make distclean"

- Add tests for disabled options



<    1   2   3