Dropbear 2024.85

[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: [PATCH] Fix compile when disabling SHA-1

[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

[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

Re: Compiling Dropbear with Tru64 on DEC Alpha

[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: Only do connection if I already know the destination?

[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

[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

Re: Authenticating to dropbear using ecdsa-sha2-nistp256

[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: listening service without MMU?

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

[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

[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

[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

[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

Dropbear 2022.82

[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

[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: Password authentication fails

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

Re: Dropbear 2019.77

[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

[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: restrict access

[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

[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: [PATCH] Introduce extra delay before closing unauthenticated sessions

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

[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: Does Dropbear know what a ~/.ssh/config file is?

[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: Address binding question

[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

[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: OpenWRT Dropbear v2020.80: Exit before auth: No matching algo kex

[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: OpenWRT Dropbear v2020.80: Exit before auth: No matching algo kex

[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: Cannot Connect to Dropbear Server of Openwrt in QEMU

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

[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: "Bad public key options" (Was: Dropbear 2020.79)

[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

[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

[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: scp command exemple

[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: dbclient v2019.78: proxyJump

[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: bug: stdio pipe is root owned so reopening it fails

[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: [PATCH 0 of 1] Fix build

[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: SSH key exchange fails 30-70% of the time on Netgear X4S R7800

[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: SSH key exchange fails 30-70% of the time on Netgear X4S R7800

[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: Hiding dropbear output on boot up

[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: Timeout settings

[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: [PATCH] Add Ed25519 keys support

[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: android access

[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: dropbear and new host keys?

[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 and new host keys?

[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 processes getting into uninterruptible I/O process "D" state

[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: Configuration Issues

[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

[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

[Matt Johnston]

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

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

Cheers,
Matt

> On Thu 11/4/2019, at 12:11 pm, Chahar, Rohini  
> wrote:
> 
> Hi Matt,
>  
> Please find my responses below.
>  
> Regards,
> Rohini
>  
> From: Matt Johnston mailto:m...@ucc.asn.au>> 
> Sent: 10 April 2019 18:39
> To: Chahar, Rohini  <mailto:rohini.cha...@netscout.com>>
> Cc: dropbear@ucc.asn.au <mailto:dropbear@ucc.asn.au>
> Subject: Re: Dropbear 2018.76 when behaving as client sending sha1 as mac
>  
> [EXTERNAL EMAIL]
> Hi Rohini,
>  
> I'm not entirely clear about the problem - is the conneciton failing or is it 
> just selecting hmac-sha2-sha1 which you don't want?
> ROHINI >> Dropbear is selecting sha1 and sha2 on its own. My understanding 
> was first sha2 is tried and when the server do not supports it them dropbear 
> move to sha1 but it is not happening. When sending request to server it is 
> sending sha1 only. In default_options.h file comment also says “/* Message 
> integrity. sha2-256 is recommended as a default, sha1 for compatibility */”
>  
> The algorithm chosen will be the first one in the client's list that is also 
> in the server's list. When you do the "copy to the server" is it dropbear as 
> a client that is sending hmac-sha1? Was that compiled with sha2 enabled in 
> the options?
> ROHINI >> Yes when I am doing copy to server dropbear is selecting sha1. Yes 
> sha2 is enabled in options. I also tried disabling sha1 then dropbear is 
> sending sha2. I do not want to disable sha2 I want it to be the first one 
> used by dropbear. Is there any priority setting which is doing so?
>  
> If you can build them with 
>  
> #define DEBUG_TRACE 1
>  
> in localoptions.h then running with "dropbear -v" and "dbclient -v" will give 
> some debug output, or a tcpdump/wireshark capture should show what's going on 
> too.
> ROHINI >> I captured packets in wireshark and from there only I reached to 
> this conclusion.
>  
> Cheers,
> Matt
> 
> 
> On Wed 10/4/2019, at 8:15 pm, Chahar, Rohini  <mailto:rohini.cha...@netscout.com>> wrote:
>  
> Hi,
>  
> I am experiencing a problem w.r.t dropbear 2018.76. I have the version 
> installed and it is working fine but when I try to do a copy from this to a 
> server that time dropbear is sending mac as hmac-sha1. However when I try to 
> do login via putty that time dropbear behaves as server and uses mac as 
> hmac-sha2-256. 
> In default file it is written that sha2 is default option but it is not 
> coming as default. My understanding was that dropbear sends sha2 as default 
> option and when server do not supports the mac it falls back to sha1.
> Do I need to do some code changes or is this a known problem? Please help me 
> in resolving this issue.
>  
> Regards,
> Rohini

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

[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

Dropbear 2019.78

[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

[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

[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: Dropbear 2018.76

[Matt Johnston]

Hi Warren,

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

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

Cheers,
Matt


On Wed, Mar 20, 2019 at 12:53:55AM -0400, Russell Warren wrote:
> I've just run into this same problem.
> 
> Any word on a new release to fix the numerous changes since 2018.76?
> 
> Also, anyone care to jump in with a recommendation out of these options?
> 
> 1. Continue to use 2017.75?
> 2. Use 2018.76 with the specified patch
> <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: How to get dbclient?

[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: MAX_USERNAME_LEN set too low

[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: dbclient can't connect to cisco

[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

[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: dbclient can't connect to cisco

[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: Strange behaviour surrounding "ssh -T ..." and non-zero exit

[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

[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

Re: Login attempt for nonexistent user

[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: The website is down

[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: User enumeration in Dropbear 2018.76 and earlier

[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: ifndef_wrapper.sh required sed with "-E" which isn't available with old sed version.

[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: potential bug in atomicio?

[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: OpenSSH drop-in replacement

[Matt Johnston]

Hi Martin,

Dropbear should be able to do 1, it will send the PAM_TEXT_INFO as a SSH banner.
SSH clients may display that before asking for a username though, I haven't 
tested.

Dropbear can't change usernames though.

Cheers,
Matt

> On Wed 13/6/2018, at 4:21 pm, Martin van Es  wrote:
> 
> Hi,
> 
> I'm looking for an OpenSSH drop-in replacement that fixes two problems
> in OpenSSH for me:
> 
> 1. Allow PAM_TEXT_INFO conversation messages displayed during
> keyboard-interactive PAM authentication (without buffering). I don't
> want a prompt, only display a url containing a challenge.
> 2. Honour new username after PAM set PAM_USER using
> pam_set_item(PAM_USER, value)
> 
> Would dropbear be a valid contender?
> 
> Martin
> -- 
> If 'but' was any useful, it would be a logic operator

Re: Dropbear incompatible with current python Twisted

[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: Problem using reverse ssh tunnel (remote port forwading)

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

[Matt Johnston]

Hi John,

The reason it's not supported is that noone has implemented it yet. I don't 
have plans to, but if someone wants to send an implementation it could be added.

Are you interested in client or server?

Cheers,
Matt


> On Sat 19/5/2018, at 12:19 am, John  wrote:
> 
> Are there any plans to add layer 3 Tunnel support to dropbear?  Similar to 
> OpenSSH's -w option added in version 4.3 using Linux's TUN driver.  
> 
> Any reason for not supporting it yet?
> 
> Thanks,
> -John

Re: Dropbear ssh tunneling segfault

[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 

Re: Dropbear server exit when idle?

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

[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

[Matt Johnston]

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

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

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

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

Ah, I'll fix the docs.

Thanks,
Matt

Re: Dropbear 2018.76

[Matt Johnston]

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

Hi Steffen,

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

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

Cheers,
Matt

Re: Dropbear 2018.76

[Matt Johnston]

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

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

Cheers,
Matt

Dropbear 2018.76

[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: "Failed loading .. " host key files warning messages

[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: ssh login stuck at "expecting SSH2_MSG_KEX_ECDH_REPLY"

[Matt Johnston]

Hi Hari,

Can you get a backtrace of the stuck dropbear process in 2) ? That might 
suggest what's going wrong.

Cheers,
Matt

> On Mon 23/10/2017, at 7:12 pm, Hariharasubramanian Ramasubramanian 
>  wrote:
> 
> ssh login gets stuck at "expecting SSH2_MSG_KEX_ECDH_REPLY" at random.
> 
> However forcing ssh to use 3des cipher suite makes the login go through.
> 
> What causes the login to succeed when cipher suite is forced but fail 
> otherwise ?
> 
> Here are the debug for 3 different use cases:
> 1) successful login attempt
> 2) failed login attempt
> 3) forced 3des cipher suite
> 
> ==
> 1) Successful login attempt
> ==
> -bash-4.1$ ssh -vvv root@wsbmc011
> OpenSSH_5.8p2, OpenSSL 1.0.0g 18 Jan 2012
> debug1: Reading configuration data 
> /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to wsbmc011 [9.3.21.42] port 22.
> debug1: Connection established.
> debug3: Incorrect RSA1 identifier
> debug3: Could not load 
> "/gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_rsa" as a RSA1 public key
> debug2: key_type_from_name: unknown key type '-BEGIN'
> debug3: key_read: missing keytype
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug2: key_type_from_name: unknown key type '-END'
> debug3: key_read: missing keytype
> debug1: identity file /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_rsa 
> type 1
> debug1: identity file 
> /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_rsa-cert type -1
> debug1: identity file /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_dsa 
> type -1
> debug1: identity file 
> /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_dsa-cert type -1
> debug1: identity file 
> /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_ecdsa type -1
> debug1: identity file 
> /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_ecdsa-cert type -1
> debug1: Remote protocol version 2.0, remote software version dropbear_2016.74
> debug1: no match: dropbear_2016.74
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.8
> debug2: fd 3 setting O_NONBLOCK
> debug3: load_hostkeys: loading entries for host "wsbmc011" from file 
> "/gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/known_hosts"
> debug3: load_hostkeys: found key type RSA in file 
> /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/known_hosts:23
> debug3: load_hostkeys: loaded 1 keys
> debug3: order_hostkeyalgs: prefer hostkeyalgs: 
> ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit: 
> ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: 
> 

Re: ssh disconnects due to corrupt packet (dropbear compiled with DEBUG_TRACE)

[Matt Johnston]

Hi,

It looks like you're running in from inetd and the TRACE output is 
ending up getting sent over the network socket. The length 1414676803 is 
'TRAC' converted to ascii.
I guess dropbear is running with "-E", or what is the configuration? 
That won't work, you'll need to log to syslog instead (the default) when 
using inetd.
I can't think of any known issues in 2016.74 causing messages like that 
- if you keep seeing it could you send me the logs/pcap off-list, 
without -v.


Cheers,
Matt

On 2017-10-11 11:25 am, Hariharasubramanian Ramasubramanian wrote:

I was observing occasional connection disconnect during session setup 
with dropber version 2016.74.


I compiled dropbear (version 2016.74) with DEBUG_TRACE flag on (in 
debug.h) to help me debug these session setup errors.


However when I run dropbear with the -v switch, client fails to 
connect, _everytime_.


The client (9.41.166.131) is OpenSSH_5.8p2 running on RHEL 6.4.
The server (9.3.21.44) is dropbear_2016.74

1) Is this a known issue in dropbear_2016.74 ?
2) Also please suggest how I can debug ssh session setup failures with 
dropbear server ?



The output of ssh -vvv root@9.3.21.44 is as follows:
-bash-4.1$ ssh -vvv root@9.3.21.44
OpenSSH_5.8p2, OpenSSL 1.0.0g 18 Jan 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 9.3.21.44 [9.3.21.44] port 22.
debug1: Connection established.
debug1: identity file 
/afs/awd.austin.ibm.com/usr/u2/hramasub/.ssh/id_rsa type -1
debug1: identity file 
/afs/awd.austin.ibm.com/usr/u2/hramasub/.ssh/id_rsa-cert type -1
debug1: identity file 
/afs/awd.austin.ibm.com/usr/u2/hramasub/.ssh/id_dsa type -1
debug1: identity file 
/afs/awd.austin.ibm.com/usr/u2/hramasub/.ssh/id_dsa-cert type -1
debug1: identity file 
/afs/awd.austin.ibm.com/usr/u2/hramasub/.ssh/id_ecdsa type -1
debug1: identity file 
/afs/awd.austin.ibm.com/usr/u2/hramasub/.ssh/id_ecdsa-cert type -1
debug1: ssh_exchange_identification: [1522] Oct 09 11:35:43 Failed 
loading /var/lib/dropbear/dropbear_rsa_host_key
debug1: ssh_exchange_identification: TRACE (1522) 0.00: leave 
loadhostkey
debug1: ssh_exchange_identification: TRACE (1522) 0.001107: enter 
buf_get_rsa_priv_key
debug1: ssh_exchange_identification: TRACE (1522) 0.001398: enter 
buf_get_rsa_pub_key
debug1: ssh_exchange_identification: TRACE (1522) 0.002371: leave 
buf_get_rsa_pub_key: success
debug1: ssh_exchange_identification: TRACE (1522) 0.003364: leave 
buf_get_rsa_priv_key
debug1: ssh_exchange_identification: TRACE (1522) 0.003685: leave 
loadhostkey
debug1: ssh_exchange_identification: [1522] Oct 09 11:35:43 Failed 
loading /etc/dropbear/dropbear_dss_host_key
debug1: ssh_exchange_identification: TRACE (1522) 0.009414: leave 
loadhostkey
debug1: ssh_exchange_identification: [1522] Oct 09 11:35:43 Failed 
loading /etc/dropbear/dropbear_ecdsa_host_key
debug1: ssh_exchange_identification: TRACE (1522) 0.014786: leave 
loadhostkey
debug1: ssh_exchange_identification: TRACE (1522) 0.014964: Disabling 
key type 1
debug1: ssh_exchange_identification: TRACE (1522) 0.015427: Disabling 
key type 2
debug1: ssh_exchange_identification: TRACE (1522) 0.016107: Disabling 
key type 3
debug1: ssh_exchange_identification: TRACE (1522) 0.016541: Disabling 
key type 4
debug1: ssh_exchange_identification: [1522] Oct 09 11:35:43 Child 
connection from :::9.41.166.131:49818
debug1: ssh_exchange_identification: TRACE (1522) 0.030210: enter 
session_init
debug1: ssh_exchange_identification: TRACE (1522) 0.030381: 
setnonblocking: 0
debug1: ssh_exchange_identification: TRACE (1522) 0.031095: leave 
setnonblocking
debug1: ssh_exchange_identification: TRACE (1522) 0.031521: 
setnonblocking: 0
debug1: ssh_exchange_identification: TRACE (1522) 0.031948: leave 
setnonblocking
debug1: ssh_exchange_identification: TRACE (1522) 0.032572: 
update_channel_prio
debug1: ssh_exchange_identification: TRACE (1522) 0.033036: 
update_channel_prio: not any
debug1: ssh_exchange_identification: TRACE (1522) 0.033453: Dropbear 
priority transitioning 10 -> 11
debug1: ssh_exchange_identification: TRACE (1522) 0.034171: 
setnonblocking: 4
debug1: ssh_exchange_identification: TRACE (1522) 0.034642: leave 
setnonblocking
debug1: ssh_exchange_identification: TRACE (1522) 0.035068: 
setnonblocking: 5
debug1: ssh_exchange_identification: TRACE (1522) 0.035746: leave 
setnonblocking
debug1: ssh_exchange_identification: TRACE (1522) 0.036801: leave 
session_init
debug1: ssh_exchange_identification: TRACE (1522) 0.037927: 
kexinitialise()
debug1: ssh_exchange_identification: TRACE (1522) 0.038795: 
DATAALLOWED=0

debug1: ssh_exchange_identification: TRACE (1522) 0.039085: -> KEXINIT
debug1: ssh_exchange_identification: TRACE (1522) 0.039748: enter 
set_connect_fds
debug1: ssh_exchange_identification: TRACE (1522) 

Re: proof-of-concept ed25519 crypto and other additions implemented

[Matt Johnston]

Hi Péter,

Thank you for the work. I think most of these look useful and could be merged. 
I'll have a closer look over them in the next week or so with some more 
detailed comments.

A few comments for now:

- I'm tending to avoid "make CONFIGVAR=1", I think all of yours can be in 
options.h instead? You don't have to worry about pulling in unneeded size like 
keyimport.o - if nothing is called in that file then it will be excluded from 
the linked executable.
- Can the patches be made from a fork of the Dropbear tree, with the 2017.75 
tag? That will make merging/cherry picking easier 
https://github.com/mkj/dropbear/tree/DROPBEAR_2017.75 


- I don't like the pointer arithmetic 
https://github.com/pts/pts-dropbear/blob/4bb002ccad33a5fa55b88b4216586b09881e0d3c/ed25519.c#L70
 


if (buf->pos + 83 > buf->len ||
0 != memcmp(buf->data + buf->pos, "\0\0\0\x0bssh-ed25519\0\0\0@", 
19)
   ) return DROPBEAR_FAILURE;
memcpy(key->spk, buf->data + buf->pos + 19, 64);

Instead it should use buf_getstring(), buf_getbufstring(), buf_incrwritepos() 
etc.

-  Agree that SHA512 from libtomcrypt should be used instead.
- what is the reason for wanting a 8192 bit RSA key?

I see you mentioned chacha20-poly1305 in the TODO. If you (or anyone else) is 
going to implement that it would be worth using the upcoming libtomcrypt 1.18 
release which supports those. The mode used by OpenSSH may be a bit different 
though, with a separate cipher for lengths.

Cheers,
Matt

> On Mon 2/10/2017, at 12:26 am, Péter Szabó  wrote:
> 
> Dear Dropbear Authors,
> 
> Thank you for your work on Dropbear! It's a great SSH server and toolset for 
> resource-constrained systems, I use it every day.
> 
> This weekend I've implemented a couple of features I've always wanted to have:
> 
> * Added ssh-ed25519 crypto for server host keys and user keys. The 
> implementation is based on TweetNaCl v20140427.
> * Added environment variable propagation (similar to OpenSSH AcceptEnv, 
> command-line flag -A) to Dropbear sshd.
> * Added autodetection and loading of OpenSSH hostkeys to Dropbear sshd (with 
> `make OPENSSHHOSTKEYLOAD=1').
> * Added flag to dropbearkey to generate private keys in OpenSSH format 
> directly (dropbearkey -Z openssh, with `make WRITEOPENSSHKEYS=1').
> * Improved some command-line flags (e.g. dropbear -E is always available).
> * Compilation instructions for pts-xstatic (statically linked i386 Linux 
> binary). Binary size is 350456 bytes.
> * Added option to compile without loading any system hostkeys (e.g. from 
> /etc/dropbear) (with `make NOSYSHOSTKEYLOAD=1').
> * Made dropbearkey behavior is more compatible with ssh-keygen in OpenSSH:
> ** dropbearkey now creates a .pub file.
> ** -b bits flag.
> ** -C comment flag. (The comment will be added to the public key file, and 
> not to the private key file.)
> ** -P passphrase flag. Only the empty passhprase is allowed.
> ** -N passphrase flag. Only the empty passhprase is allowed.
> * Added autodection of the input private key file format, as `dropbearconvert 
> any'.
> 
> The code is in https://github.com/pts/pts-dropbear 
> , which is a fork of 
> dropbear-2017.75.tar.bz2.
> 
> It would be great if these improvements could be merged to upstream Dropbear, 
> so all Dropbear users would benefit. Please let me know what the best course 
> of action would be to make this happen, and how I can help.
> 
> Best regards,
> 
> Péter Szabó

Re: RSA default key size of 2048 bits too large for low-spec systems

[Matt Johnston]

Hi Brent,

I'll see about improving the visibility of the default key sizes in options.h 
and also dropbearkey's printout. 
I changed to 2048 because 1024 is likely to become breakable within the next 
few years, it's best to have secure defaults if systems are going to remain 
un-updated for that timeframe.
The change was never mentioned in the CHANGES for 2013.61test - sorry about 
that oversight, I've added it now.

For a slow device maybe it'd be better to disable RSA and DSS altogether and 
just use ECDSA keys? Those are siginificantly faster and supported by all 
recent SSH implementations I know of (at least for desktops and servers). The 
newer "-R" option can also be used to generate keys on first connection - that 
might be fast enough with ECDSA.

Cheers,
Matt

> On Sat 24/6/2017, at 9:31 am, Brent Roman  wrote:
> 
> I recently upgraded some low power ARM9 systems from dropbear v0.52 to 
> v2017.75
> 
> Everything went well until a system system tried to generate server keys on 
> first boot.
> Then it hung while working to generate the default 2048 bit RSA key.
> 
> Further investigation determined that it had not really hung.
> Given many tens of minutes, it would complete the initial boot.
> 
> Why did we decide to change the default to 2048 bit keys given the cost of 
> generating these on the embedded systems for which it is intended to run?
> 
> The #define for setting the default key size is currently in a .c file.
> Could this be moved to the options.h file with a comment recommending 
> reducing the default size when targeting slow systems?
> 
> Note, I do realize that there is a -s option for dropbearkey, but the 
> appropriate values for that option are dependent on the key algorithm 
> selected.  I believe the defaults should always be usable.
> 
> Dropbear is a great piece of Open Source software.
> 
> I hope you'll consider this small change.
> 
> - brent
> 
> 
> 

Re: OpenWrt/LEDE: dropbear & MIPS & gcc 7.1.0

[Matt Johnston]

Hi Syrone,

Updating libtom makes sense, it's on the todo list.

I'm curious if it's a bug in old libtommath or new gcc. In my experience 
differences between optimisation levels are more often problems with the 
compiler, but could be either.
If you could get a backtrace of a stuck "dbclient" built with gcc 7 it might be 
useful to see what's going on (and to know where to look in the libtommath 
commit log)

Cheers,
Matt

> On Thu 1/6/2017, at 2:28 pm, Syrone Wong  wrote:
> 
> Hi all,
> 
> Recently, I upgrade my LEDE toolchain to binutils 2.28 & GCC 7, notice
> I cannot SSH to router.
> 
> A more detailed description can be found
> (http://lists.infradead.org/pipermail/lede-dev/2017-May/007753.html),
> later, Kevin find it might related to libtommath
> (http://lists.infradead.org/pipermail/lede-dev/2017-May/007797.html).
> 
> Two possible solution:
> 
> i. change libtommath compilation flag from -Os to -O2:
> http://lists.infradead.org/pipermail/lede-dev/2017-May/007843.html
> 
> ii. update the bundled libtom* to latest:
> http://lists.infradead.org/pipermail/lede-dev/2017-May/007849.html
> 
> Please update the bundled libraries to latest, or help to find the root cause.
> 
> Thanks in advance
> 
> Best Regards,
> Syrone Wong

Re: Dropbear 2017.75

[Matt Johnston]

On Fri, May 19, 2017 at 02:37:28PM +0200, Guilhem Moulin wrote:
> Hi Matt,
> 
> On Thu, 18 May 2017 at 23:02:09 +0800, Matt Johnston wrote:
> > Dropbear 2017.75 is released. This has a couple of security
> > fixes and a couple of bug fixes since 2016.74.
> 
> FYI https://matt.ucc.asn.au/dropbear/CHANGES yields 403 forbidden.

Sorry missed this email before. Noticed it myself just now
while requesting CVEs, I've fixed it.

Re: Restrictions for password logins

[Matt Johnston]

On Fri, May 19, 2017 at 07:42:21AM +, Henrik Uggla wrote:
> Hi!
> 
> 
> How can I set restrictions, like those given in authorized_keys, to all 
> password logins?

Hi Henrik,

You can't set all of those restrictions like command= though
you can disable TCP forwarding at compile time in options.h

What restrictions were you looking at?

Cheers,
Matt

Dropbear 2017.75

[Matt Johnston]

Hi all,

Dropbear 2017.75 is released. This has a couple of security
fixes and a couple of bug fixes since 2016.74.

https://matt.ucc.asn.au/dropbear/dropbear.html

I'm intending to make another release in the next couple of
weeks including the various pending fixes in the Mercurial
tree and pull requests.  That's a bit more obtrusive with
changes to options.h and #ifdef => #if.

Cheers,
Matt

2017.75 - 18 May 2017

- Security: Fix double-free in server TCP listener cleanup
  A double-free in the server could be triggered by an authenticated user if
  dropbear is running with -a (Allow connections to forwarded ports from any 
host)
  This could potentially allow arbitrary code execution as root by an 
authenticated user.
  Affects versions 2013.56 to 2016.74. Thanks to Mark Shepard for reporting the 
crash.

- Security: Fix information disclosure with ~/.ssh/authorized_keys symlink.
  Dropbear parsed authorized_keys as root, even if it were a symlink. The fix
  is to switch to user permissions when opening authorized_keys

  A user could symlink their ~/.ssh/authorized_keys to a root-owned file they
  couldn't normally read. If they managed to get that file to contain valid
  authorized_keys with command= options it might be possible to read other
  contents of that file.
  This information disclosure is to an already authenticated user.
  Thanks to Jann Horn of Google Project Zero for reporting this.

- Generate hostkeys with dropbearkey atomically and flush to disk with fsync
  Thanks to Andrei Gherzan for a patch

- Fix out of tree builds with bundled libtom
  Thanks to Henrik Nordström and Peter Krefting for patches.

Re: Multiple authorized_keys files??

[Matt Johnston]

Hi Cody,

It doesn't have that option at the moment. What other files would you use?

Cheers,
Matt

On Thu, Feb 09, 2017 at 11:08:16AM -0500, Cody Scott wrote:
> I wondering if it is possible to have multiple authorized_keys files. By
> default Dropbear uses ~/.ssh/authorized_keys
> 
> Is it possible to specify another path of a authorized_keys file?
> 
> 
> Thanks,
> 
> Cody Scott

Re: SEGV in Dropbear v2016.74 when connect with HostKeyAlgorithms=ssh-dss or HostKeyAlgorithms=ssh-dss

[Matt Johnston]

Hi Konstantin,

Would you be able to run Dropbear under inetd and see if that helps? uClinux 
generally requires that - though it's not obvious to me how it could cause this 
crash.
Is there any chance of getting a backtrace where it is crashing? The RSA and 
DSS crashes are at different spots, so I guess some global state might be 
getting corrupted.
When it successfully runs (no HostKeyAlgorithms) I assume it is using ecdsa for 
the hostkey?

Cheers,
Matt


> On Wed 18/1/2017, at 8:53 am, Konstantin Lazarev  wrote:
> 
> Hello,
> 
> I see consistent SEGV when running Dropbear v2016.74 in uClinux 2.6.33 on 
> ARMv7m-cortex-m4 processor
> Faults happen only if client specifying HostKeyAlgorithms option.
> Please see verbose output from client and dropbear:
> 
> [root@172.17.152.20 : ]# dropbear -V
> Dropbear v2016.74
> 
>  from client 
> ---
> $ssh -v -o HostKeyAlgorithms=ssh-dss root@172.17.152.20 
> 
> OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug1: Connecting to 172.17.152.20 [172.17.152.20] port 22.
> debug1: Connection established.
> debug1: key_load_public: No such file or directory
> debug1: identity file /home//.ssh/id_rsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home//.ssh/id_rsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home//.ssh/id_dsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home//.ssh/id_dsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home//.ssh/id_ecdsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home//.ssh/id_ecdsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home//.ssh/id_ed25519 type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home//.ssh/id_ed25519-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
> debug1: Remote protocol version 2.0, remote software version dropbear_2016.74
> debug1: no match: dropbear_2016.74
> debug1: Authenticating to 172.17.152.20:22  as 
> 'root'
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: algorithm: curve25519-sha...@libssh.org 
> 
> debug1: kex: host key algorithm: ssh-dss
> debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 
> compression: none
> debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 
> compression: none
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> Connection closed by 172.17.152.20 port 22
> 
>  from dropbear 
> ---
> [root@172.17.152.20 : ]# dropbear -v -F
> TRACE  (2934) 0.00: enter buf_get_rsa_priv_key
> TRACE  (2934) 0.000702: enter buf_get_rsa_pub_key
> TRACE  (2934) 0.003142: leave buf_get_rsa_pub_key: success
> TRACE  (2934) 0.006667: leave buf_get_rsa_priv_key
> TRACE  (2934) 0.007364: leave loadhostkey
> TRACE  (2934) 0.008475: enter buf_get_dss_pub_key
> TRACE  (2934) 0.029568: leave buf_get_dss_pub_key: success
> TRACE  (2934) 0.030491: leave loadhostkey
> TRACE  (2934) 0.031491: enter buf_get_ecdsa_priv_key
> TRACE  (2934) 0.032079: enter buf_get_ecc_raw_pubkey
> TRACE  (2934) 0.037565: leave buf_get_ecdsa_pub_key
> TRACE  (2934) 0.038492: leave loadhostkey
> TRACE  (2934) 0.049830: Disabling key type 2
> TRACE  (2934) 0.050450: Disabling key type 3
> TRACE  (2934) 0.110221: listensockets: 1 to try
> TRACE  (2934) 0.37: listening on ':22'
> TRACE  (2934) 0.111844: enter dropbear_listen
> TRACE  (2934) 0.112368: dropbear_listen: all interfaces
> TRACE  (2934) 0.113916: bind(22) failed
> TRACE  (2934) 0.114629: leave dropbear_listen: success, 1 socks bound
> TRACE  (2934) 0.115578: set_listen_fast_open failed for socket 3: Protocol 
> not available
> [2934] Jan 01 00:16:07 Not backgrounding
> [2934] Jan 01 00:16:12 Child connection from 172.17.163.3:42180 
> 
> TRACE  (2934) 5.057261: enter session_init
> TRACE  (2934) 5.058028: setnonblocking: 5
> TRACE  (2934) 5.058726: leave setnonblocking
> TRACE  (2934) 5.059736: setnonblocking: 5
> TRACE  (2934) 5.060404: leave setnonblocking
> TRACE  (2934) 5.060983: update_channel_prio
> TRACE  (2934) 5.061525: update_channel_prio: not any
> TRACE  (2934) 5.062037: Dropbear priority transitioning 10 -> 11
> TRACE  (2934) 5.062814: setnonblocking: 3
> TRACE  (2934) 5.063414: leave 

Re: Port forwarding for certain users only

[Matt Johnston]

Hi Peter,

Currently I don't think that's possible, sorry. There are restrictions for 
public keys auth but not password users.

Matt

> On Wed. 23/11/2016, at 10:55 pm, Peter Krefting  
> wrote:
> 
> Hi!
> 
> Is there a way to restrict port forwarding to certain users only?
> 
> On an embedded device, I have a user that opens a settings menu when logging 
> in (with username + password), and I do not wish that user to allow port 
> forwarding. The UID for the login is 0 because it needs to be able to change 
> stuff on the system, but there is a "root" account with a regular shell that 
> preferrably should be able to forward ports.
> 
> -- 
> \\// Peter - http://www.softwolves.pp.se/

Re: Building with Musl

[Matt Johnston]

Hi Andrew,

I suspect Dropbear itself needs fixing, your workaround sounds fine for now. 
The configure script should probably just test for HAVE_LINUX_TYPES_H or 
similar and the required #defines. I'll look at it.

Cheers,
Matt

#ifdef SO_PRIORITY
#include 
#include 
#endif




> On Tue 26/7/2016, at 7:20 pm, Andrew Bainbridge  wrote:
> 
> Andrew Bainbridge  microsoft.com> writes:
> 
> My embedded device is running Linux 3.4.0. I couldn't find 
> a package of kernel 3.4.0 kernel headers available on 
> Raspbian package manager, so I installed the nearest, which
> was linux-headers-3.6-trunk-rpi. Already, I can see myself 
> falling into a rabbit hole.
> 
> Then I found lots more compile errors failing to find more
> headers. So I ended up with an include path like this:
> 
> export CFLAGS="-I ../zlib-1.2.8 -I /usr/src/linux-headers-3.6
> -trunk-common/include -I /usr/src/linux-headers-3.6-trunk-
> common/arch/arm/include -I /usr/include/arm-linux-gnueabihf"
> 
> But then I end up with a error message from line 30 of 
> /usr/include/arm-linux-gnueabihf/bits/types.h. The compiler 
> complains about the keyword "typedef". The previous line was
> #include , so presumably that file left the
> compiler in a bad state. 
> 
> At this point I gave up and removed #includes of 
> linux/types.h and linux/pkt_sched.h from dropbear's 
> includes.h. Then the only thing that failed to compile was a
> couple of places that wanted definitions of 
> TC_PRIO_INTERACTIVE_BULK and TC_PRIO_INTERACTIVE. Grepping
> the 3.6 kernel headers I installed, I saw that they are
> defined as 4 and 6 respectively, so I just pasted those 
> values in as literals. This is entirely not cool. I'm 
> ashamed. However, the code now compiles and works on the 
> embedded device.
> 
> I guess me learning how to cross compile properly is
> off-topic for this mailing list.
> 

Dropbear 2016.74, security updates

[Matt Johnston]

Hi all,

Dropbear 2016.74 is released. This includes fixes for a few
security issues. Further details will be published by Beyond
Security in a week or so, I will update CVE numbers when available.

Downloads are at https://matt.ucc.asn.au/dropbear/dropbear.html

I strongly advise upgrading any systems where dbclient or
dropbearkey is used with arguments/input provided from external
sources, or systems where Unix usernames can be chosen
arbitrarily. The release also includes a fix for a
TCP forwarding issue that has affected quite a few people.

Cheers,
Matt

2016.74 - 21 July 2016

- Security: Message printout was vulnerable to format string injection.

  If specific usernames including "%" symbols can be created on a system
  (validated by getpwnam()) then an attacker could run arbitrary code as root
  when connecting to Dropbear server.

  A dbclient user who can control username or host arguments could potentially
  run arbitrary code as the dbclient user. This could be a problem if scripts
  or webpages pass untrusted input to the dbclient program.

- Security: dropbearconvert import of OpenSSH keys could run arbitrary code as
  the local dropbearconvert user when parsing malicious key files

- Security: dbclient could run arbitrary code as the local dbclient user if
  particular -m or -c arguments are provided. This could be an issue where
  dbclient is used in scripts.

- Security: dbclient or dropbear server could expose process memory to the
  running user if compiled with DEBUG_TRACE and running with -v

  The security issues were reported by an anonymous researcher working with
  Beyond Security's SecuriTeam Secure Disclosure www.beyondsecurity.com/ssd.html

- Fix port forwarding failure when connecting to domains that have both
  IPv4 and IPv6 addresses. The bug was introduced in 2015.68

- Fix 100% CPU use while waiting for rekey to complete. Thanks to Zhang Hui P
  for the patch

Re: ED25519 key support?

[Matt Johnston]

Hi Stephen,

I may eventually, though it isn't high on the priority list.
What's your use for ed25519 keys rather than other ecdsa?

Cheers,
Matt


> On Sun 26/6/2016, at 7:24 am, Stephen Kent  wrote:
> 
> Are there any plans to add support for ED25519 user and host keys in dropbear?
> 
> Thanks,
> 
> Stephen

Re: Running Dropbear Without Root Permissions

[Matt Johnston]

My guess is that the problem is related to /etc/shadow. If
the crypted password there isn't readable then it will use
the entry from /etc/passwd - I guess that's something like
'!!' which would signify a locked account.

For testing you can always hardcode a password crypt in debug.h

Cheers,
Matt

On Sun, Jun 12, 2016 at 11:31:55AM +0200, Hans Harder wrote:
> I have it running as a separate daemon on a few systems as a non root user
> without problems..
> I changed the config.h to disable all the features which might require more
> rights than the user has or uses OS functions  for instance
>  DISABLE_PAM, DISABLE_LASTLOG,  DISABLE_SYSLOG
> I only use the user daemon with ssh keys...
> 
> Also I changed the locations of all the needed files to a local locaition
> for instance in the options.h file  where the hostkeys are located
>  (removed the /etc path from it)
> 
> That should make it work I believe
> 
> 
> Hans
> 
> 
> On Fri, Jun 10, 2016 at 10:43 AM, Nixon, Kent W  wrote:
> 
> > Hi all,
> >
> > I'm currently testing my (default) compile settings of dropbear 2016.73 on
> > an x86_64 Ubuntu 14.04 machine. I'm running the dropbear server from the
> > terminal of a standard user account and attempting to connect using
> > dbclient as that same user from the same machine just to test/learn how to
> > use dropbear before I attempt to cross-compile it and run it on an Android
> > system.
> >
> > I currently run the following command to start the server:
> >
> > dropbear -F -p  -E -R -m
> >
> > And attempt to connect (using the same machine) as the same user that is
> > running dropbear using:
> >
> > dbcleint -p  -y @127.0.0.1
> >
> > Everything seems to work well, except that after I enter the appropriate
> > password, the client is rejected by the server which posts the message:
> >
> > User account '' is locked
> >
> > However, following the same steps as above, but running the dropbear
> > server with root permissions, everything works as expected (i.e. I am able
> > to open a remote shell without any problems).
> >
> > What changes when dropbear is run with standard user permissions that is
> > causing the account to be 'locked'? Do I need to locate the rsa/dss/ecdsa
> > keys somewhere else other than /etc/dropbear/?
> >
> > Thanks in advance for your time and consideration!
> >
> > ~ Kent
> >

Re: Keepalive timeout with dropbear client

[Matt Johnston]

Hi David,

Dropbear since 2015.68 always sets the socket non-blocking [1], so I think that 
change should be safe on older versions. The only risk I can think of is if it 
gets in some state where it might spin with 100% CPU.

Cheers,
Matt

[1] 
https://secure.ucc.asn.au/hg/dropbear/annotate/10f198d4a308/common-session.c#l68


> On Tue 7/6/2016, at 7:59 pm, David Chapdelaine  
> wrote:
> 
> Hi everyone,
>  
> We have been using version 65 of Dropbear to maintain an ssh connection to a 
> central server. It usually works fine, but when there is a network failure 
> the Dropbear client waits until there is a tcp timeout before declaring that 
> there was a keepalive timeout. So in practice even though we set the 
> keepalive timeout as 30 seconds, dbclient doesn’t exit before ~15 minutes 
> which is when the tcp timeout is triggered.
>  
> By digging in dropbear’s code I noticed that when running in client mode, the 
> connection to the server is blocking whereas that connection is non blocking 
> when running in server mode. I thus changed the connection to non blocking in 
> client mode. To do this I changed the call to connect_remote line 75-76 of 
> cli-main.c from
>  
> int sock = connect_remote(cli_opts.remotehost, cli_opts.remoteport, 0, 
> );
> 
> 
> to
> 
> int sock = connect_remote(cli_opts.remotehost, cli_opts.remoteport, 1, 
> );
> 
>  
> Initial tests are good so far and it addresses our issue, but I wanted to run 
> this through you to get your insights on potential problems with this change. 
> As far as you know, is there any side effect that we should be aware of? Was 
> there a reason why the connection was blocking in client mode?
>  
> Thanks a lot for your inputs!
>  
> David Chapdelaine
> Développeur logiciel | Software Developer
> T|P: +1-514-332-4000 p.6595 | dchapdela...@genetec.com 
> 
>  
> 
>  
> Conçu pour évoluer | Built to evolve | www.genetec.com/dna 
> 
>   
>   
>   
> 

Re: a bug detected in dropbear v071

[Matt Johnston]

On Wed 11/5/2016, at 11:55 pm, Thomas De Schampheleire 
 wrote:
>> 
>> I expect the next release will be in perhaps a month's
>> time - it could be longer though.
> 
> Is there a certain strategy with respect to timing of releases? Could
> you describe it?
> 
> It seems a long time to me to wait a month before releasing a bug fix
> of this type (100% CPU load). Meanwhile we can of course apply your
> patch explicitly, but other users may be experiencing the same and may
> not be aware of this fix.

Hi Thomas,

Releases usually occur once sufficient new CHANGES items have accumulated, 
around a dozen or so is the trend. So far since 2016.73 there are about 5. For 
the next release I intend to sort out being able to build without sha1, it also 
needs some more thorough testing of the #ifdef->#if changes.

If there's an important fix then I'll sometimes make a smaller release. How 
frequently have you seen the 100% CPU rekey issue? As far as I can tell the 
bug's been present since 2007 with no other reports, which is why I was leaving 
it for the next release.

Cheers,
Matt

Re: a bug detected in dropbear v071

[Matt Johnston]

Hi,

I expect the next release will be in perhaps a month's
time - it could be longer though.

Cheers,
Matt

On Tue, May 10, 2016 at 08:21:35AM +, ZHANG Hui P wrote:
> Hi ,
>  I have verified this commit, it works well. When can we got a formal 
>  release includes this commit?
> thanks.
> 
> From: Matt Johnston [mailto:m...@ucc.asn.au]
> Sent: 2016年4月29日 23:18
> To: ZHANG Hui P
> Cc: dropbear@ucc.asn.au
> Subject: Re: a bug detected in dropbear v071
> 
> Hi,
> 
> I think this problem should be solved by the commit
> https://secure.ucc.asn.au/hg/dropbear/rev/432b0a030fd6
> 
> Thank you for the detailed report.
> 
> Cheers,
> Matt
> 
> 
> On Wed 20/4/2016, at 2:44 pm, ZHANG Hui P 
> <hui.p.zh...@alcatel-sbell.com.cn<mailto:hui.p.zh...@alcatel-sbell.com.cn>> 
> wrote:
> 
> Hi:
>  I am a software engineer of Alcatel-Lucent. In our product we use 
> dropbear v071 under the OS: Linux version 3.4.24. At most time it works 
> perfectly, but recently we got a problem: sometimes a child-process of 
> dropbear occupied nearly 100% CPU (we use ARM1176, single-core). After I 
> investigated it ,I found it is cause by a misuse of KEX_REKEY_TIMEOUT.
> KEX_REKEY_TIMEOUT is defined as 8hours. that means when a session lasts more 
> than 8 hours, the server and client will re-exchange their KEY for security 
> reason. The timestamp of last-time KEY-EXCHANGED is recorded in variable 
> "ses.kexstate.lastkextime".
>  The child dropbear process decides the "timeout" parameter of "select" 
> function by calling "select_timeout". we can see it checks the timeout-events 
> like KEX_REKEY_TIMEOUT, AUTH_TIMEOUT, keepalive_secs. If there is a timeout 
> occurs, the "update_timeout" function returns a negative value, then 
> "select_timeout" modifies it to ZREO by this:
> /* clamp negative timeouts to zero - event has already triggered */
>  return MAX(timeout, 0);
>if "select_timeout" returns ZERO, the next "select" call (in 
> "session_loop") will return immediately. Then it will check timeout events by 
> this:
> /* check for auth timeout, rekeying required etc */
>checktimeouts();
>in the function " checktimeouts ", when it find the timeout is reached or 
> to many data has been sent, it will send a SSH_MSG_KEXINIT message to peer. 
> Normally this message will trigger a new KEY-EXCHANGE. However, when there is 
> a network problem that the peer can't receive the message , this bug occurs: 
> the timestamp ses.kexstate.lastkextime is only updated by calling  
> "switch_keys"-->" kexinitialise ", unfortunately this calling sequence is 
> driven by ssh-messages, either SSH_MSG_KEXDH_INIT or SSH_MSG_NEWKEYS. When 
> there is no ssh-message received , the child dropbear process enters 
> dead-loop "select" with ZERO-timeout parameter caused by KEX_REKEY_TIMEOUT.
> >  So there is a very simple way to reproduce this bug: first define the 
> > KEX_REKEY_TIMEOUT as small as possible( I set it to 8 seconds), then start 
> > a ssh-session , the child dropbear process is forked. then plug out the 
> > network wire, after 8 seconds the child dropbear thread will occupy 100% 
> > CPU. Could you kindly check it? thanks.
> 
> Best regards
> 

Re: a bug detected in dropbear v071

[Matt Johnston]

Hi,

I think this problem should be solved by the commit
https://secure.ucc.asn.au/hg/dropbear/rev/432b0a030fd6 


Thank you for the detailed report.

Cheers,
Matt


> On Wed 20/4/2016, at 2:44 pm, ZHANG Hui P  
> wrote:
> 
> Hi:
>  I am a software engineer of Alcatel-Lucent. In our product we use 
> dropbear v071 under the OS: Linux version 3.4.24. At most time it works 
> perfectly, but recently we got a problem: sometimes a child-process of 
> dropbear occupied nearly 100% CPU (we use ARM1176, single-core). After I 
> investigated it ,I found it is cause by a misuse of KEX_REKEY_TIMEOUT.
> KEX_REKEY_TIMEOUT is defined as 8hours. that means when a session lasts more 
> than 8 hours, the server and client will re-exchange their KEY for security 
> reason. The timestamp of last-time KEY-EXCHANGED is recorded in variable 
> "ses.kexstate.lastkextime". 
>  The child dropbear process decides the "timeout" parameter of "select" 
> function by calling "select_timeout". we can see it checks the timeout-events 
> like KEX_REKEY_TIMEOUT, AUTH_TIMEOUT, keepalive_secs. If there is a timeout 
> occurs, the "update_timeout" function returns a negative value, then 
> "select_timeout" modifies it to ZREO by this:
> /* clamp negative timeouts to zero - event has already triggered */
>  return MAX(timeout, 0);
>if "select_timeout" returns ZERO, the next "select" call (in 
> "session_loop") will return immediately. Then it will check timeout events by 
> this:
> /* check for auth timeout, rekeying required etc */
>checktimeouts();
>in the function " checktimeouts ", when it find the timeout is reached or 
> to many data has been sent, it will send a SSH_MSG_KEXINIT message to peer. 
> Normally this message will trigger a new KEY-EXCHANGE. However, when there is 
> a network problem that the peer can't receive the message , this bug occurs: 
> the timestamp ses.kexstate.lastkextime is only updated by calling  
> "switch_keys"-->" kexinitialise ", unfortunately this calling sequence is 
> driven by ssh-messages, either SSH_MSG_KEXDH_INIT or SSH_MSG_NEWKEYS. When 
> there is no ssh-message received , the child dropbear process enters 
> dead-loop "select" with ZERO-timeout parameter caused by KEX_REKEY_TIMEOUT.
> >  So there is a very simple way to reproduce this bug: first define the 
> > KEX_REKEY_TIMEOUT as small as possible( I set it to 8 seconds), then start 
> > a ssh-session , the child dropbear process is forked. then plug out the 
> > network wire, after 8 seconds the child dropbear thread will occupy 100% 
> > CPU. Could you kindly check it? thanks.
>  
> Best regards

Re: Can't SSH from Windows

[Matt Johnston]

Hi Rob,

It sounds like LEAF have disabled the group14-sha1 algorithm which was the only 
compatible algorithm. Sha1 isn't too insecure in this context, at least at 
present.

Matt

On 29 April 2016 3:06:46 am AWST, Rob Ogle  wrote:
>I just installed the latest version of uclibc from
>leaf.sourceforge.net. 
>
>I can ssh into the leaf box just fine from another linux box, but I
>can't
>get any windows ssh client to connect. I have tried multiple clients
>from
>multiple machines. 
>
> 
>
>The error message from puTTY says:  Couldn't agree a key exchange
>algorithm
>(available: curve25519-sha...@libssh.org
> , ecdh-sha2-nistp521,
>ecdh-sha1-nistp384, ecdh-sha2-nistp256, kexgue...@matt.uccasn.au)
>
> 
>
>The error message from Dameware SSH Client says: connection error:
>Could not
>negotiate diffie-hellman-group1-sha1.
>
> 
>
>Putty version 0.67

Re: a bug detected in dropbear v071

[Matt Johnston]

Hi Thomas,

Hui's analysis look right, I'll try and test it myself later this week. (Sorry, 
replied privately).

Cheers,
Matt

On 25 April 2016 11:15:58 pm AWST, Thomas De Schampheleire 
 wrote:
>ZHANG Hui P  alcatel-sbell.com.cn> writes:
>
>> 
>> 
>> 
>> Hi:
>>  I am a software engineer of Alcatel-Lucent. In our product
>we use
>dropbear v071 under the OS: Linux version 3.4.24. At most time it works
>perfectly, but recently we got a problem: sometimes a child-process of
>>  dropbear occupied nearly 100% CPU (we use ARM1176, single-core).
>After I
>investigated it ,I found it is cause by a misuse of KEX_REKEY_TIMEOUT.
>> KEX_REKEY_TIMEOUT is defined as 8hours. that means when a session
>lasts
>more than 8 hours, the server and client will re-exchange their KEY for
>security reason. The timestamp of last-time
>>  KEY-EXCHANGED is recorded in variable "ses.kexstate.lastkextime". 
>>  The child dropbear process decides the "timeout" parameter of
>"select"
>function by calling "select_timeout". we can see it checks the
>timeout-events like KEX_REKEY_TIMEOUT, AUTH_TIMEOUT,
>>  keepalive_secs. If there is a timeout occurs, the "update_timeout"
>function returns a negative value, then "select_timeout" modifies it to
>ZREO
>by this:
>> /* clamp negative timeouts to zero - event has already triggered */
>>  return MAX(timeout, 0);
>>    if "select_timeout" returns ZERO, the next "select" call (in
>"session_loop") will return immediately. Then it will check timeout
>events
>by this:
>> /* check for auth timeout, rekeying required etc */
>>    checktimeouts();
>>    in the function " checktimeouts ", when it find the timeout is
>reached
>or to many data has been sent, it will send a SSH_MSG_KEXINIT message
>to
>peer. Normally this message will trigger a new KEY-EXCHANGE. However,
>>  when there is a network problem that the peer can't receive the
>message ,
>this bug occurs: the timestamp ses.kexstate.lastkextime is only updated
>by
>calling  "switch_keys"-->" kexinitialise ", unfortunately this calling
>sequence is driven by ssh-messages,
>>  either SSH_MSG_KEXDH_INIT or SSH_MSG_NEWKEYS. When there is no
>ssh-message received , the child dropbear process enters dead-loop
>"select"
>with ZERO-timeout parameter caused by KEX_REKEY_TIMEOUT.
>> >  So there is a very simple way to reproduce this bug: first
>define
>the KEX_REKEY_TIMEOUT as small as possible( I set it to 8 seconds),
>then
>start a ssh-session , the child dropbear process is forked. then plug
>>  out the network wire, after 8 seconds the child dropbear thread will
>occupy 100% CPU. Could you kindly check it? thanks.
>>  
>
>Any feedback regarding this reported issue?
>
>Thanks,
>Thomas

Re: dropbear with external libtommath/libtomcrypt

[Matt Johnston]

Hi Peter,

External libraries are fine - Debian has used them for a
while. The only security-important change is
https://secure.ucc.asn.au/hg/dropbear/rev/a55b97f5a485 which
I assume is already in buildroot.

I've made a few small changes to clear memory or avoid
memory allocations - those could go upstream to libtom at
some point.

Cheers,
Matt

On Sat, Apr 16, 2016 at 11:29:02AM +0200, Peter Korsgaard wrote:
> Hi,
> 
> We've recently received patches in Buildroot (http://buildroot.org) to
> build libtommath/libtomcrypt (statically) seperately and link dropbear
> against those instead of the bundled copies.
> 
> In general we prefer to use system libraries instead of bundled versions
> whenever possible, but as dropbear is security sensitive I wanted to
> check before making the change.
> 
> I see that the bundled copies contain local changes. What is the
> pro/cons of using the bundled versions vs external?
> 
> -- 
> Bye, Peter Korsgaard

Dropbear 2016.72

[Matt Johnston]

Hi all,

Dropbear SSH 2016.72 is released. This has a single change, a
security fix. If X11 forwarding is enabled a user could
bypass any "command=" restrictions in authorized_keys and run
any command as their own user (or perform other operations
allowed by the "xauth" binary such as writing files). It
does not affect systems where command= restrictions are not
used.

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

The patch is https://secure.ucc.asn.au/hg/dropbear/rev/a3e8389e01ff

Cheers,
Matt


2016.72 - 9 March 2016

- Validate X11 forwarding input. Could allow bypass of authorized_keys command= 
restrictions,
  found by github.com/tintinweb. Thanks to Damien Miller for a patch.

Re: Single-address space, no processes?

[Matt Johnston]

Hi Sebastian,

I'd be interesting in merging changes upstream, I think it would be of interest 
to a few people. It would need to be under a similar license to the current 
code.

Currently the session state is kept in ses, svr_ses, and cli_ses global 
variables (all structs defined in session.h). Changing eg ses.payload to 
ses->payload throughout the codebase is fairly straighforward. It mightn't be 
necessary to pass pointers around everywhere if ses/svr_ses/cli_ses could be 
thread-local pointer variables - how widely supported is thread-local storage? 

Some of the state in ses might need to move to a process-wide state structure - 
"childpids" for example. That mightn't be relevant for your situation.

There is also some recent work to use Dropbear as a Perl module - that might 
have some useful changes in terms of avoiding Unix user authentication etc. 
https://github.com/atrodo/Net-Dropbear/tree/master/dropbear

Cheers,
Matt


> On Mon 4/1/2016, at 9:18 pm, Sebastian Huber 
>  wrote:
> 
> Hello,
> 
> thanks for the hints.
> 
> So, running dropbear in a  single-address space and no process environment 
> seems to be doable. However, it requires probably some possible large code 
> modifications, e.g.
> 
> * encapsulate the global state in a context structure and pass a pointer to 
> this structure around,
> * add cleanup code instead of exit().
> 
> If I work on this, would it be possible to upstream these changes?
> 
> -- 
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>