From dario.piantanida at gmail.com  Fri Oct  3 16:43:44 2014
From: dario.piantanida at gmail.com (Dario Piantanida)
Date: Fri, 3 Oct 2014 10:43:44 +0200
Subject: Help with secure configuration
Message-ID: <CADX3hRFBGJ3bxyUhvR3JR_Qtb_Lz29_nFEFzOHq01zMzemuHgQ@mail.gmail.com>

Hello, I'm a happy dropbear user for my LG ARM Debian 6 NAS.

To allow me to access it from internet, I exposed NAS port 22 on my home
router.
Yesterday I saw a nice Chinese gentleman trying and trying to login as root
on my NAS, so I would like to strengthen the configuration.

First I would like to know if it is possibile to ban an IP after too many
failed attempts.

Second I would like to allow password login from within the LAN and require
certificate login from outside: is this possible?

Last thing: I test modifications to my NAS on a ARM QEMU VM with Debian 6
installed; when I try to put latest dropbear there (sudo dpkg -i), it says
(I can't cut&paste):

Restarting dropbear SSH server: ipv6: Unknown symbol udp_push_pending_frames
invoke-rc.d: initscript dropbear (--install):
   the subprocess for old post-installation script returned error state 1
Errors isntalling dropbear

and it is not there.
Does anybody know how to fix this?

Thank you very much!
Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141003/3ba93c24/attachment.htm 

From hans at atbas.org  Sat Oct  4 20:44:22 2014
From: hans at atbas.org (Hans Harder)
Date: Sat, 4 Oct 2014 14:44:22 +0200
Subject: [Patch] Restricting access to certain ip numbers.
Message-ID: <CAKzsc6fnj0c13T9qLBhQEmpWiFCpHsXQuZpi561NQA8URxOc9w@mail.gmail.com>

Perhaps not something to have default in dropbear, put perhaps of interest
for someone...

In order to restrict  access from certain ip addresses only, you can, with
this patch, start a dropbear with option -S
This will only allow password logins if a corresponding file
/etc/dropbear/ip_<ipnumber>_any.allow exists.

It will also check for /etc/dropbear/ip_<ipnumber>_<username>.allow for
granting access to specific usernames only

If you start dropbear with -S -S  it will also use this restriction for
pubkey validation

Example:
# blocking password and pubkey from unknown locations, using a valid pubkey
root at core ~# ./dropbear -S -S  -F  -p 2022
[24472] Oct 04 12:30:21 Not backgrounding
[24473] Oct 04 12:30:40 Child connection from ::ffff:192.168.1.10:49799
[24473] Oct 04 12:30:40 Exit before auth (user 'root', 0 fails): Remote
address ::ffff:192.168.1.10:49799 is not allowed to connect with public key
or password

# blocking password from unknown locations, using a valid pubkey
root at core ~# ./dropbear -S   -F  -p 2022
[24486] Oct 04 12:30:55 Not backgrounding
[24487] Oct 04 12:31:10 Child connection from ::ffff:192.168.1.10:49801
[24487] Oct 04 12:31:11 Pubkey auth succeeded for 'root' with key md5
14:07:9a:1d:d9:64:45:db:88:d8:78:62:45:1e:88:21 from ::ffff:
192.168.1.10:49801

# blocking password from unknown locations, using a valid password
root at core ~# ./dropbear -S   -F  -p 2022
[24551] Oct 04 12:31:25 Not backgrounding
[24552] Oct 04 12:32:06 Child connection from ::ffff:192.168.1.10:49802
[24552] Oct 04 12:32:09 IP access denied : file
/etc/dropbear/ip_192.168.1.10_root.allow not found
[24552] Oct 04 12:32:09 IP access denied : file
/etc/dropbear/ip_192.168.1.10_any.allow not found
[24552] Oct 04 12:32:09 Exit before auth (user 'root', 0 fails): Remote
address ::ffff:192.168.1.10:49802 is not allowed to connect with password

# grant  connections for root from 192.168.1.10, using a valid publickey
root at core ~# touch /etc/dropbear/ip_192.168.1.10_root.allow
root at core ~# ./dropbear -S -S  -F  -p 2022
[24578] Oct 04 12:33:02 Not backgrounding
[24579] Oct 04 12:33:20 Child connection from ::ffff:192.168.1.10:49803
[24579] Oct 04 12:33:20 IP access allowed : file
/etc/dropbear/ip_192.168.1.10_root.allow found
[24579] Oct 04 12:33:20 Pubkey auth succeeded for 'root' with key md5
14:07:9a:1d:d9:64:45:db:88:d8:78:62:45:1e:88:21 from ::ffff:
192.168.1.10:49803


Have fun with it...

Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141004/136f0666/attachment.htm 
-------------- next part --------------
--- ../dropbear-2014.65/options.h	2014-09-11 02:37:28.000000000 -0600
+++ options.h	2014-10-04 01:28:55.000000000 -0600
@@ -20,6 +20,10 @@
 #endif
 
 /* Default hostkey paths - these can be specified on the command line */
+#ifndef CONFIG_DIRECTORY
+#define CONFIG_DIRECTORY "/etc/dropbear"
+#endif
+/* Default hostkey paths - these can be specified on the command line */
 #ifndef DSS_PRIV_FILENAME
 #define DSS_PRIV_FILENAME "/etc/dropbear/dropbear_dss_host_key"
 #endif
--- ../dropbear-2014.65/runopts.h	2014-08-08 07:40:47.000000000 -0600
+++ runopts.h	2014-10-04 01:25:22.000000000 -0600
@@ -87,6 +87,7 @@ typedef struct svr_runopts {
 
 	int norootlogin;
 
+	int restrictlogins;
 	int noauthpass;
 	int norootpass;
 	int allowblankpass;
--- ../dropbear-2014.65/svr-runopts.c	2014-08-08 07:40:47.000000000 -0600
+++ svr-runopts.c	2014-10-04 02:58:05.000000000 -0600
@@ -68,6 +68,7 @@ static void printhelp(const char * progn
 					"-m		Don't display the motd on login\n"
 #endif
 					"-w		Disallow root logins\n"
+					"-S		Enable logins from restricted addresses\n"
 #if defined(ENABLE_SVR_PASSWORD_AUTH) || defined(ENABLE_SVR_PAM_AUTH)
 					"-s		Disable password logins\n"
 					"-g		Disable password logins for root\n"
@@ -127,6 +128,7 @@ void svr_getopts(int argc, char ** argv)
 	svr_opts.forkbg = 1;
 	svr_opts.norootlogin = 0;
 	svr_opts.noauthpass = 0;
+	svr_opts.restrictlogins = 0;
 	svr_opts.norootpass = 0;
 	svr_opts.allowblankpass = 0;
 	svr_opts.inetdmode = 0;
@@ -244,6 +246,9 @@ void svr_getopts(int argc, char ** argv)
 				case 'I':
 					next = &idle_timeout_arg;
 					break;
+				case 'S':
+					svr_opts.restrictlogins++;
+					break;
 #if defined(ENABLE_SVR_PASSWORD_AUTH) || defined(ENABLE_SVR_PAM_AUTH)
 				case 's':
 					svr_opts.noauthpass = 1;
--- ../dropbear-2014.65/svr-auth.c	2014-08-08 07:40:47.000000000 -0600
+++ svr-auth.c	2014-10-04 05:35:21.000000000 -0600
@@ -79,6 +79,46 @@ static void authclear() {
 	
 }
 
+/* check if a file  ip_<ipnumber>_<user>.allow or ip_<ipnumber>.allow is found
+ * which determines if access is allowed or not. */
+static int restrictlogin_valid(char *usernm, int log)
+{
+	char address[65], *ptr, fn[256];
+	
+	/* get remote ip:port address IPv4 or IPv6 */
+	if (strncmp(svr_ses.addrstring,"::ffff:",7)==0) {
+		strlcpy(address,&svr_ses.addrstring[7],sizeof(address));
+	} else {
+		strlcpy(address,svr_ses.addrstring,sizeof(address));
+	}
+	ptr=strrchr(address,':');
+	if (ptr!=0) {
+		/* remove the port part, leaving the ip only in the address */
+		*ptr='\0'; 
+		/* change all remaining : characters into . characters (IPv6) */
+		while ( (ptr=strchr(address,':')) !=0 ) {
+			*ptr='.';
+		}
+        	/* test if user from ip is allowed */
+		snprintf(fn,sizeof(fn),"%s/ip_%s_%s.allow",CONFIG_DIRECTORY,address,usernm);
+		if (access(fn,F_OK)==0) {
+			dropbear_log(LOG_INFO, "IP access allowed : file %s found",fn);
+			return(1);
+		} else if (log) {
+			dropbear_log(LOG_INFO, "IP access denied : file %s not found",fn);
+		}
+        	/* test if any user from ip is allowed */
+		snprintf(fn,sizeof(fn),"%s/ip_%s_any.allow",CONFIG_DIRECTORY,address);
+		if (access(fn,F_OK)==0) {
+			dropbear_log(LOG_INFO, "IP access allowed : file %s found",fn);
+			return(1);
+		} else if (log) {
+			dropbear_log(LOG_INFO, "IP access denied : file %s not found",fn);
+		}
+	}
+	return(0);
+}
+
 /* Send a banner message if specified to the client. The client might
  * ignore this, but possibly serves as a legal "no trespassing" sign */
 void send_msg_userauth_banner(buffer *banner) {
@@ -148,6 +188,10 @@ void recv_msg_userauth_request() {
 			strncmp(methodname, AUTH_METHOD_NONE,
 				AUTH_METHOD_NONE_LEN) == 0) {
 		TRACE(("recv_msg_userauth_request: 'none' request"))
+		if (svr_opts.allowblankpass && svr_opts.restrictlogins!=0 && restrictlogin_valid(username,1)==0) {
+    		        dropbear_log(LOG_INFO, "IP access denied for blank password" );
+			valid_user = 0;
+		}
 		if (valid_user
 				&& svr_opts.allowblankpass
 				&& !svr_opts.noauthpass
@@ -176,6 +220,13 @@ void recv_msg_userauth_request() {
 		if (methodlen == AUTH_METHOD_PASSWORD_LEN &&
 				strncmp(methodname, AUTH_METHOD_PASSWORD,
 					AUTH_METHOD_PASSWORD_LEN) == 0) {
+			if (svr_opts.restrictlogins!=0 && restrictlogin_valid(username,1)==0 ) {
+				/* do not allow retries */
+				m_free(username);
+				m_free(servicename);
+				m_free(methodname);
+				dropbear_exit("Remote address %s is not allowed to connect with password",svr_ses.addrstring);
+			}
 			if (valid_user) {
 				svr_auth_password();
 				goto out;
@@ -191,6 +242,13 @@ void recv_msg_userauth_request() {
 		if (methodlen == AUTH_METHOD_PASSWORD_LEN &&
 				strncmp(methodname, AUTH_METHOD_PASSWORD,
 					AUTH_METHOD_PASSWORD_LEN) == 0) {
+			if (valid_user && svr_opts.restrictlogins!=0 && restrictlogin_valid(username,1)==0 ) {
+				/* do not allow retries */
+				m_free(username);
+				m_free(servicename);
+				m_free(methodname);
+				dropbear_exit("Remote address %s is not allowed to connect with pam password",svr_ses.addrstring);
+			}
 			if (valid_user) {
 				svr_auth_pam();
 				goto out;
@@ -204,6 +262,13 @@ void recv_msg_userauth_request() {
 	if (methodlen == AUTH_METHOD_PUBKEY_LEN &&
 			strncmp(methodname, AUTH_METHOD_PUBKEY,
 				AUTH_METHOD_PUBKEY_LEN) == 0) {
+		if (svr_opts.restrictlogins==2 && restrictlogin_valid(username,0)==0) {
+			/* if pubkey is not allowed , so is password not... so break off connection */
+			m_free(username);
+			m_free(servicename);
+			m_free(methodname);
+			dropbear_exit("Remote address %s is not allowed to connect with public key or password",svr_ses.addrstring);
+		}
 		if (valid_user) {
 			svr_auth_pubkey();
 		} else {

From bth at kamstrup.dk  Mon Oct  6 16:04:03 2014
From: bth at kamstrup.dk (Bruno Thomsen)
Date: Mon, 6 Oct 2014 08:04:03 +0000
Subject: [Patch] Restricting access to certain ip numbers.
In-Reply-To: <CAKzsc6fnj0c13T9qLBhQEmpWiFCpHsXQuZpi561NQA8URxOc9w@mail.gmail.com>
References: <CAKzsc6fnj0c13T9qLBhQEmpWiFCpHsXQuZpi561NQA8URxOc9w@mail.gmail.com>
Message-ID: <915054555B5659448ACF8A70E114824D015BEA28B1@Exchange2010.kamstrup.dk>

> Subject: [Patch] Restricting access to certain ip numbers.
>
> Perhaps not something to have default in dropbear, put perhaps of interest for someone...?
>
> In order to restrict ?access from certain ip addresses only, you can, with this patch, start a dropbear with option -S
> This will only allow password logins if a corresponding file /etc/dropbear/ip_<ipnumber>_any.allow exists.
>
> It will also check for /etc/dropbear/ip_<ipnumber>_<username>.allow for granting access to specific usernames only
> 
> If you start dropbear with -S -S ?it will also use this restriction for pubkey validation

Most of this functionality sounds like something iptables can do.
I don't really see a point in adding firewall capabilities to a lightweight ssh implementation.
But thanks for sharing the patch :)



Venlig hilsen / Best regards


Bruno Thomsen
Development engineer
Technology

Kamstrup A/S
Industrivej 28
DK-8660 Skanderborg
Tel: +45 89 93 10 00
Fax: +45 89 93 10 01
Dir: +45 89 93 13 94
E-mail: bth at kamstrup.dk
Web: www.kamstrup.dk

From rparimi at gmail.com  Tue Oct  7 10:57:55 2014
From: rparimi at gmail.com (Ravi Parimi)
Date: Mon, 6 Oct 2014 19:57:55 -0700
Subject: dbclient fails to honor -o options
Message-ID: <CAN0KgYeuQ327zcQQ1X2S3ufzY1JwhJiwdmsCxGquoNC4Zht8aA@mail.gmail.com>

Hello Dropbear-er's

I'm running Dropbear v2014.64 on embedded linux and noticed that
dbclient doesn't recognize -o options that work with the normal ssh
client. For e.g:

loader# scp -o StrictHostKeyChecking=no -o
UserKnownHostsFile=/dev/null 10.11.0.20:/storage/file.txt /tmp/
WARNING: Ignoring unknown argument '-oStrictHostKeyChecking=no'
WARNING: Ignoring unknown argument '-oUserKnownHostsFile=/dev/null'

Host '10.11.0.20' is not in the trusted hosts file.
(ecdsa-sha2-nistp256 fingerprint md5
55:72:5e:c5:57:25:a9:c6:3a:37:a5:a9:6e:12:95:a1)
Do you want to continue connecting? (y/n)

The usage string, however, shows that -o is supported.

loader# scp -v
usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
           [-l limit] [-o ssh_option] [-P port] [-S program]
           [[user@]host1:]file1 [...] [[user@]host2:]file2

Next, I created a sample ssh_config file:

loader# cat /.ssh/config
StrictHostKeyChecking no
UserKnownHostsFile /dev/null

And asked scp to read it, but that doesn't work:

loader# scp -F /.ssh/config  10.11.0.20:/storage/file.txt /tmp/
Dropbear v2014.64

Has anyone had luck with getting either of the above options to work?

thanks

From pratiksingh86 at gmail.com  Wed Oct  8 19:54:29 2014
From: pratiksingh86 at gmail.com (pratik singh)
Date: Wed, 8 Oct 2014 17:24:29 +0530
Subject: Write error : dbclient
In-Reply-To: <20140928135103.GB32743@ucc.gu.uwa.edu.au>
References: <CACQLUqYzFoTqC45CMSBPTin569hFHHX2CR8jkNOy8f0DhWm9jA@mail.gmail.com>
	<20140924143214.GT8675@ucc.gu.uwa.edu.au>
	<CACQLUqbaN6X+dhm-1vSjyBbgc==K_zWDuhNnHu79mCYCaH7O-A@mail.gmail.com>
	<20140928135103.GB32743@ucc.gu.uwa.edu.au>
Message-ID: <CACQLUqa1uJmyJ-OR0wjzOGb4O8qJZBpJYefNAZ_UOyTC_p5JRg@mail.gmail.com>

Hi Matt,

Thanks for the prompt response.

Yes, mp_exptmod() call in kexdh_comb_key() is taking around 60 seconds.

Adding "#define MP_LOW_MEM 1" to options.h then "make clean" and rebuild
does not help the situation. I am not sure about data cache type. How to
check it?

Please share your inputs on this.

Thanks
Pratik

On Sun, Sep 28, 2014 at 7:21 PM, Matt Johnston <matt at ucc.asn.au> wrote:

> Hi Pratik,
>
> Yes, mp_exptmod() the problematic part. Without performing
> the "verify" SSH won't have any security against network
> attacks - certainly not advisable.
>
> There's also a mp_exptmod() call in kexdh_comb_key()  which
> creates the session key - is that call slow too?
>
> Does adding "#define MP_LOW_MEM 1" to options.h then "make
> clean" and rebuild help the situation? Do you know what kind
> of data cache the device has?
>
> Cheers,
> Matt
>
>
> On Fri, Sep 26, 2014 at 12:50:26PM +0530, pratik singh wrote:
> > Hi Matt,
> >
> > Thanks for the reply.
> >
> > Things are working fine when I commented function "buf_dss_verify".
> > Actually majoriy of the time taken was in mp_exptmod() routine with each
> > call takes around 25 secs and because of this only openssh server is
> > getting timeout.
> > As per your suggestion one of the solution is to merge tofastmath library
> > but just for one function merging whole library is a hectic work though.
> > Based on experiments i have couple of questions:
> > 1)  dropbear ssh client is working by commenting out the function
> > "buf_dss_verify". Is it ok for me to take this as workaround and continue
> > or this can cause any serious problem further?
> > 2) Is there any other solution to improve the speed of calculations in
> > function "mp_exptmod()" only?
> >
> > Appreciate your response.
> >
> > Thanks
> > Pratik
> >
> > On Wed, Sep 24, 2014 at 8:02 PM, Matt Johnston <matt at ucc.asn.au> wrote:
> >
> > > Hi Pratik,
> > >
> > > I'm assuming that it is the session timeout that's causing
> > > the disconnection.  The log on the OpenSSH server should
> > > confirm that.
> > >
> > > I think the only real solution would be to improve the speed
> > > of libtommath on that device. Running a profiler to
> > > determine the slowest parts would be the first step. I don't
> > > know much about the device itself though it seems libtommath
> > > performs quite badly - OpenSSL is generally faster. Looking
> > > at the difference in its maths operations might help. It's
> > > non-trivial work though.
> > >
> > > Cheers,
> > > Matt
> > >
> > >
> > > On Wed, Sep 24, 2014 at 02:12:41PM +0530, pratik singh wrote:
> > > > Hi,
> > > >
> > > > I am using Dropbear 0.48 with uClinux-dist. Currently dropbear
> server is
> > > > working fine but while trying to run dbclient it throws write error.
> Some
> > > > of the traces are:
> > > >
> > > > TRACE: leave process_packet
> > > > TRACE: enter cli_sessionloop
> > > > TRACE: enter send_msg_service_request: servicename='ssh-userauth'
> > > > TRACE: enter encrypt_packet()
> > > > TRACE: encrypt_packet type is 5
> > > >
> > > > TRACE: enter writemac
> > > > TRACE: leave writemac
> > > > TRACE: enter enqueue
> > > > TRACE: leave enqueue
> > > > TRACE: leave encrypt_packet()
> > > > TRACE: leave send_msg_service_request
> > > > TRACE: leave cli_sessionloop: sent userauth service req
> > > > TRACE: enter write_packet
> > > >
> > > > TRACE: enter cli_tty_cleanup
> > > > TRACE: leave cli_tty_cleanup: not in raw mode
> > > > TRACE: enter session_cleanup
> > > > TRACE: enter chancleanup
> > > > TRACE: leave chancleanup
> > > > TRACE: leave session_cleanup
> > > > dbclient: connection to pratik at 10.10.10.1:22 exited: error writing
> > > >
> > >
> --------------------------------------------------------------------------------------------------------------
> > > >
> > > > I have tried the following:
> > > > 1) Run dbclient with -K option but still getting the same write error
> > > > 2) Run dbclient with -y option but still getting the same write error
> > > >
> > > > On further debugging I have found that this write comes because
> server
> > > (in
> > > > this case Openssh) is getting timeout.
> > > >
> > > > I am running microblaze processor at about 60mhz with hardware
> > > > multiplier, divider enabled.
> > > >
> > > >
> > > > From the wireshark capture i have seen that server is sending "FIN"
> > > > packet. also server is sending the 2 ssh packets in one reply packet.
> > > > Do not know the reason of this behavior.
> > > >
> > > >
> > > > I am facing this problem for connection between dbclient <---->
> Openssh.
> > > >
> > > >
> > > > Please help as m stuck to this problem since very long. Appreciate
> your
> > > reply.
> > > >
> > > >
> > > > Attached the pcap file for your reference. apply
> > > "ip.addr==10.216.114.137"
> > > > filter in pcap file. IP address is client having dbclient and other
> is
> > > > server having openssh.
> > > >
> > > >
> > > > --
> > > > Thanks & Regards
> > > > Pratik Singh
> > >
> > >
> > >
> >
> >
> > --
> > Thanks & Regards
> > Pratik Singh
>



-- 
Thanks & Regards
Pratik Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141008/2fa13598/attachment.htm 

From hans at atbas.org  Wed Oct  8 20:14:39 2014
From: hans at atbas.org (Hans Harder)
Date: Wed, 8 Oct 2014 14:14:39 +0200
Subject: dbclient fails to honor -o options
Message-ID: <CAKzsc6c7Pcza8WgBE7+77Mm4Kp8Yq6JqoSbtPxWD-CPoHvNF6w@mail.gmail.com>

you can use scp with -y -y option.
This is passed to dbclient with the underneath patch for scp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141008/f234f237/attachment.htm 
-------------- next part --------------
--- a/scp.c       2014-10-08 05:34:21.000000000 -0600
+++ b/scp.c       2014-10-08 05:35:38.000000000 -0600
@@ -324,7 +324,7 @@ main(int argc, char **argv)
        addargs(&args, "%s", ssh_program);

        fflag = tflag = 0;
-       while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:")) != -1)
+       while ((ch = getopt(argc, argv, "dfl:prtvBCyc:i:P:q1246S:o:F:")) != -1)
                switch (ch) {
                /* User-visible flags. */
                case '1':
@@ -332,6 +332,7 @@ main(int argc, char **argv)
                case '4':
                case '6':
                case 'C':
+               case 'y':
                        addargs(&args, "-%c", ch);
                        break;
                case 'o':
@@ -1145,7 +1146,7 @@ void
 usage(void)
 {
        (void) fprintf(stderr,
-           "usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]\n"
+           "usage: scp [-1246BCpqrvy] [-c cipher] [-F ssh_config] [-i identity_file]\n"
            "           [-l limit] [-o ssh_option] [-P port] [-S program]\n"
            "           [[user@]host1:]file1 [...] [[user@]host2:]file2\n");
        exit(1);

From hans at atbas.org  Thu Oct  9 18:58:27 2014
From: hans at atbas.org (Hans Harder)
Date: Thu, 9 Oct 2014 12:58:27 +0200
Subject: X11 forwarding in dbclient
Message-ID: <CAKzsc6c2SP1kQrr2t3S8_EFj-AWyFzwrgxRSmYus-dWHdaNk4g@mail.gmail.com>

How difficult is it to get X11 forwarding in the dbclient.

currently I only have it working when using openssh with -X option.
But because of multihop (more than 2 hops)  I have to use dbclient, but it
doesn't support X11 forwarding.

thx

Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141009/969524e0/attachment.htm 

From jedevnull at gmail.com  Sat Oct 11 04:50:22 2014
From: jedevnull at gmail.com (Jed Evnull)
Date: Fri, 10 Oct 2014 16:50:22 -0400
Subject: android
Message-ID: <CAFo83mF5AGTwyyrbzB_zO9hkurK4pTuAP4Sz0XiV25KPc75LGg@mail.gmail.com>

Hello,

I'm compiling dropbear v2014.65 with the sourcery toolchain using:

./configure --host=arm-none-linux-gnueabi \
--disable-zlib \
--disable-largefile \
--disable-loginfunc \
--disable-shadow \
--disable-utmp \
--disable-utmpx \
--disable-wtmp \
--disable-wtmpx \
--disable-pututline \
--disable-pututxline \
--disable-lastlog \
CC=arm-none-linux-gnueabi-gcc

The compile goes fine, but as expected, login via password fails for
android.  I no longer see an option to supply a password at dropbear start
with -C.  Has this been deprecated? Is there a patch?

Thanks for any help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141010/ca56d954/attachment.htm 

From post at lespocky.de  Sat Oct 18 16:09:28 2014
From: post at lespocky.de (Alexander Dahl)
Date: Sat, 18 Oct 2014 10:09:28 +0200
Subject: use dropbear ssh client over specific interface?
Message-ID: <54422038.20303@lespocky.de>

Hei hei,

say I have a machine with multiple network interfaces, and maybe policy
based routing. Is it possible to let the ssh client use a specific
network interface for an outgoing connection? I could not tell from `man
8 dropbear` or `man 1 dbclient`.

Greets
Alex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141018/2d6abd9f/attachment.sig 

From matt at ucc.asn.au  Sat Oct 18 16:20:57 2014
From: matt at ucc.asn.au (Matt Johnston)
Date: Sat, 18 Oct 2014 16:20:57 +0800
Subject: use dropbear ssh client over specific interface?
In-Reply-To: <54422038.20303@lespocky.de>
References: <54422038.20303@lespocky.de>
Message-ID: <91F38263-FC63-4876-BA88-3E3723EE18A3@ucc.asn.au>

> On Sat 18/10/2014, at 4:09 pm, Alexander Dahl <post at lespocky.de> wrote:
> 
> say I have a machine with multiple network interfaces, and maybe policy
> based routing. Is it possible to let the ssh client use a specific
> network interface for an outgoing connection? I could not tell from `man
> 8 dropbear` or `man 1 dbclient`.

Hi Alex,

Not at the moment. It wouldn?t be hard to implement OpenSSH?s ?-b bindaddress?, I?ll put it on the todo list.

Cheers,
Matt

From rcleere at gmail.com  Tue Oct 21 02:39:21 2014
From: rcleere at gmail.com (Ryan Cleere)
Date: Mon, 20 Oct 2014 13:39:21 -0500
Subject: [Patch] Add SSH_CLIENT environment variable
Message-ID: <CANdbdj+Nti3VmnmbKpDv8sbd6_kD19Poc8vcEpNmvzU=Wq24OQ@mail.gmail.com>

I had a problem where bash was not overwriting the default PATH variable
which defaults to '/usr/bin:/bin'. This was causing remote management to
fail because it couldn't find the commands in the PATH. I found that for
bash to execute ~/.bashrc the environment variable 'SSH_CLIENT' needs to be
set. Openssh sets the variable to "remoteip remote_port local_port", which
is very similar to 'SSH_CONNECTION'. This patch sets the 'SSH_CLIENT'
environment variable which causes bash to execute .bashrc upon startup.

Thanks,
Ryan

Author: Ryan <rcleere at gmail.com>
Date:   Mon Oct 20 12:59:47 2014 -0500

    Add SSH_CLIENT environment variable

diff --git a/chansession.h b/chansession.h
index 1a01d04..50ba8f0 100644
--- a/chansession.h
+++ b/chansession.h
@@ -54,6 +54,9 @@ struct ChanSess {
        /* Used to set $SSH_CONNECTION in the child session.
        Is only set temporarily before forking */
        char *connection_string;
+
+       /* Used to set $SSH_CLIENT in the child session. */
+       char *client_string;

 #ifndef DISABLE_X11FWD
        struct Listener * x11listener;
diff --git a/svr-chansession.c b/svr-chansession.c
index 6c73778..b3c5c87 100644
--- a/svr-chansession.c
+++ b/svr-chansession.c
@@ -241,6 +241,7 @@ static int newchansess(struct Channel *channel) {
        chansess = (struct ChanSess*)m_malloc(sizeof(struct ChanSess));
        chansess->cmd = NULL;
        chansess->connection_string = NULL;
+       chansess->client_string = NULL;
        chansess->pid = 0;

        /* pty details */
@@ -617,6 +618,21 @@ static char* make_connection_string() {
        return ret;
 }

+static char* make_client_string() {
+       char *local_ip, *local_port, *remote_ip, *remote_port;
+       size_t len;
+       char *ret;
+       get_socket_address(ses.sock_in, &local_ip, &local_port, &remote_ip,
&remote_port, 0);
+       len = strlen(local_ip) + strlen(local_port) + strlen(remote_ip) +
strlen(remote_port) + 4;
+       ret = m_malloc(len);
+       snprintf(ret, len, "%s %s %s", remote_ip, remote_port, local_port);
+       m_free(local_ip);
+       m_free(local_port);
+       m_free(remote_ip);
+       m_free(remote_port);
+       return ret;
+}
+
 /* Handle a command request from the client. This is used for both shell
  * and command-execution requests, and passes the command to
  * noptycommand or ptycommand as appropriate.
@@ -678,6 +694,7 @@ static int sessioncommand(struct Channel *channel,
struct ChanSess *chansess,
        connection_string is freed below. */
 #ifndef USE_VFORK
        chansess->connection_string = make_connection_string();
+       chansess->client_string = make_client_string();
 #endif

        if (chansess->term == NULL) {
@@ -694,6 +711,7 @@ static int sessioncommand(struct Channel *channel,
struct ChanSess *chansess,

 #ifndef USE_VFORK
        m_free(chansess->connection_string);
+       m_free(chansess->client_string);
 #endif

        if (ret == DROPBEAR_FAILURE) {
@@ -949,6 +967,10 @@ static void execchild(void *user_data) {
        if (chansess->connection_string) {
                addnewvar("SSH_CONNECTION", chansess->connection_string);
        }
+
+       if (chansess->client_string) {
+               addnewvar("SSH_CLIENT", chansess->client_string);
+       }

 #ifdef ENABLE_SVR_PUBKEY_OPTIONS
        if (chansess->original_command) {
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141020/e25475d0/attachment.htm 

From mrapoport at Airspan.com  Tue Oct 21 21:00:56 2014
From: mrapoport at Airspan.com (Michael Rapoport)
Date: Tue, 21 Oct 2014 13:00:56 +0000
Subject: IPv4 and IPv6 support
Message-ID: <9D1898A395B5F0468B9F5152D5FB5FBA0929B1A5@FS34.airspan.com>

Hello.

We are using currently the dropbear for the IPv4 only:

/usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 192.168.1.1:22 -p 192.168.14.30:22


Now, we need to add the IPv6 support.
I have a question:

Is it possible to use just one instance of dropbear for both protocols by just adding the IPv6 address and port like this:
       /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 192.168.1.1:22 -p 192.168.14.30:22 -p [2003::100:17]:22

Or I need to run the second instance of the dropbear with the IPv6 address and port like this:
       /usr/sbin/dropbear  -p [2003::100:17]:22

I'm running the latest release 2014.65 and the combined option doesn't work, while the second option with 2 instances works.

Thank you,
Sincerely,
Michael.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141021/b20cac04/attachment.htm 

From matt at ucc.asn.au  Tue Oct 21 21:58:43 2014
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 21 Oct 2014 21:58:43 +0800
Subject: IPv4 and IPv6 support
In-Reply-To: <9D1898A395B5F0468B9F5152D5FB5FBA0929B1A5@FS34.airspan.com>
References: <9D1898A395B5F0468B9F5152D5FB5FBA0929B1A5@FS34.airspan.com>
Message-ID: <20141021135843.GK14135@ucc.gu.uwa.edu.au>

Hi Michael,

I just checked now, it works for me on Linux 3.13 and OSX 10.10. What platform
are you running on? What do you see for the commands below?

Output from "strace" looking where it calls bind() might be informative too.

I can't really think of anything Dropbear would be doing
that would prevent it, given 2 instances work.
That's not to say it's not doing something wrong though.

Cheers,
Matt

# dropbear -F -E -p '[2405:3c00:5200:101::111]:9999' -p 130.95.13.111:5555 
[1981] Oct 21 21:50:30 Failed loading /etc/dropbear/dropbear_ecdsa_host_key
[1981] Oct 21 21:50:30 Not backgrounding

# lsof -p 1981
...
dropbear 1981 root    3u  IPv6 4449935      0t0     TCP evil.ucc.gu.uwa.edu.au:9999 (LISTEN)
dropbear 1981 root    4u  IPv4 4449936      0t0     TCP evil.ucc.gu.uwa.edu.au:5555 (LISTEN)

# netstat -antp|grep 2139
tcp        0      0 130.95.13.111:5555      0.0.0.0:*               LISTEN      1981/dropbear   
tcp6       0      0 2405:3c00:5200:101:9999 :::*                    LISTEN      1981/dropbear   


On Tue, Oct 21, 2014 at 01:00:56PM +0000, Michael Rapoport wrote:
> Hello.
> 
> We are using currently the dropbear for the IPv4 only:
> 
> /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 192.168.1.1:22 -p 192.168.14.30:22
> 
> 
> Now, we need to add the IPv6 support.
> I have a question:
> 
> Is it possible to use just one instance of dropbear for both protocols by just adding the IPv6 address and port like this:
>        /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 192.168.1.1:22 -p 192.168.14.30:22 -p [2003::100:17]:22
> 
> Or I need to run the second instance of the dropbear with the IPv6 address and port like this:
>        /usr/sbin/dropbear  -p [2003::100:17]:22
> 
> I'm running the latest release 2014.65 and the combined option doesn't work, while the second option with 2 instances works.
> 
> Thank you,
> Sincerely,
> Michael.
> 

From matt at ucc.asn.au  Tue Oct 21 23:09:46 2014
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 21 Oct 2014 23:09:46 +0800
Subject: [Patch] Add SSH_CLIENT environment variable
In-Reply-To: <CANdbdj+Nti3VmnmbKpDv8sbd6_kD19Poc8vcEpNmvzU=Wq24OQ@mail.gmail.com>
References: <CANdbdj+Nti3VmnmbKpDv8sbd6_kD19Poc8vcEpNmvzU=Wq24OQ@mail.gmail.com>
Message-ID: <20141021150946.GL14135@ucc.gu.uwa.edu.au>

Thanks, I've merged it with some small changes.

I keep being surprised bash doesn't have separate
interactive/non-interactive config files, like .zshrc vs
.zshenv

Matt

On Mon, Oct 20, 2014 at 01:39:21PM -0500, Ryan Cleere wrote:
> I had a problem where bash was not overwriting the default PATH variable
> which defaults to '/usr/bin:/bin'. This was causing remote management to
> fail because it couldn't find the commands in the PATH. I found that for
> bash to execute ~/.bashrc the environment variable 'SSH_CLIENT' needs to be
> set. Openssh sets the variable to "remoteip remote_port local_port", which
> is very similar to 'SSH_CONNECTION'. This patch sets the 'SSH_CLIENT'
> environment variable which causes bash to execute .bashrc upon startup.
> 
> Thanks,
> Ryan
> 
> Author: Ryan <rcleere at gmail.com>
> Date:   Mon Oct 20 12:59:47 2014 -0500
> 
>     Add SSH_CLIENT environment variable
> 
> diff --git a/chansession.h b/chansession.h
> index 1a01d04..50ba8f0 100644
> --- a/chansession.h
> +++ b/chansession.h
> @@ -54,6 +54,9 @@ struct ChanSess {
>         /* Used to set $SSH_CONNECTION in the child session.
>         Is only set temporarily before forking */
>         char *connection_string;
> +
> +       /* Used to set $SSH_CLIENT in the child session. */
> +       char *client_string;
> 
>  #ifndef DISABLE_X11FWD
>         struct Listener * x11listener;
> diff --git a/svr-chansession.c b/svr-chansession.c
> index 6c73778..b3c5c87 100644
> --- a/svr-chansession.c
> +++ b/svr-chansession.c
> @@ -241,6 +241,7 @@ static int newchansess(struct Channel *channel) {
>         chansess = (struct ChanSess*)m_malloc(sizeof(struct ChanSess));
>         chansess->cmd = NULL;
>         chansess->connection_string = NULL;
> +       chansess->client_string = NULL;
>         chansess->pid = 0;
> 
>         /* pty details */
> @@ -617,6 +618,21 @@ static char* make_connection_string() {
>         return ret;
>  }
> 
> +static char* make_client_string() {
> +       char *local_ip, *local_port, *remote_ip, *remote_port;
> +       size_t len;
> +       char *ret;
> +       get_socket_address(ses.sock_in, &local_ip, &local_port, &remote_ip,
> &remote_port, 0);
> +       len = strlen(local_ip) + strlen(local_port) + strlen(remote_ip) +
> strlen(remote_port) + 4;
> +       ret = m_malloc(len);
> +       snprintf(ret, len, "%s %s %s", remote_ip, remote_port, local_port);
> +       m_free(local_ip);
> +       m_free(local_port);
> +       m_free(remote_ip);
> +       m_free(remote_port);
> +       return ret;
> +}
> +
>  /* Handle a command request from the client. This is used for both shell
>   * and command-execution requests, and passes the command to
>   * noptycommand or ptycommand as appropriate.
> @@ -678,6 +694,7 @@ static int sessioncommand(struct Channel *channel,
> struct ChanSess *chansess,
>         connection_string is freed below. */
>  #ifndef USE_VFORK
>         chansess->connection_string = make_connection_string();
> +       chansess->client_string = make_client_string();
>  #endif
> 
>         if (chansess->term == NULL) {
> @@ -694,6 +711,7 @@ static int sessioncommand(struct Channel *channel,
> struct ChanSess *chansess,
> 
>  #ifndef USE_VFORK
>         m_free(chansess->connection_string);
> +       m_free(chansess->client_string);
>  #endif
> 
>         if (ret == DROPBEAR_FAILURE) {
> @@ -949,6 +967,10 @@ static void execchild(void *user_data) {
>         if (chansess->connection_string) {
>                 addnewvar("SSH_CONNECTION", chansess->connection_string);
>         }
> +
> +       if (chansess->client_string) {
> +               addnewvar("SSH_CLIENT", chansess->client_string);
> +       }
> 
>  #ifdef ENABLE_SVR_PUBKEY_OPTIONS
>         if (chansess->original_command) {

From jamie at shareable.org  Tue Oct 21 23:41:54 2014
From: jamie at shareable.org (Jamie Lokier)
Date: Tue, 21 Oct 2014 16:41:54 +0100
Subject: [Patch] Add SSH_CLIENT environment variable
In-Reply-To: <20141021150946.GL14135@ucc.gu.uwa.edu.au>
References: <CANdbdj+Nti3VmnmbKpDv8sbd6_kD19Poc8vcEpNmvzU=Wq24OQ@mail.gmail.com>
	<20141021150946.GL14135@ucc.gu.uwa.edu.au>
Message-ID: <20141021154154.GZ6266@jl-vm1.vm.bytemark.co.uk>

Matt Johnston wrote:
> Thanks, I've merged it with some small changes.
> 
> I keep being surprised bash doesn't have separate
> interactive/non-interactive config files, like .zshrc vs
> .zshenv

It does, if you pass BASH_ENV in the environment.  BASH_ENV gives the
name of a config file to run only when bash is non-interactive, so you
to match that zsh behaviour, you might set BASH_ENV=$HOME/.bashenv.

-- Jamie

From stevenhoneyman at gmail.com  Wed Oct 22 00:26:17 2014
From: stevenhoneyman at gmail.com (Steven Honeyman)
Date: Tue, 21 Oct 2014 17:26:17 +0100
Subject: [PATCH] prevent unnecessary 'Failed loading' warning if -R is used
In-Reply-To: <CABz95_DORHY-RBsvS-aHCqergH2rTdf1nmp2jG_XpenVkssXqQ@mail.gmail.com>
References: <CABz95_DORHY-RBsvS-aHCqergH2rTdf1nmp2jG_XpenVkssXqQ@mail.gmail.com>
Message-ID: <CABz95_AmUTDGtbN_UeR796medP870nbezZyM8XWu4AbFc3_m0g@mail.gmail.com>

On 25 September 2014 00:52, Steven Honeyman <stevenhoneyman at gmail.com> wrote:
> If keys are set to be generated when the first connection is made,
> then a message saying "Failed" looks bad. This change only shows the
> warning if -R is either not used at runtime, or if it's not compiled
> in.
>
> (apologies for using git format-patch... I've never used mercurial,
> and figured this was trivial enough to post as-is)
>
>
> Signed-off-by: Steven Honeyman <stevenhoneyman at gmail.com>
>
> ---
>  svr-runopts.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/svr-runopts.c b/svr-runopts.c
> index 8380de3..f285ab7 100644
> --- a/svr-runopts.c
> +++ b/svr-runopts.c
> @@ -410,6 +410,9 @@ static void loadhostkey(const char *keyfile, int
> fatal_duplicate) {
>      sign_key * read_key = new_sign_key();
>      enum signkey_type type = DROPBEAR_SIGNKEY_ANY;
>      if (readhostkey(keyfile, read_key, &type) == DROPBEAR_FAILURE) {
> +#ifdef DROPBEAR_DELAY_HOSTKEY
> +        if (!svr_opts.delay_hostkey)
> +#endif
>          dropbear_log(LOG_WARNING, "Failed loading %s", keyfile);
>      }
>
> --
> 2.1.0

Hi Matt,

Any chance this could be reviewed?

Thanks

From matt at ucc.asn.au  Wed Oct 22 07:18:27 2014
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed, 22 Oct 2014 07:18:27 +0800
Subject: [PATCH] prevent unnecessary 'Failed loading' warning if -R is used
In-Reply-To: <CABz95_AmUTDGtbN_UeR796medP870nbezZyM8XWu4AbFc3_m0g@mail.gmail.com>
References: <CABz95_DORHY-RBsvS-aHCqergH2rTdf1nmp2jG_XpenVkssXqQ@mail.gmail.com>
	<CABz95_AmUTDGtbN_UeR796medP870nbezZyM8XWu4AbFc3_m0g@mail.gmail.com>
Message-ID: <20141021231827.GM14135@ucc.gu.uwa.edu.au>

Hi Steven,

I've applied this now, sorry it didn't get done weeks ago.

Matt

On Tue, Oct 21, 2014 at 05:26:17PM +0100, Steven Honeyman wrote:
> On 25 September 2014 00:52, Steven Honeyman <stevenhoneyman at gmail.com> wrote:
> > If keys are set to be generated when the first connection is made,
> > then a message saying "Failed" looks bad. This change only shows the
> > warning if -R is either not used at runtime, or if it's not compiled
> > in.
> >
> > (apologies for using git format-patch... I've never used mercurial,
> > and figured this was trivial enough to post as-is)
> >
> >
> > Signed-off-by: Steven Honeyman <stevenhoneyman at gmail.com>
> >
> > ---
> >  svr-runopts.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/svr-runopts.c b/svr-runopts.c
> > index 8380de3..f285ab7 100644
> > --- a/svr-runopts.c
> > +++ b/svr-runopts.c
> > @@ -410,6 +410,9 @@ static void loadhostkey(const char *keyfile, int
> > fatal_duplicate) {
> >      sign_key * read_key = new_sign_key();
> >      enum signkey_type type = DROPBEAR_SIGNKEY_ANY;
> >      if (readhostkey(keyfile, read_key, &type) == DROPBEAR_FAILURE) {
> > +#ifdef DROPBEAR_DELAY_HOSTKEY
> > +        if (!svr_opts.delay_hostkey)
> > +#endif
> >          dropbear_log(LOG_WARNING, "Failed loading %s", keyfile);
> >      }
> >
> > --
> > 2.1.0
> 
> Hi Matt,
> 
> Any chance this could be reviewed?
> 
> Thanks

From matt at ucc.asn.au  Thu Oct 23 20:54:21 2014
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 23 Oct 2014 20:54:21 +0800
Subject: X11 forwarding in dbclient
In-Reply-To: <CAKzsc6c2SP1kQrr2t3S8_EFj-AWyFzwrgxRSmYus-dWHdaNk4g@mail.gmail.com>
References: <CAKzsc6c2SP1kQrr2t3S8_EFj-AWyFzwrgxRSmYus-dWHdaNk4g@mail.gmail.com>
Message-ID: <20141023125421.GO14135@ucc.gu.uwa.edu.au>

Hi,

Sorry I forgot to reply to this.

It shouldn't be too hard. The "tricky" bit would be sorting
out a fake X11 cookie to pass through xauth. The OpenSSH
code would be worth looking at.

Matt

On Thu, Oct 09, 2014 at 12:58:27PM +0200, Hans Harder wrote:
> How difficult is it to get X11 forwarding in the dbclient.
> 
> currently I only have it working when using openssh with -X option.
> But because of multihop (more than 2 hops)  I have to use dbclient, but it
> doesn't support X11 forwarding.
> 
> thx
> 
> Hans

From matt at ucc.asn.au  Thu Oct 23 20:56:50 2014
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 23 Oct 2014 20:56:50 +0800
Subject: android
In-Reply-To: <CAFo83mF5AGTwyyrbzB_zO9hkurK4pTuAP4Sz0XiV25KPc75LGg@mail.gmail.com>
References: <CAFo83mF5AGTwyyrbzB_zO9hkurK4pTuAP4Sz0XiV25KPc75LGg@mail.gmail.com>
Message-ID: <20141023125650.GP14135@ucc.gu.uwa.edu.au>

Hi Jed,

Android doesn't have all the normal auth functions. A
patched Dropbear repository is at
https://github.com/barryk/android_external_dropbear/network

Cheers,
Matt

On Fri, Oct 10, 2014 at 04:50:22PM -0400, Jed Evnull wrote:
> Hello,
> 
> I'm compiling dropbear v2014.65 with the sourcery toolchain using:
> 
> ./configure --host=arm-none-linux-gnueabi \
> --disable-zlib \
> --disable-largefile \
> --disable-loginfunc \
> --disable-shadow \
> --disable-utmp \
> --disable-utmpx \
> --disable-wtmp \
> --disable-wtmpx \
> --disable-pututline \
> --disable-pututxline \
> --disable-lastlog \
> CC=arm-none-linux-gnueabi-gcc
> 
> The compile goes fine, but as expected, login via password fails for
> android.  I no longer see an option to supply a password at dropbear start
> with -C.  Has this been deprecated? Is there a patch?
> 
> Thanks for any help!

From matt at ucc.asn.au  Thu Oct 23 22:12:40 2014
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 23 Oct 2014 22:12:40 +0800
Subject: Dropbear 2014.66
Message-ID: <20141023141239.GQ14135@ucc.gu.uwa.edu.au>

Hi all,

I've released Dropbear 2014.66. It has a few small fixes for
the previous release.

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

Cheers,
Matt


2014.66 - Thursday 23 October 2014

- Use the same keepalive handling behaviour as OpenSSH. This will work better 
  with some SSH implementations that have different behaviour with unknown 
  message types.

- Don't reply with SSH_MSG_UNIMPLEMENTED when we receive a reply to our own 
  keepalive message

- Set $SSH_CLIENT to keep bash happy, patch from Ryan Cleere

- Fix wtmp which broke since 2013.62, patch from Whoopie

From stevenhoneyman at gmail.com  Sun Oct 26 03:40:28 2014
From: stevenhoneyman at gmail.com (Steven Honeyman)
Date: Sat, 25 Oct 2014 20:40:28 +0100
Subject: hostkey mkdir bug/feature request
Message-ID: <CABz95_CGh1mGMmYyw38tw62SLdAKufqXqODxY-CB1PagDcW-gA@mail.gmail.com>

I'm not sure if this is intended or not, but I just got this
accidently; when quickly testing on a system which /etc/dropbear does
not yet exist:

# ./dropbear -R -F -E
[2417] Oct 25 20:27:56 Not backgrounding
[2425] Oct 25 20:28:00 Child connection from 127.0.0.1:44185
[2425] Oct 25 20:28:00 Couldn't create new file
/etc/dropbear/dropbear_rsa_host_key.tmp2425: No such file or directory
[2425] Oct 25 20:28:00 Exit before auth: Couldn't read or generate
hostkey /etc/dropbear/dropbear_rsa_host_key

(now, I mkdir /etc/dropbear and try and reconnect)

[2442] Oct 25 20:28:18 Child connection from 127.0.0.1:44186
[2442] Oct 25 20:28:18 Generated hostkey
/etc/dropbear/dropbear_rsa_host_key, fingerprint is sha1!! 29:96:.....


I'd expect if /etc/dropbear did not exist, then it should be created
.
If not a bug, then please consider it a feature request for some time
in the future :)


Thanks,
Steven

From jacmet at sunsite.dk  Tue Oct 28 21:11:26 2014
From: jacmet at sunsite.dk (Peter Korsgaard)
Date: Tue, 28 Oct 2014 14:11:26 +0100
Subject: [PATCH] gensignkey: ensure host keys are flushed to disk
Message-ID: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>

From: Peter Korsgaard <peter at korsgaard.com>

Otherwise we can end up with an empty host key, breaking logins.

E.G.:

Run dropbear -R and pull power before the host key is writting to disk.
After reboot we have:

ls -l /etc/dropbear/
-rw-------    1 root     root        0 Oct 28 10:41 dropbear_ecdsa_host_key

Which dropbear will try to read and fail:

[599] Oct 28 10:43:43 Early exit: Bad buf_getptr

Signed-off-by: Peter Korsgaard <peter at korsgaard.com>
---
 gensignkey.c |  1 +
 svr-kex.c    | 17 +++++++++++++++++
 2 files changed, 18 insertions(+)

diff --git a/gensignkey.c b/gensignkey.c
index 338bbef..06fdfd3 100644
--- a/gensignkey.c
+++ b/gensignkey.c
@@ -41,6 +41,7 @@ static int buf_writefile(buffer * buf, const char * filename) {
 
 out:
 	if (fd >= 0) {
+		fsync(fd);
 		m_close(fd);
 	}
 	return ret;
diff --git a/svr-kex.c b/svr-kex.c
index 337c377..8e76489 100644
--- a/svr-kex.c
+++ b/svr-kex.c
@@ -89,6 +89,7 @@ static void svr_ensure_hostkey() {
 
 	const char* fn = NULL;
 	char *fn_temp = NULL;
+	char *fn_dir = NULL;
 	enum signkey_type type = ses.newkeys->algo_hostkey;
 	void **hostkey = signkey_key_ptr(svr_opts.hostkey, type);
 	int ret = DROPBEAR_FAILURE;
@@ -142,6 +143,22 @@ static void svr_ensure_hostkey() {
 		}
 	}
 
+#ifdef HAVE_LIBGEN_H
+	/* ensure directory update is flushed to disk */
+	fn_dir = strdup(fn);
+	if (fn_dir != NULL) {
+		char *dir = dirname(fn_dir);
+		int dirfd = open(dir, O_RDONLY);
+
+		if (dirfd != -1) {
+			fsync(dirfd);
+			close(dirfd);
+		}
+
+		free(fn_dir);
+	}
+#endif
+
 	ret = readhostkey(fn, svr_opts.hostkey, &type);
 
 	if (ret == DROPBEAR_SUCCESS) {
-- 
2.1.0


From emmanuel.deloget at sfr.com  Tue Oct 28 22:38:54 2014
From: emmanuel.deloget at sfr.com (DELOGET, Emmanuel)
Date: Tue, 28 Oct 2014 14:38:54 +0000
Subject: [PATCH] gensignkey: ensure host keys are flushed to disk
In-Reply-To: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>
References: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>
Message-ID: <1414507134.7974.2.camel@sfr.com>

Hello, 

These are only comments - I'm not Matt :)

Le mardi 28 octobre 2014 ? 14:11 +0100, Peter Korsgaard a ?crit :
> From: Peter Korsgaard <peter at korsgaard.com>
> 
> Otherwise we can end up with an empty host key, breaking logins.
> 
> E.G.:
> 
> Run dropbear -R and pull power before the host key is writting to disk.
> After reboot we have:
> 
> ls -l /etc/dropbear/
> -rw-------    1 root     root        0 Oct 28 10:41 dropbear_ecdsa_host_key
> 
> Which dropbear will try to read and fail:
> 
> [599] Oct 28 10:43:43 Early exit: Bad buf_getptr
> 
> Signed-off-by: Peter Korsgaard <peter at korsgaard.com>
> ---
>  gensignkey.c |  1 +
>  svr-kex.c    | 17 +++++++++++++++++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/gensignkey.c b/gensignkey.c
> index 338bbef..06fdfd3 100644
> --- a/gensignkey.c
> +++ b/gensignkey.c
> @@ -41,6 +41,7 @@ static int buf_writefile(buffer * buf, const char * filename) {
>  
>  out:
>  	if (fd >= 0) {
> +		fsync(fd);

Instead of fsync, I think it sould be better to open the file with
O_SYNC on the systems that allows it (and add a fsync fallback on the
systems where O_SYNC is not available). While it will degrade the
performance a bit (since the file is quite small, I guess that adding
O_SYNC would not be that bad), it will ensure that the write will not
return until the data + metadata is present on disk - meaning that we'll
avoid race conditions that could occur between the write and the fsync
operation.

>  		m_close(fd);
>  	}
>  	return ret;
> diff --git a/svr-kex.c b/svr-kex.c
> index 337c377..8e76489 100644
> --- a/svr-kex.c
> +++ b/svr-kex.c
> @@ -89,6 +89,7 @@ static void svr_ensure_hostkey() {
>  
>  	const char* fn = NULL;
>  	char *fn_temp = NULL;
> +	char *fn_dir = NULL;
>  	enum signkey_type type = ses.newkeys->algo_hostkey;
>  	void **hostkey = signkey_key_ptr(svr_opts.hostkey, type);
>  	int ret = DROPBEAR_FAILURE;
> @@ -142,6 +143,22 @@ static void svr_ensure_hostkey() {
>  		}
>  	}
>  
> +#ifdef HAVE_LIBGEN_H
> +	/* ensure directory update is flushed to disk */
> +	fn_dir = strdup(fn);
> +	if (fn_dir != NULL) {

if (fn_dir) ? Checking for NULL is not necessar - the C standard says
that we have a known path to promote pointers to boolean (

Anyway, it sound weird to not do a check if a malloc failed (which is
what is tested here) - thus I see 3 possibilities:

* stick with this solution
* use a PATH_MAX on-stack variable to store a copy of fn
* return an error if strdup() (or malloc) fails. 

I'm not sure there is one good answer to this specific point.

> +		char *dir = dirname(fn_dir);
> +		int dirfd = open(dir, O_RDONLY);

The O_DIRECTORY flag is missing (at least on Linux) to make sure that
the pathname is indeed a directory (it /might/ be a file).

> +
> +		if (dirfd != -1) {
> +			fsync(dirfd);

O_RDONLY file descriptors can be fsysnc only on Linux (that's a well
documented POSIX conformance issue). We should make sure that the fd is
writable before we fsync it. 

> +			close(dirfd);
> +		}
> +
> +		free(fn_dir);
> +	}
> +#endif
> +
>  	ret = readhostkey(fn, svr_opts.hostkey, &type);
>  
>  	if (ret == DROPBEAR_SUCCESS) {

Best regards, 

-- Emmanuel Deloget

From jacmet at sunsite.dk  Tue Oct 28 23:08:37 2014
From: jacmet at sunsite.dk (Peter Korsgaard)
Date: Tue, 28 Oct 2014 16:08:37 +0100
Subject: [PATCH] gensignkey: ensure host keys are flushed to disk
In-Reply-To: <1414507134.7974.2.camel@sfr.com> (Emmanuel DELOGET's message of
	"Tue, 28 Oct 2014 14:38:54 +0000")
References: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>
	<1414507134.7974.2.camel@sfr.com>
Message-ID: <87r3xs8c5m.fsf@dell.be.48ers.dk>

>>>>> "DELOGET," == DELOGET, Emmanuel <emmanuel.deloget at sfr.com> writes:

Hi (this time from an address subscribed to the list),

 >> out:
 >> if (fd >= 0) {
 >> +		fsync(fd);

 > Instead of fsync, I think it sould be better to open the file with
 > O_SYNC on the systems that allows it (and add a fsync fallback on the
 > systems where O_SYNC is not available). While it will degrade the
 > performance a bit (since the file is quite small, I guess that adding
 > O_SYNC would not be that bad), it will ensure that the write will not
 > return until the data + metadata is present on disk - meaning that we'll
 > avoid race conditions that could occur between the write and the fsync
 > operation.

This is the write to the temporary file, so it doesn't really
matter. The only important thing is to ensure the data is flushed before
the link / dir fsync is done.


 >> +#ifdef HAVE_LIBGEN_H
 >> +	/* ensure directory update is flushed to disk */
 >> +	fn_dir = strdup(fn);
 >> +	if (fn_dir != NULL) {

 > if (fn_dir) ? Checking for NULL is not necessar - the C standard says
 > that we have a known path to promote pointers to boolean (

Sure they are equivalent, just trying to follow the code style of the
rest of dropbear.


 > Anyway, it sound weird to not do a check if a malloc failed (which is
 > what is tested here) - thus I see 3 possibilities:

 > * stick with this solution
 > * use a PATH_MAX on-stack variable to store a copy of fn
 > * return an error if strdup() (or malloc) fails. 

 > I'm not sure there is one good answer to this specific point.

I'm not sure what you mean here? Are you referring to the fact that I
skip the fsync if the strdup fails?

I think the current behaviour is the most sensible. Strdup is very
unlikely to fail, and we don't want to quit the host key writing even if
it did (as you can then not use dropbear at all).


 >> +		char *dir = dirname(fn_dir);
 >> +		int dirfd = open(dir, O_RDONLY);

 > The O_DIRECTORY flag is missing (at least on Linux) to make sure that
 > the pathname is indeed a directory (it /might/ be a file).

Ok, but even so the fsync would be harmless.


 >> +
 >> +		if (dirfd != -1) {
 >> +			fsync(dirfd);

 > O_RDONLY file descriptors can be fsysnc only on Linux (that's a well
 > documented POSIX conformance issue). We should make sure that the fd is
 > writable before we fsync it. 

Ok, out of interest - What systems disallow fsync on RO directory FDs?
Changing to O_RDWR should be fine as we're already writing to the
directory.

Thanks for the review!

-- 
Bye, Peter Korsgaard

From post at lespocky.de  Wed Oct 29 00:11:03 2014
From: post at lespocky.de (Alexander Dahl)
Date: Tue, 28 Oct 2014 17:11:03 +0100
Subject: [PATCH] gensignkey: ensure host keys are flushed to disk
In-Reply-To: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>
References: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>
Message-ID: <544FC017.8090706@lespocky.de>

Hei hei,

On 28.10.2014 14:11, Peter Korsgaard wrote:
> Otherwise we can end up with an empty host key, breaking logins.
> 
> E.G.:
> 
> Run dropbear -R and pull power before the host key is writting to disk.
> After reboot we have:
> 
> ls -l /etc/dropbear/
> -rw-------    1 root     root        0 Oct 28 10:41 dropbear_ecdsa_host_key
> 
> Which dropbear will try to read and fail:

I can confirm this can happen in the wild. We already had this issue and
circumvented it by calling sync on the shell somewhere else in the init
process, however I consider it a more elegant solution if dropbear would
ensure this by itself.

Greets
Alex


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141028/a5afbb14/attachment.sig 

From plemay at accedian.com  Wed Nov  5 22:09:52 2014
From: plemay at accedian.com (Paul Lemay)
Date: Wed, 5 Nov 2014 09:09:52 -0500
Subject: Dropbear cli-session
In-Reply-To: <20140928133333.GA32743@ucc.gu.uwa.edu.au>
References: <CAGWNPhOgY63ZhBmxQ=MeFSqw5M5WzCs+rj8o1o7hwW8Ppqnb9g@mail.gmail.com>
	<CAGWNPhPmeqmxmKHyR14vHeJF_6oi6tK8opEsR0Os5HOtY08dDg@mail.gmail.com>
	<CAGWNPhNS01ecKkRS7bkf3AO2L_RnhvYfSHt3i48a9cM=5m8WuQ@mail.gmail.com>
	<20140928133333.GA32743@ucc.gu.uwa.edu.au>
Message-ID: <CAGWNPhNtD54OYJGGG7K9HxdNkgCre04H-MwgzkmfOb9vimYrQg@mail.gmail.com>

Hello Matt,

coming back to this project, I have tries the following as you suggested:

"If you want to run it all within Dropbear itself I'd modify
sessioncommand()  which handles subsystem requests. Rather
than calling ptycommand() or noptycommand() make it call
connect_remote() - have a look at newtcpdirect() for an
example. Set channel->writefd and channel->readfd to the
returned socket, and make sure you set ses.maxfd
appropriately. It's an asynchronous connection, but I think
it should work OK."

what happens, is that the client connects and the sequence of SSH
authorization  is executed properly. The Dropbear server establishes a TCP
connection with myserver. All this is good, then, as part of the
application protocol, myserver sends an HELLO message. The message is
received by Dropbear, encoded and sent to the client application. Dropbear
then receive a connection reset from the client.

TRACE  (28333) 1415195715.978336: > connection in progress: err = 99
TRACE  (28333) 1415195715.978341: leave netconfdirect: err 99 socketfd (7)
TRACE  (28333) 1415195715.978347: enter send_msg_channel_failure
TRACE  (28333) 1415195715.978362: leave send_msg_channel_failure
TRACE  (28333) 1415195715.978367: leave chansessionrequest
TRACE  (28333) 1415195715.978372: leave recv_msg_channel_request
TRACE  (28333) 1415195715.978391: empty queue dequeing
TRACE  (28333) 1415195715.978408: enter check_in_progress
TRACE  (28333) 1415195715.978428: enter send_msg_channel_open_confirmation
TRACE  (28333) 1415195715.978448: leave send_msg_channel_open_confirmation
TRACE  (28333) 1415195715.978458: leave check_in_progress: success
TRACE  (28333) 1415195715.978482: empty queue dequeing
TRACE  (28333) 1415195715.978580: send normal readfd
TRACE  (28333) 1415195715.978587: enter send_msg_channel_data
TRACE  (28333) 1415195715.978590: enter send_msg_channel_data isextended 0
fd 7
TRACE  (28333) 1415195715.978593: maxlen 16375
TRACE  (28333) 1415195715.978598: send_msg_channel_data: len 581 fd 7
TRACE  (28333) 1415195715.978624: leave send_msg_channel_data
TRACE  (28333) 1415195715.978644: empty queue dequeing
*[28333] Nov 05 08:55:15 Exit (plemay): Error reading: Connection reset by
peer       <---------------*
TRACE  (28333) 1415195715.978865: enter session_cleanup
TRACE  (28333) 1415195715.978873: enter chancleanup
TRACE  (28333) 1415195715.978877: channel 0 closing

The same suite of events work fine with sshd so I am sure there is probably
something missing in the initialization of the session. I have defines

const struct ChanType svrchansess = {
    0, /* sepfds */
    "session", /* name */
    newchansess, /* inithandler */
    NULL, /* checkclosehandler */
    chansessionrequest, /* reqhandler */
    closechansess, /* closehandler */
};

and made sure that it was calling a function very similar to
newtcpdirect(). Is there something that I do wrong or missing?




On 28 September 2014 09:33, Matt Johnston <matt at ucc.asn.au> wrote:

> If you want to run it all within Dropbear itself I'd modify
> sessioncommand()  which handles subsystem requests. Rather
> than calling ptycommand() or noptycommand() make it call
> connect_remote() - have a look at newtcpdirect() for an
> example. Set channel->writefd and channel->readfd to the
> returned socket, and make sure you set ses.maxfd
> appropriately. It's an asynchronous connection, but I think
> it should work OK.
>
> Another option would be to make a little helper script that runs
> 'nc host port' and add another special case like that for
> sftp in sessioncommand().
>
> Cheers,
> Matt
>
> On Thu, Sep 25, 2014 at 10:27:12AM -0400, Paul Lemay wrote:
> > Actually Matt,
> >
> > it is a NETCONF server that I am implementing but I was expecting to
> have a
> > TCP communication from dropbear! I see that you already trigger a
> subsystem
> > in such a context. Is it possible to setup a tcp communication link with
> > the server at this point in the code?
> >
> > On Thu, Sep 25, 2014 at 6:37 AM, Paul Lemay <plemay at accedian.com> wrote:
> >
> > > Hello Matt,
> > >
> > > Thanks for your reply.
> > >
> > > Let me provide additional information on what I am trying to do with
> > > Dropbear. There are several types of client applications (i.e., some
> > > running their own client version of SSH others running through the
> Dropbear
> > > SSH clients apps with prot forwarding). They are all looking for secure
> > > services provided by a single server (i.e., MyTcpServer). In other
> words,
> > > all SSH clients connects to a single Dropbear server for services
> provided
> > > by MyTcpServer. The other connections to the Dropbear server will be
> > > rejected by MyTcpServer because they won't support MyTcpServer XML
> > > protocol. Threfore, in my simple view of things, the Dropbear server
> > > instance provides the secure authentication and communication. All
> > > decrypted communication channels are forwarded to MyTcpServer.
> > >
> > > Hope this could help in finding a good solution.
> > >
> > > Best Regards!
> > >
> > > On Wed, Sep 24, 2014 at 1:01 PM, Paul Lemay <plemay at accedian.com>
> wrote:
> > >
> > >> Hello there,
> > >>
> > >> I have a SSH client browser. It is connected to the Dropbear server. I
> > >> would like to know if it is possible to tailor dropbear so that, once
> the
> > >> dropbear authentication process is completed, a connection is
> establish to
> > >> my local server ready to takeover TCP communication for this browser.
> > >>
> > >> I understand there is a cli-tcpfwd that seems to support this function
> > >> but I do not know how to use it. Are there some examples available?
> > >>
> > >
> > >
> >
> > --
> >
> >
> > Avis de confidentialit?
> >
> > Les informations contenues dans le pr?sent message et dans toute pi?ce
> qui
> > lui est jointe sont confidentielles et peuvent ?tre prot?g?es par le
> secret
> > professionnel. Ces informations sont ? l?usage exclusif de son ou de ses
> > destinataires. Si vous recevez ce message par erreur, veuillez s?il vous
> > plait communiquer imm?diatement avec l?exp?diteur et en d?truire tout
> > exemplaire. De plus, il vous est strictement interdit de le divulguer, de
> > le distribuer ou de le reproduire sans l?autorisation de l?exp?diteur.
> > Merci.
> >
> > Confidentiality notice
> >
> > This e-mail message and any attachment hereto contain confidential
> > information which may be privileged and which is intended for the
> exclusive
> > use of its addressee(s). If you receive this message in error, please
> > inform sender immediately and destroy any copy thereof. Furthermore, any
> > disclosure, distribution or copying of this message and/or any attachment
> > hereto without the consent of the sender is strictly prohibited. Thank
> you.
>

-- 


Avis de confidentialit?

Les informations contenues dans le pr?sent message et dans toute pi?ce qui 
lui est jointe sont confidentielles et peuvent ?tre prot?g?es par le secret 
professionnel. Ces informations sont ? l?usage exclusif de son ou de ses 
destinataires. Si vous recevez ce message par erreur, veuillez s?il vous 
plait communiquer imm?diatement avec l?exp?diteur et en d?truire tout 
exemplaire. De plus, il vous est strictement interdit de le divulguer, de 
le distribuer ou de le reproduire sans l?autorisation de l?exp?diteur. 
Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential 
information which may be privileged and which is intended for the exclusive 
use of its addressee(s). If you receive this message in error, please 
inform sender immediately and destroy any copy thereof. Furthermore, any 
disclosure, distribution or copying of this message and/or any attachment 
hereto without the consent of the sender is strictly prohibited. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141105/a63ae63f/attachment-0001.htm 

From plemay at accedian.com  Thu Nov  6 03:43:51 2014
From: plemay at accedian.com (Paul Lemay)
Date: Wed, 5 Nov 2014 14:43:51 -0500
Subject: Dropbear cli-session
In-Reply-To: <CAGWNPhNtD54OYJGGG7K9HxdNkgCre04H-MwgzkmfOb9vimYrQg@mail.gmail.com>
References: <CAGWNPhOgY63ZhBmxQ=MeFSqw5M5WzCs+rj8o1o7hwW8Ppqnb9g@mail.gmail.com>
	<CAGWNPhPmeqmxmKHyR14vHeJF_6oi6tK8opEsR0Os5HOtY08dDg@mail.gmail.com>
	<CAGWNPhNS01ecKkRS7bkf3AO2L_RnhvYfSHt3i48a9cM=5m8WuQ@mail.gmail.com>
	<20140928133333.GA32743@ucc.gu.uwa.edu.au>
	<CAGWNPhNtD54OYJGGG7K9HxdNkgCre04H-MwgzkmfOb9vimYrQg@mail.gmail.com>
Message-ID: <CAGWNPhMnKFSOCw-qW36TaX1rUAkUUz3YHuyA03ntj03un5G14A@mail.gmail.com>

Hello again Matt,

I finally made it worked with netcat as you suggested in earlier email. I
therefore believe that I am not connecting properly in the dropbear server
the RX and TX of the client and server. At what location should this be
done?

On 5 November 2014 09:09, Paul Lemay <plemay at accedian.com> wrote:

> Hello Matt,
>
> coming back to this project, I have tries the following as you suggested:
>
> "If you want to run it all within Dropbear itself I'd modify
> sessioncommand()  which handles subsystem requests. Rather
> than calling ptycommand() or noptycommand() make it call
> connect_remote() - have a look at newtcpdirect() for an
> example. Set channel->writefd and channel->readfd to the
> returned socket, and make sure you set ses.maxfd
> appropriately. It's an asynchronous connection, but I think
> it should work OK."
>
> what happens, is that the client connects and the sequence of SSH
> authorization  is executed properly. The Dropbear server establishes a TCP
> connection with myserver. All this is good, then, as part of the
> application protocol, myserver sends an HELLO message. The message is
> received by Dropbear, encoded and sent to the client application. Dropbear
> then receive a connection reset from the client.
>
> TRACE  (28333) 1415195715.978336: > connection in progress: err = 99
> TRACE  (28333) 1415195715.978341: leave netconfdirect: err 99 socketfd (7)
> TRACE  (28333) 1415195715.978347: enter send_msg_channel_failure
> TRACE  (28333) 1415195715.978362: leave send_msg_channel_failure
> TRACE  (28333) 1415195715.978367: leave chansessionrequest
> TRACE  (28333) 1415195715.978372: leave recv_msg_channel_request
> TRACE  (28333) 1415195715.978391: empty queue dequeing
> TRACE  (28333) 1415195715.978408: enter check_in_progress
> TRACE  (28333) 1415195715.978428: enter send_msg_channel_open_confirmation
> TRACE  (28333) 1415195715.978448: leave send_msg_channel_open_confirmation
> TRACE  (28333) 1415195715.978458: leave check_in_progress: success
> TRACE  (28333) 1415195715.978482: empty queue dequeing
> TRACE  (28333) 1415195715.978580: send normal readfd
> TRACE  (28333) 1415195715.978587: enter send_msg_channel_data
> TRACE  (28333) 1415195715.978590: enter send_msg_channel_data isextended 0
> fd 7
> TRACE  (28333) 1415195715.978593: maxlen 16375
> TRACE  (28333) 1415195715.978598: send_msg_channel_data: len 581 fd 7
> TRACE  (28333) 1415195715.978624: leave send_msg_channel_data
> TRACE  (28333) 1415195715.978644: empty queue dequeing
> *[28333] Nov 05 08:55:15 Exit (plemay): Error reading: Connection reset by
> peer       <---------------*
> TRACE  (28333) 1415195715.978865: enter session_cleanup
> TRACE  (28333) 1415195715.978873: enter chancleanup
> TRACE  (28333) 1415195715.978877: channel 0 closing
>
> The same suite of events work fine with sshd so I am sure there is
> probably something missing in the initialization of the session. I have
> defines
>
> const struct ChanType svrchansess = {
>     0, /* sepfds */
>     "session", /* name */
>     newchansess, /* inithandler */
>     NULL, /* checkclosehandler */
>     chansessionrequest, /* reqhandler */
>     closechansess, /* closehandler */
> };
>
> and made sure that it was calling a function very similar to
> newtcpdirect(). Is there something that I do wrong or missing?
>
>
>
>
> On 28 September 2014 09:33, Matt Johnston <matt at ucc.asn.au> wrote:
>
>> If you want to run it all within Dropbear itself I'd modify
>> sessioncommand()  which handles subsystem requests. Rather
>> than calling ptycommand() or noptycommand() make it call
>> connect_remote() - have a look at newtcpdirect() for an
>> example. Set channel->writefd and channel->readfd to the
>> returned socket, and make sure you set ses.maxfd
>> appropriately. It's an asynchronous connection, but I think
>> it should work OK.
>>
>> Another option would be to make a little helper script that runs
>> 'nc host port' and add another special case like that for
>> sftp in sessioncommand().
>>
>> Cheers,
>> Matt
>>
>> On Thu, Sep 25, 2014 at 10:27:12AM -0400, Paul Lemay wrote:
>> > Actually Matt,
>> >
>> > it is a NETCONF server that I am implementing but I was expecting to
>> have a
>> > TCP communication from dropbear! I see that you already trigger a
>> subsystem
>> > in such a context. Is it possible to setup a tcp communication link with
>> > the server at this point in the code?
>> >
>> > On Thu, Sep 25, 2014 at 6:37 AM, Paul Lemay <plemay at accedian.com>
>> wrote:
>> >
>> > > Hello Matt,
>> > >
>> > > Thanks for your reply.
>> > >
>> > > Let me provide additional information on what I am trying to do with
>> > > Dropbear. There are several types of client applications (i.e., some
>> > > running their own client version of SSH others running through the
>> Dropbear
>> > > SSH clients apps with prot forwarding). They are all looking for
>> secure
>> > > services provided by a single server (i.e., MyTcpServer). In other
>> words,
>> > > all SSH clients connects to a single Dropbear server for services
>> provided
>> > > by MyTcpServer. The other connections to the Dropbear server will be
>> > > rejected by MyTcpServer because they won't support MyTcpServer XML
>> > > protocol. Threfore, in my simple view of things, the Dropbear server
>> > > instance provides the secure authentication and communication. All
>> > > decrypted communication channels are forwarded to MyTcpServer.
>> > >
>> > > Hope this could help in finding a good solution.
>> > >
>> > > Best Regards!
>> > >
>> > > On Wed, Sep 24, 2014 at 1:01 PM, Paul Lemay <plemay at accedian.com>
>> wrote:
>> > >
>> > >> Hello there,
>> > >>
>> > >> I have a SSH client browser. It is connected to the Dropbear server.
>> I
>> > >> would like to know if it is possible to tailor dropbear so that,
>> once the
>> > >> dropbear authentication process is completed, a connection is
>> establish to
>> > >> my local server ready to takeover TCP communication for this browser.
>> > >>
>> > >> I understand there is a cli-tcpfwd that seems to support this
>> function
>> > >> but I do not know how to use it. Are there some examples available?
>> > >>
>> > >
>> > >
>> >
>> > --
>> >
>> >
>> > Avis de confidentialit?
>> >
>> > Les informations contenues dans le pr?sent message et dans toute pi?ce
>> qui
>> > lui est jointe sont confidentielles et peuvent ?tre prot?g?es par le
>> secret
>> > professionnel. Ces informations sont ? l?usage exclusif de son ou de ses
>> > destinataires. Si vous recevez ce message par erreur, veuillez s?il vous
>> > plait communiquer imm?diatement avec l?exp?diteur et en d?truire tout
>> > exemplaire. De plus, il vous est strictement interdit de le divulguer,
>> de
>> > le distribuer ou de le reproduire sans l?autorisation de l?exp?diteur.
>> > Merci.
>> >
>> > Confidentiality notice
>> >
>> > This e-mail message and any attachment hereto contain confidential
>> > information which may be privileged and which is intended for the
>> exclusive
>> > use of its addressee(s). If you receive this message in error, please
>> > inform sender immediately and destroy any copy thereof. Furthermore, any
>> > disclosure, distribution or copying of this message and/or any
>> attachment
>> > hereto without the consent of the sender is strictly prohibited. Thank
>> you.
>>
>
>

-- 


Avis de confidentialit?

Les informations contenues dans le pr?sent message et dans toute pi?ce qui 
lui est jointe sont confidentielles et peuvent ?tre prot?g?es par le secret 
professionnel. Ces informations sont ? l?usage exclusif de son ou de ses 
destinataires. Si vous recevez ce message par erreur, veuillez s?il vous 
plait communiquer imm?diatement avec l?exp?diteur et en d?truire tout 
exemplaire. De plus, il vous est strictement interdit de le divulguer, de 
le distribuer ou de le reproduire sans l?autorisation de l?exp?diteur. 
Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential 
information which may be privileged and which is intended for the exclusive 
use of its addressee(s). If you receive this message in error, please 
inform sender immediately and destroy any copy thereof. Furthermore, any 
disclosure, distribution or copying of this message and/or any attachment 
hereto without the consent of the sender is strictly prohibited. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141105/dafba918/attachment.htm 

From matt at ucc.asn.au  Sat Nov  8 22:26:02 2014
From: matt at ucc.asn.au (Matt Johnston)
Date: Sat, 8 Nov 2014 22:26:02 +0800
Subject: [PATCH] gensignkey: ensure host keys are flushed to disk
In-Reply-To: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>
References: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>
Message-ID: <20141108142602.GH10430@ucc.gu.uwa.edu.au>

On Tue, Oct 28, 2014 at 02:11:26PM +0100, Peter Korsgaard wrote:
> 
> Otherwise we can end up with an empty host key, breaking logins.
> 
> E.G.:
> 
> Run dropbear -R and pull power before the host key is writting to disk.
> After reboot we have:

Hi Peter,

Thanks for the patch, I've applied it with small changes.
https://secure.ucc.asn.au/hg/dropbear/rev/fd2e8bbb0333

Emmanuel - thanks for the review. Dropbear already has
exit-on-failure m_strdup(), I'm using that. I'll avoid
O_DIRECTORY since it's fairly harmless to leave out and is a
portability hassle. I've made it open with O_RDWR though can't
actually see in the opengroup.org posix docs where that is
required for fsync?

Cheers,
Matt

From matt at ucc.asn.au  Sat Nov  8 22:47:12 2014
From: matt at ucc.asn.au (Matt Johnston)
Date: Sat, 8 Nov 2014 22:47:12 +0800
Subject: Dropbear cli-session
In-Reply-To: <CAGWNPhNtD54OYJGGG7K9HxdNkgCre04H-MwgzkmfOb9vimYrQg@mail.gmail.com>
References: <CAGWNPhOgY63ZhBmxQ=MeFSqw5M5WzCs+rj8o1o7hwW8Ppqnb9g@mail.gmail.com>
	<CAGWNPhPmeqmxmKHyR14vHeJF_6oi6tK8opEsR0Os5HOtY08dDg@mail.gmail.com>
	<CAGWNPhNS01ecKkRS7bkf3AO2L_RnhvYfSHt3i48a9cM=5m8WuQ@mail.gmail.com>
	<20140928133333.GA32743@ucc.gu.uwa.edu.au>
	<CAGWNPhNtD54OYJGGG7K9HxdNkgCre04H-MwgzkmfOb9vimYrQg@mail.gmail.com>
Message-ID: <20141108144712.GI10430@ucc.gu.uwa.edu.au>

Hi Paul,

> TRACE  (28333) 1415195715.978336: > connection in progress: err = 99
> TRACE  (28333) 1415195715.978341: leave netconfdirect: err 99 socketfd (7)
> TRACE  (28333) 1415195715.978347: enter send_msg_channel_failure

What's printing this bit? It seems like something is
treating a SSH_OPEN_IN_PROGRESS (99) return value as
failure rather than just returning that from newchansess?

Cheers,
Matt

> TRACE  (28333) 1415195715.978362: leave send_msg_channel_failure
> TRACE  (28333) 1415195715.978367: leave chansessionrequest
> TRACE  (28333) 1415195715.978372: leave recv_msg_channel_request
> TRACE  (28333) 1415195715.978391: empty queue dequeing
> TRACE  (28333) 1415195715.978408: enter check_in_progress
> TRACE  (28333) 1415195715.978428: enter send_msg_channel_open_confirmation
> TRACE  (28333) 1415195715.978448: leave send_msg_channel_open_confirmation
> TRACE  (28333) 1415195715.978458: leave check_in_progress: success
> TRACE  (28333) 1415195715.978482: empty queue dequeing
> TRACE  (28333) 1415195715.978580: send normal readfd
> TRACE  (28333) 1415195715.978587: enter send_msg_channel_data
> TRACE  (28333) 1415195715.978590: enter send_msg_channel_data isextended 0
> fd 7
> TRACE  (28333) 1415195715.978593: maxlen 16375
> TRACE  (28333) 1415195715.978598: send_msg_channel_data: len 581 fd 7
> TRACE  (28333) 1415195715.978624: leave send_msg_channel_data
> TRACE  (28333) 1415195715.978644: empty queue dequeing
> *[28333] Nov 05 08:55:15 Exit (plemay): Error reading: Connection reset by
> peer       <---------------*
> TRACE  (28333) 1415195715.978865: enter session_cleanup
> TRACE  (28333) 1415195715.978873: enter chancleanup
> TRACE  (28333) 1415195715.978877: channel 0 closing
> 
> The same suite of events work fine with sshd so I am sure there is probably
> something missing in the initialization of the session. I have defines
> 
> const struct ChanType svrchansess = {
>     0, /* sepfds */
>     "session", /* name */
>     newchansess, /* inithandler */
>     NULL, /* checkclosehandler */
>     chansessionrequest, /* reqhandler */
>     closechansess, /* closehandler */
> };
> 
> and made sure that it was calling a function very similar to
> newtcpdirect(). Is there something that I do wrong or missing?
> 
> 
> 
> 
> On 28 September 2014 09:33, Matt Johnston <matt at ucc.asn.au> wrote:
> 
> > If you want to run it all within Dropbear itself I'd modify
> > sessioncommand()  which handles subsystem requests. Rather
> > than calling ptycommand() or noptycommand() make it call
> > connect_remote() - have a look at newtcpdirect() for an
> > example. Set channel->writefd and channel->readfd to the
> > returned socket, and make sure you set ses.maxfd
> > appropriately. It's an asynchronous connection, but I think
> > it should work OK.
> >
> > Another option would be to make a little helper script that runs
> > 'nc host port' and add another special case like that for
> > sftp in sessioncommand().
> >
> > Cheers,
> > Matt
> >
> > On Thu, Sep 25, 2014 at 10:27:12AM -0400, Paul Lemay wrote:
> > > Actually Matt,
> > >
> > > it is a NETCONF server that I am implementing but I was expecting to
> > have a
> > > TCP communication from dropbear! I see that you already trigger a
> > subsystem
> > > in such a context. Is it possible to setup a tcp communication link with
> > > the server at this point in the code?
> > >
> > > On Thu, Sep 25, 2014 at 6:37 AM, Paul Lemay <plemay at accedian.com> wrote:
> > >
> > > > Hello Matt,
> > > >
> > > > Thanks for your reply.
> > > >
> > > > Let me provide additional information on what I am trying to do with
> > > > Dropbear. There are several types of client applications (i.e., some
> > > > running their own client version of SSH others running through the
> > Dropbear
> > > > SSH clients apps with prot forwarding). They are all looking for secure
> > > > services provided by a single server (i.e., MyTcpServer). In other
> > words,
> > > > all SSH clients connects to a single Dropbear server for services
> > provided
> > > > by MyTcpServer. The other connections to the Dropbear server will be
> > > > rejected by MyTcpServer because they won't support MyTcpServer XML
> > > > protocol. Threfore, in my simple view of things, the Dropbear server
> > > > instance provides the secure authentication and communication. All
> > > > decrypted communication channels are forwarded to MyTcpServer.
> > > >
> > > > Hope this could help in finding a good solution.
> > > >
> > > > Best Regards!
> > > >
> > > > On Wed, Sep 24, 2014 at 1:01 PM, Paul Lemay <plemay at accedian.com>
> > wrote:
> > > >
> > > >> Hello there,
> > > >>
> > > >> I have a SSH client browser. It is connected to the Dropbear server. I
> > > >> would like to know if it is possible to tailor dropbear so that, once
> > the
> > > >> dropbear authentication process is completed, a connection is
> > establish to
> > > >> my local server ready to takeover TCP communication for this browser.
> > > >>
> > > >> I understand there is a cli-tcpfwd that seems to support this function
> > > >> but I do not know how to use it. Are there some examples available?
> > > >>
> > > >
> > > >
> > >
> > > --
> > >
> > >
> > > Avis de confidentialit?
> > >
> > > Les informations contenues dans le pr?sent message et dans toute pi?ce
> > qui
> > > lui est jointe sont confidentielles et peuvent ?tre prot?g?es par le
> > secret
> > > professionnel. Ces informations sont ? l?usage exclusif de son ou de ses
> > > destinataires. Si vous recevez ce message par erreur, veuillez s?il vous
> > > plait communiquer imm?diatement avec l?exp?diteur et en d?truire tout
> > > exemplaire. De plus, il vous est strictement interdit de le divulguer, de
> > > le distribuer ou de le reproduire sans l?autorisation de l?exp?diteur.
> > > Merci.
> > >
> > > Confidentiality notice
> > >
> > > This e-mail message and any attachment hereto contain confidential
> > > information which may be privileged and which is intended for the
> > exclusive
> > > use of its addressee(s). If you receive this message in error, please
> > > inform sender immediately and destroy any copy thereof. Furthermore, any
> > > disclosure, distribution or copying of this message and/or any attachment
> > > hereto without the consent of the sender is strictly prohibited. Thank
> > you.
> >
> 
> -- 
> 
> 
> Avis de confidentialit?
> 
> Les informations contenues dans le pr?sent message et dans toute pi?ce qui 
> lui est jointe sont confidentielles et peuvent ?tre prot?g?es par le secret 
> professionnel. Ces informations sont ? l?usage exclusif de son ou de ses 
> destinataires. Si vous recevez ce message par erreur, veuillez s?il vous 
> plait communiquer imm?diatement avec l?exp?diteur et en d?truire tout 
> exemplaire. De plus, il vous est strictement interdit de le divulguer, de 
> le distribuer ou de le reproduire sans l?autorisation de l?exp?diteur. 
> Merci.
> 
> Confidentiality notice
> 
> This e-mail message and any attachment hereto contain confidential 
> information which may be privileged and which is intended for the exclusive 
> use of its addressee(s). If you receive this message in error, please 
> inform sender immediately and destroy any copy thereof. Furthermore, any 
> disclosure, distribution or copying of this message and/or any attachment 
> hereto without the consent of the sender is strictly prohibited. Thank you.

From emmanuel.deloget at sfr.com  Mon Nov 10 16:54:30 2014
From: emmanuel.deloget at sfr.com (DELOGET, Emmanuel)
Date: Mon, 10 Nov 2014 08:54:30 +0000
Subject: [PATCH] gensignkey: ensure host keys are flushed to disk
In-Reply-To: <20141108142602.GH10430@ucc.gu.uwa.edu.au>
References: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>
	<20141108142602.GH10430@ucc.gu.uwa.edu.au>
Message-ID: <1415609670.29319.3.camel@sfr.com>

Hello, 

Le samedi 08 novembre 2014 ? 22:26 +0800, Matt Johnston a ?crit :
> On Tue, Oct 28, 2014 at 02:11:26PM +0100, Peter Korsgaard wrote:
> > 
> > Otherwise we can end up with an empty host key, breaking logins.
> > 
> > E.G.:
> > 
> > Run dropbear -R and pull power before the host key is writting to disk.
> > After reboot we have:
> 
> Hi Peter,
> 
> Thanks for the patch, I've applied it with small changes.
> https://secure.ucc.asn.au/hg/dropbear/rev/fd2e8bbb0333
> 
> Emmanuel - thanks for the review. Dropbear already has
> exit-on-failure m_strdup(), I'm using that. I'll avoid
> O_DIRECTORY since it's fairly harmless to leave out and is a
> portability hassle. I've made it open with O_RDWR though can't
> actually see in the opengroup.org posix docs where that is
> required for fsync?

Part of the problem has its root here: the POSIX standard does not say a
word on this specific issue - so different UNIX have different
implementation. I found at least two of them: 

http://nixdoc.net/man-pages/irix/man2/fsync.2.html
http://nixdoc.net/man-pages/Tru64/man2/fsync.2.html

Granted, there are not the primary target for dropbear :)

The linux man page warns about that issue in the Notes section:

http://linux.die.net/man/2/fsync

Additionnally, a good number of other UNIX (and other POSIX layers such
as the one offered by eCos) doesn't say anything about that so it's hard
to know how the implementation behaves without testing it.

I might be a bit over-prudent here and maybe noone will ever notice. But
since it can lead to a nasty bug I think it's better to err on the side
of safety :) 

> Cheers,
> Matt

Best regards, 

-- Emmanuel Deloget


From seldhose at zinwave.com  Fri Nov 21 00:32:36 2014
From: seldhose at zinwave.com (Sony)
Date: Thu, 20 Nov 2014 16:32:36 +0000 (UTC)
Subject: limiting the connections
Message-ID: <loom.20141120T172534-884@post.gmane.org>

I am using the options.h to configure the number of connections allowed for
a dropbear server. But the server is configured as ssh     stream  tcp    
nowait  root    /usr/sbin/dropbear dropbear -Fi in the /etc/inetd.conf .
Each time a new connection request arrives, it will spawn a new dropbear
process. Each connection is handled by seperate processes, so i cannot limit
the number of connections by options.h configurations.
Is there a way i can use the same process for multiple connections ?


From jacmet at sunsite.dk  Mon Dec  1 19:51:08 2014
From: jacmet at sunsite.dk (Peter Korsgaard)
Date: Mon, 01 Dec 2014 12:51:08 +0100
Subject: [PATCH] gensignkey: ensure host keys are flushed to disk
In-Reply-To: <1415609670.29319.3.camel@sfr.com> (Emmanuel DELOGET's message of
	"Mon, 10 Nov 2014 08:54:30 +0000")
References: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>
	<20141108142602.GH10430@ucc.gu.uwa.edu.au>
	<1415609670.29319.3.camel@sfr.com>
Message-ID: <87mw77h9lf.fsf@dell.be.48ers.dk>

>>>>> "DELOGET," == DELOGET, Emmanuel <emmanuel.deloget at sfr.com> writes:

Hi, (this time from a subscribed address)

>> Thanks for the patch, I've applied it with small changes.
 >> https://secure.ucc.asn.au/hg/dropbear/rev/fd2e8bbb0333
 >> 
 >> Emmanuel - thanks for the review. Dropbear already has
 >> exit-on-failure m_strdup(), I'm using that. I'll avoid
 >> O_DIRECTORY since it's fairly harmless to leave out and is a
 >> portability hassle. I've made it open with O_RDWR though can't
 >> actually see in the opengroup.org posix docs where that is
 >> required for fsync?

 > Part of the problem has its root here: the POSIX standard does not say a
 > word on this specific issue - so different UNIX have different
 > implementation. I found at least two of them:

 > http://nixdoc.net/man-pages/irix/man2/fsync.2.html
 > http://nixdoc.net/man-pages/Tru64/man2/fsync.2.html

 > Granted, there are not the primary target for dropbear :)

 > The linux man page warns about that issue in the Notes section:

 > http://linux.die.net/man/2/fsync

 > Additionnally, a good number of other UNIX (and other POSIX layers such
 > as the one offered by eCos) doesn't say anything about that so it's hard
 > to know how the implementation behaves without testing it.

 > I might be a bit over-prudent here and maybe noone will ever notice. But
 > since it can lead to a nasty bug I think it's better to err on the side
 > of safety :)

Actually it is the other way around. Something related came up today,
and I finally now got to test what got committed. It doesn't work (on
Linux atleast) as open on the parent directory fails with -EISDIR unless
it is opened read only. This is also documented in the man page:

EISDIR pathname refers to a directory and the access requested involved
writing (that is, O_WRONLY or O_RDWR is set).

The exact code handling it in the kernel is in fs/namei.c:

static int may_open(struct path *path, int acc_mode, int flag)
{
        struct dentry *dentry = path->dentry;
        struct inode *inode = dentry->d_inode;
        int error;

        /* O_PATH? */
        if (!acc_mode)
                return 0;

        if (!inode)
                return -ENOENT;

        switch (inode->i_mode & S_IFMT) {
        case S_IFLNK:
                return -ELOOP;
        case S_IFDIR:
                if (acc_mode & MAY_WRITE)
                        return -EISDIR;
                break;
        ...

So we either need to change it back to O_RDONLY, or first try with
O_RDWR and fall back to O_RDONLY if it fails with EISDIR in case other
OSes require RDWR access for fsync.

What are we going to do?

-- 
Bye, Peter Korsgaard

From emmanuel.deloget at sfr.com  Tue Dec  2 00:25:13 2014
From: emmanuel.deloget at sfr.com (DELOGET, Emmanuel)
Date: Mon, 1 Dec 2014 16:25:13 +0000
Subject: [PATCH] gensignkey: ensure host keys are flushed to disk
In-Reply-To: <87r3wjh9pt.fsf@dell.be.48ers.dk>
References: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>
	<20141108142602.GH10430@ucc.gu.uwa.edu.au>
	<1415609670.29319.3.camel@sfr.com> <87r3wjh9pt.fsf@dell.be.48ers.dk>
Message-ID: <1417451112.13290.3.camel@sfr.com>

Le lundi 01 d?cembre 2014 ? 12:48 +0100, Peter Korsgaard <> a ?crit :
> >>>>> "DELOGET," == DELOGET, Emmanuel <emmanuel.deloget at sfr.com> writes:
> 
> Hi,
> 
> >> Thanks for the patch, I've applied it with small changes.
>  >> https://secure.ucc.asn.au/hg/dropbear/rev/fd2e8bbb0333
>  >> 
>  >> Emmanuel - thanks for the review. Dropbear already has
>  >> exit-on-failure m_strdup(), I'm using that. I'll avoid
>  >> O_DIRECTORY since it's fairly harmless to leave out and is a
>  >> portability hassle. I've made it open with O_RDWR though can't
>  >> actually see in the opengroup.org posix docs where that is
>  >> required for fsync?
> 
>  > Part of the problem has its root here: the POSIX standard does not say a
>  > word on this specific issue - so different UNIX have different
>  > implementation. I found at least two of them:
> 
>  > http://nixdoc.net/man-pages/irix/man2/fsync.2.html
>  > http://nixdoc.net/man-pages/Tru64/man2/fsync.2.html
> 
>  > Granted, there are not the primary target for dropbear :)
> 
>  > The linux man page warns about that issue in the Notes section:
> 
>  > http://linux.die.net/man/2/fsync
> 
>  > Additionnally, a good number of other UNIX (and other POSIX layers such
>  > as the one offered by eCos) doesn't say anything about that so it's hard
>  > to know how the implementation behaves without testing it.
> 
>  > I might be a bit over-prudent here and maybe noone will ever notice. But
>  > since it can lead to a nasty bug I think it's better to err on the side
>  > of safety :)
> 
> Actually it is the other way around. Something related came up today,
> and I finally now got to test what got committed. It doesn't work (on
> Linux atleast) as open on the parent directory fails with -EISDIR unless
> it is opened read only. This is also documented in the man page:
> 
> EISDIR pathname refers to a directory and the access requested involved
> writing (that is, O_WRONLY or O_RDWR is set).
> 
> The exact code handling it in the kernel is in fs/namei.c:
> 
> static int may_open(struct path *path, int acc_mode, int flag)
> {
>         struct dentry *dentry = path->dentry;
>         struct inode *inode = dentry->d_inode;
>         int error;
> 
>         /* O_PATH? */
>         if (!acc_mode)
>                 return 0;
> 
>         if (!inode)
>                 return -ENOENT;
> 
>         switch (inode->i_mode & S_IFMT) {
>         case S_IFLNK:
>                 return -ELOOP;
>         case S_IFDIR:
>                 if (acc_mode & MAY_WRITE)
>                         return -EISDIR;
>                 break;
>         ...
> 
> So we either need to change it back to O_RDONLY, or first try with
> O_RDWR and fall back to O_RDONLY if it fails with EISDIR in case other
> OSes require RDWR access for fsync.

The first thing that came to my mind is: "damned". That's sooo stretched
from a POSIX point of view! :)

> What are we going to do?

Either (option 1) go the road of a simple patch (keep O_RDONLY) and wait
for users to complain (this might never happen) or (option 2)
encapsulate fsync-on-a-directory into something that will work on any
systems (maybe with some configure magic here and there). 

Further reading on the Intarweb lead me to:

* Tru64 has been EOL'ed by HP [1]. Yet, dec-osf (another name for Tru64)
is still a dropbear target [2] so it might be interesting to keep it. 
* Last (minor) version of IRIX dates from 2005, and the OS has been
EOL'ed in 2006 [3].

So the only two occurences I found target OSes that are no longer
developped nor maintained. They might still be in use although I'm not
sure this use goes beyond hobbyism (I would not like to support a
discontinued platform as a professionnal). Option 1 above might be
enough for now. 

[1]http://fr.wikipedia.org/wiki/Tru64_UNIX
[2]https://secure.ucc.asn.au/hg/dropbear/file/fd2e8bbb0333/configure.ac#l68
[3]http://en.wikipedia.org/wiki/IRIX

In any case, I have to apologize for all that fuzz - it seems I've been
plain wrong on that case. I should have known better: test before you
assert something. This way, I would have seen that opening a directory
as writable was not possible. 

Sorry for that, 

-- Emmanuel Deloget



From josh at joshdubois.com  Thu Dec  4 08:10:08 2014
From: josh at joshdubois.com (Josh DuBois)
Date: Wed, 3 Dec 2014 18:10:08 -0600
Subject: android
Message-ID: <CCCFD02A-26F7-45ED-A205-FCF83F9EB866@joshdubois.com>

> Matt Johnston matt at ucc.asn.au 
> Thu Oct 23 20:56:50 WST 2014
> Hi Jed,
> 
> Android doesn't have all the normal auth functions. A
> patched Dropbear repository is at
> https://github.com/barryk/android_external_dropbear/network
Is there any chance of getting any of the things necessary to run dropbear on Android upstream, or is that not a desire of the dropbear maintainer(s)?  It seems it would be nice to have Android support upstream, given how popular it is as a platform.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141203/e9d3648e/attachment.htm 

From peter at korsgaard.com  Fri Dec  5 16:34:28 2014
From: peter at korsgaard.com (Peter Korsgaard)
Date: Fri, 05 Dec 2014 09:34:28 +0100
Subject: [PATCH] gensignkey: ensure host keys are flushed to disk
In-Reply-To: <1417451112.13290.3.camel@sfr.com> (Emmanuel DELOGET's message of
	"Mon, 1 Dec 2014 16:25:13 +0000")
References: <1414501886-20843-1-git-send-email-jacmet@sunsite.dk>
	<20141108142602.GH10430@ucc.gu.uwa.edu.au>
	<1415609670.29319.3.camel@sfr.com> <87r3wjh9pt.fsf@dell.be.48ers.dk>
	<1417451112.13290.3.camel@sfr.com>
Message-ID: <87h9xawl4b.fsf@dell.be.48ers.dk>

>>>>> "DELOGET," == DELOGET, Emmanuel <emmanuel.deloget at sfr.com> writes:

Hi,

 > In any case, I have to apologize for all that fuzz - it seems I've been
 > plain wrong on that case. I should have known better: test before you
 > assert something. This way, I would have seen that opening a directory
 > as writable was not possible. 

 > Sorry for that, 

No problem. Matt, how will we fix it? Unconditionally use O_RDONLY or
some kind of fallback?

-- 
Bye, Peter Korsgaard

From jdp5087 at gmail.com  Sat Dec 13 22:09:38 2014
From: jdp5087 at gmail.com (Jon Poler)
Date: Sat, 13 Dec 2014 09:09:38 -0500
Subject: Interest in Dropbear
Message-ID: <CAHB_798w9sM9W4hyokotqYi8P54PT+gYSbbhe8i--bAsrDM3hQ@mail.gmail.com>

Hello everyone!

I am glad to have discovered this project!

I am a self-taught programmer, who has been learning for about 1.5 years
now. I will be attending an unstructured "school" called "Hacker School"
for 3 months starting in January 2015, and I am actively searching for
interesting open-source projects to contribute to during my time there.

I am trying to get an idea of your vision for the future of Dropbear. Would
someone be able to comment on features that you would like to see added to
this project? If someone does find a few minutes to comment on this, please
keep in mind that my skill level is merely that of a novice, but I am very
willing to learn, and I will have a considerable chunk of time to dedicate
whichever project I may choose. I am particularly interested in network
programming in C and security.

Perhaps I am looking in the wrong places, but I am having difficulties
locating any sort of developer-oriented documentation. If any exists, would
someone please guide me to the stash? Also, if you see fit, maybe I could
try to write some rudimentary docs while I am sifting through the source
code anyway. Will someone suggest a good place for me to start reading?

I look forward to hearing from you!
Jon Poler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20141213/ae8e0335/attachment.htm 

From cengelma at gmx.at  Sun Dec 14 18:07:02 2014
From: cengelma at gmx.at (Christian Engelmayer)
Date: Sun, 14 Dec 2014 11:07:02 +0100
Subject: [PATCH] Fix structure clearance in openssh_read()
Message-ID: <1418551622-6605-1-git-send-email-cengelma@gmx.at>

When clearing the memory of 'key' in function openssh_read(), only the size
of the pointer to the data instead of the whole size of struct openssh_key
is cleared. Correct the size calculation as detected by Coverity CID 1191543.

Signed-off-by: Christian Engelmayer <cengelma at gmx.at>
---
 keyimport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/keyimport.c b/keyimport.c
index 66a7f55..2f9d3fa 100644
--- a/keyimport.c
+++ b/keyimport.c
@@ -810,7 +810,7 @@ static sign_key *openssh_read(const char *filename, char * UNUSED(passphrase))
 	}
 	m_burn(key->keyblob, key->keyblob_size);
 	m_free(key->keyblob);
-	m_burn(key, sizeof(key));
+	m_burn(key, sizeof(*key));
 	m_free(key);
 	if (errmsg) {
 		fprintf(stderr, "Error: %s\n", errmsg);
-- 
1.9.1