[PATCH] Fix compile when disabling SHA-1

[Peter Krefting]

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;
}
--
2.44.0

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

[Peter Krefting]

2018-11-10 12:53 skrev W. Michael Petullo:

I read the reference you provided, but I am not yet convinced.  Is it 
not
true that pipelines by default produce the exit code from the 
right-most

program in the pipeline?


You're right and I am wrong. The exit code is the right-most command.

Sorry for the confusion.

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

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

[Peter Krefting]

2018-11-09 17:52 skrev W. Michael Petullo:


Here is a more practical example which demonstrates the problem:

$ echo false | dbclient -T r...@host.example.com
$ echo $?
0


That is because $? contains the exit status of the left-most command 
(echo), not the pipe. If you are using a bash shell, you need to use 
PIPESTATUS to find it, read more at: 
https://unix.stackexchange.com/a/73180


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

[SUSPECTED SPAM]Re: Dropbear 2018.76

[Peter Krefting]

Matt Johnston:

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



This patch does indeed fix the problem. Thank you!

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

Re: Dropbear 2018.76

[Peter Krefting]

Matt Johnston:


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


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



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


I have included the output below


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


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



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

/* Disable inetd mode */
#define INETD_MODE 0

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

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

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

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

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

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

#define DROPBEAR_SFTPSERVER 0

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

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

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

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

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

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

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

Re: [PATCH] dropbear: support out-of-tree builds

[Peter Krefting]

Hi!

Thank you for the patch. I think this should be solved in the hg 
tree but it didn't make it into the 2016.74 release.


It does indeed. I didn't notice it when looking through the revision 
history. Sorry for the duplicate.


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

Port forwarding for certain users only

[Peter Krefting]

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: Dropbear 2015.70 fixes password authentication

[Peter Krefting]

Matt Johnston:

Dropbear 2015.70 released now fixes password server authentication 
on Linux.


This version does indeed fix the issue I was seeing. Thank you for the 
swift bug fix!


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

2015.69 and password authentication

[Peter Krefting]

Hi!

Upgrading from 2015.68 to 2015.69 on the embedded platform at $DAYJOB, 
password authentication does no longer work. This seems to be related 
to a newly added test for crypt() in the configure script, which fails 
to find it and thus disables password authentication.


Has anyone else been bit by this, and is there a better workaround 
than to edit options.h to unconditionally enable 
ENABLE_SVR_PASSWORD_AUTH (removing the #ifdef HAVE_CRYPT test, which 
works fine).


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