From SGupta at Limitedbrands.com  Fri Oct 17 02:44:13 2008
From: SGupta at Limitedbrands.com (Gupta, Sharad)
Date: Thu, 16 Oct 2008 14:44:13 -0400
Subject: SOCKS5
Message-ID: <1A31957B54EB9A4790850AC76D739A6D02FB48D2F1@COLEXCHMBXP01.Limited.brands.com>

Can I use dropbear server as a SOCKS proxy? Like:
ssh <user>@<dropbear-server> -D 8081

thanks
Sharad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081016/9165b563/attachment.htm 

From matt at ucc.asn.au  Fri Oct 17 07:38:29 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Fri, 17 Oct 2008 07:38:29 +0800
Subject: SOCKS5
In-Reply-To: <1A31957B54EB9A4790850AC76D739A6D02FB48D2F1@COLEXCHMBXP01.Limited.brands.com>
References: <1A31957B54EB9A4790850AC76D739A6D02FB48D2F1@COLEXCHMBXP01.Limited.brands.com>
Message-ID: <20081016233829.GA4444@ucc.gu.uwa.edu.au>

On Thu, Oct 16, 2008 at 02:44:13PM -0400, Gupta, Sharad wrote:
> Can I use dropbear server as a SOCKS proxy? Like:
> ssh <user>@<dropbear-server> -D 8081

That should work fine - all the socks-specific stuff is
going on in the client (as far as I know).

Cheers,
Matt

From vapier at gentoo.org  Tue Oct 21 13:01:56 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 21 Oct 2008 01:01:56 -0400
Subject: [PATCH] dropbear-051: uClinux vfork
In-Reply-To: <20080920155956.GF6061@shareable.org>
References: <3ba466150809191504l5599fd02l7a2278b955dd7367@mail.gmail.com>
	<20080920155956.GF6061@shareable.org>
Message-ID: <200810210101.57652.vapier@gentoo.org>

On Saturday 20 September 2008, Jamie Lokier wrote:
> Farrell Aultman wrote:
> > Between dropbear-047 and dropbear-051 changes were made that
> > accounted for the fact that uClinux needs to use vfork instead of
> > fork.  However, fork was not replaced with vfork in all places.  I
> > moved the conditional preproccessor check for uClinux into the
> > includes.h file, so that fork is always replaced with vfork in all
> > of the dropbear code when compiling for uClinux.  A side effect is
> > that the code is cleaner since you just call fork without wrapping
> > it every time with a conditional preprocessor check.
>
> Have you checked that it's safe to call vfork in all those places?
>
> vfork is not always a safe replacement for fork, even on uClinux where
> fork doesn't work.

it istn safe.  the exit() calls need to be updated too.  the patch i wrote is 
here (i could have sworn i posted it already):
--- dropbear-0.51/scp.c
+++ dropbear-0.51/scp.c
@@ -130,13 +130,22 @@
 			fprintf(stderr, " %s", a->list[i]);
 		fprintf(stderr, "\n");
 	}
-	if ((pid = fork()) == -1)
+#ifdef __uClinux__
+	pid = vfork();
+#else
+	pid = fork();
+#endif /* __uClinux__ */
+	if (pid == -1)
 		fatal("do_local_cmd: fork: %s", strerror(errno));
 
 	if (pid == 0) {
 		execvp(a->list[0], a->list);
 		perror(a->list[0]);
+#ifdef __uClinux__
+		_exit(1);
+#else
 		exit(1);
+#endif /* __uClinux__ */
 	}
 
 	do_cmd_pid = pid;
@@ -225,7 +234,11 @@
 
 		execvp(ssh_program, args.list);
 		perror(ssh_program);
+#ifndef __uClinux__
 		exit(1);
+#else
+		_exit(1);
+#endif /* __uClinux__ */
 	} else if (do_cmd_pid == -1) {
 		fatal("fork: %s", strerror(errno));
 	}
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081021/2a9ceb33/attachment.pgp 

From vapier at gentoo.org  Tue Oct 21 13:01:56 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 21 Oct 2008 01:01:56 -0400
Subject: [PATCH] dropbear-051: uClinux vfork
In-Reply-To: <20080920155956.GF6061@shareable.org>
References: <3ba466150809191504l5599fd02l7a2278b955dd7367@mail.gmail.com>
	<20080920155956.GF6061@shareable.org>
Message-ID: <200810210101.57652.vapier@gentoo.org>

On Saturday 20 September 2008, Jamie Lokier wrote:
> Farrell Aultman wrote:
> > Between dropbear-047 and dropbear-051 changes were made that
> > accounted for the fact that uClinux needs to use vfork instead of
> > fork.  However, fork was not replaced with vfork in all places.  I
> > moved the conditional preproccessor check for uClinux into the
> > includes.h file, so that fork is always replaced with vfork in all
> > of the dropbear code when compiling for uClinux.  A side effect is
> > that the code is cleaner since you just call fork without wrapping
> > it every time with a conditional preprocessor check.
>
> Have you checked that it's safe to call vfork in all those places?
>
> vfork is not always a safe replacement for fork, even on uClinux where
> fork doesn't work.

it istn safe.  the exit() calls need to be updated too.  the patch i wrote is 
here (i could have sworn i posted it already):
--- dropbear-0.51/scp.c
+++ dropbear-0.51/scp.c
@@ -130,13 +130,22 @@
 			fprintf(stderr, " %s", a->list[i]);
 		fprintf(stderr, "\n");
 	}
-	if ((pid = fork()) == -1)
+#ifdef __uClinux__
+	pid = vfork();
+#else
+	pid = fork();
+#endif /* __uClinux__ */
+	if (pid == -1)
 		fatal("do_local_cmd: fork: %s", strerror(errno));
 
 	if (pid == 0) {
 		execvp(a->list[0], a->list);
 		perror(a->list[0]);
+#ifdef __uClinux__
+		_exit(1);
+#else
 		exit(1);
+#endif /* __uClinux__ */
 	}
 
 	do_cmd_pid = pid;
@@ -225,7 +234,11 @@
 
 		execvp(ssh_program, args.list);
 		perror(ssh_program);
+#ifndef __uClinux__
 		exit(1);
+#else
+		_exit(1);
+#endif /* __uClinux__ */
 	} else if (do_cmd_pid == -1) {
 		fatal("fork: %s", strerror(errno));
 	}
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081021/2a9ceb33/attachment-0001.pgp 

From fja0568 at gmail.com  Wed Oct 22 22:41:04 2008
From: fja0568 at gmail.com (Farrell Aultman)
Date: Wed, 22 Oct 2008 10:41:04 -0400
Subject: [PATCH] dropbear-051: uClinux vfork
In-Reply-To: <200810210101.57652.vapier@gentoo.org>
References: <3ba466150809191504l5599fd02l7a2278b955dd7367@mail.gmail.com>
	<20080920155956.GF6061@shareable.org>
	<200810210101.57652.vapier@gentoo.org>
Message-ID: <3ba466150810220741s677b905ay1671d5d78c2f1b44@mail.gmail.com>

Again, it would be better to do something like the following in includes.h:
+#ifdef __uClinux__
+#define exit(x) _exit(x)
+#endif

On Tue, Oct 21, 2008 at 1:01 AM, Mike Frysinger <vapier at gentoo.org> wrote:

> On Saturday 20 September 2008, Jamie Lokier wrote:
> > Farrell Aultman wrote:
> > > Between dropbear-047 and dropbear-051 changes were made that
> > > accounted for the fact that uClinux needs to use vfork instead of
> > > fork.  However, fork was not replaced with vfork in all places.  I
> > > moved the conditional preproccessor check for uClinux into the
> > > includes.h file, so that fork is always replaced with vfork in all
> > > of the dropbear code when compiling for uClinux.  A side effect is
> > > that the code is cleaner since you just call fork without wrapping
> > > it every time with a conditional preprocessor check.
> >
> > Have you checked that it's safe to call vfork in all those places?
> >
> > vfork is not always a safe replacement for fork, even on uClinux where
> > fork doesn't work.
>
> it istn safe.  the exit() calls need to be updated too.  the patch i wrote
> is
> here (i could have sworn i posted it already):
> --- dropbear-0.51/scp.c
> +++ dropbear-0.51/scp.c
> @@ -130,13 +130,22 @@
>                        fprintf(stderr, " %s", a->list[i]);
>                fprintf(stderr, "\n");
>        }
> -       if ((pid = fork()) == -1)
> +#ifdef __uClinux__
> +       pid = vfork();
> +#else
> +       pid = fork();
> +#endif /* __uClinux__ */
> +       if (pid == -1)
>                fatal("do_local_cmd: fork: %s", strerror(errno));
>
>        if (pid == 0) {
>                execvp(a->list[0], a->list);
>                perror(a->list[0]);
> +#ifdef __uClinux__
> +               _exit(1);
> +#else
>                exit(1);
> +#endif /* __uClinux__ */
>        }
>
>        do_cmd_pid = pid;
> @@ -225,7 +234,11 @@
>
>                execvp(ssh_program, args.list);
>                perror(ssh_program);
> +#ifndef __uClinux__
>                exit(1);
> +#else
> +               _exit(1);
> +#endif /* __uClinux__ */
>        } else if (do_cmd_pid == -1) {
>                fatal("fork: %s", strerror(errno));
>        }
> -mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081022/b3954dca/attachment.htm 

From fja0568 at gmail.com  Wed Oct 22 22:41:04 2008
From: fja0568 at gmail.com (Farrell Aultman)
Date: Wed, 22 Oct 2008 10:41:04 -0400
Subject: [PATCH] dropbear-051: uClinux vfork
In-Reply-To: <200810210101.57652.vapier@gentoo.org>
References: <3ba466150809191504l5599fd02l7a2278b955dd7367@mail.gmail.com>
	<20080920155956.GF6061@shareable.org>
	<200810210101.57652.vapier@gentoo.org>
Message-ID: <3ba466150810220741s677b905ay1671d5d78c2f1b44@mail.gmail.com>

Again, it would be better to do something like the following in includes.h:
+#ifdef __uClinux__
+#define exit(x) _exit(x)
+#endif

On Tue, Oct 21, 2008 at 1:01 AM, Mike Frysinger <vapier at gentoo.org> wrote:

> On Saturday 20 September 2008, Jamie Lokier wrote:
> > Farrell Aultman wrote:
> > > Between dropbear-047 and dropbear-051 changes were made that
> > > accounted for the fact that uClinux needs to use vfork instead of
> > > fork.  However, fork was not replaced with vfork in all places.  I
> > > moved the conditional preproccessor check for uClinux into the
> > > includes.h file, so that fork is always replaced with vfork in all
> > > of the dropbear code when compiling for uClinux.  A side effect is
> > > that the code is cleaner since you just call fork without wrapping
> > > it every time with a conditional preprocessor check.
> >
> > Have you checked that it's safe to call vfork in all those places?
> >
> > vfork is not always a safe replacement for fork, even on uClinux where
> > fork doesn't work.
>
> it istn safe.  the exit() calls need to be updated too.  the patch i wrote
> is
> here (i could have sworn i posted it already):
> --- dropbear-0.51/scp.c
> +++ dropbear-0.51/scp.c
> @@ -130,13 +130,22 @@
>                        fprintf(stderr, " %s", a->list[i]);
>                fprintf(stderr, "\n");
>        }
> -       if ((pid = fork()) == -1)
> +#ifdef __uClinux__
> +       pid = vfork();
> +#else
> +       pid = fork();
> +#endif /* __uClinux__ */
> +       if (pid == -1)
>                fatal("do_local_cmd: fork: %s", strerror(errno));
>
>        if (pid == 0) {
>                execvp(a->list[0], a->list);
>                perror(a->list[0]);
> +#ifdef __uClinux__
> +               _exit(1);
> +#else
>                exit(1);
> +#endif /* __uClinux__ */
>        }
>
>        do_cmd_pid = pid;
> @@ -225,7 +234,11 @@
>
>                execvp(ssh_program, args.list);
>                perror(ssh_program);
> +#ifndef __uClinux__
>                exit(1);
> +#else
> +               _exit(1);
> +#endif /* __uClinux__ */
>        } else if (do_cmd_pid == -1) {
>                fatal("fork: %s", strerror(errno));
>        }
> -mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081022/b3954dca/attachment-0001.htm 

From vapier at gentoo.org  Thu Oct 23 07:46:10 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 22 Oct 2008 19:46:10 -0400
Subject: [PATCH] dropbear-051: uClinux vfork
In-Reply-To: <3ba466150810220741s677b905ay1671d5d78c2f1b44@mail.gmail.com>
References: <3ba466150809191504l5599fd02l7a2278b955dd7367@mail.gmail.com>
	<200810210101.57652.vapier@gentoo.org>
	<3ba466150810220741s677b905ay1671d5d78c2f1b44@mail.gmail.com>
Message-ID: <200810221946.11680.vapier@gentoo.org>

On Wednesday 22 October 2008, Farrell Aultman wrote:
> Again, it would be better to do something like the following in includes.h:
> +#ifdef __uClinux__
> +#define exit(x) _exit(x)
> +#endif

no it wouldnt.  _exit() is *only* for when the child of a vfork() needs to 
exit without calling an exec function.  blindly macroing it away would affect 
every other case as well.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081022/42ba7c00/attachment.pgp 

From vapier at gentoo.org  Thu Oct 23 07:46:10 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 22 Oct 2008 19:46:10 -0400
Subject: [PATCH] dropbear-051: uClinux vfork
In-Reply-To: <3ba466150810220741s677b905ay1671d5d78c2f1b44@mail.gmail.com>
References: <3ba466150809191504l5599fd02l7a2278b955dd7367@mail.gmail.com>
	<200810210101.57652.vapier@gentoo.org>
	<3ba466150810220741s677b905ay1671d5d78c2f1b44@mail.gmail.com>
Message-ID: <200810221946.11680.vapier@gentoo.org>

On Wednesday 22 October 2008, Farrell Aultman wrote:
> Again, it would be better to do something like the following in includes.h:
> +#ifdef __uClinux__
> +#define exit(x) _exit(x)
> +#endif

no it wouldnt.  _exit() is *only* for when the child of a vfork() needs to 
exit without calling an exec function.  blindly macroing it away would affect 
every other case as well.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081022/42ba7c00/attachment-0001.pgp 

From rob at landley.net  Thu Oct 23 10:01:58 2008
From: rob at landley.net (Rob Landley)
Date: Wed, 22 Oct 2008 21:01:58 -0500
Subject: [PATCH] dropbear-051: uClinux vfork
In-Reply-To: <200810210101.57652.vapier@gentoo.org>
References: <3ba466150809191504l5599fd02l7a2278b955dd7367@mail.gmail.com>
	<20080920155956.GF6061@shareable.org>
	<200810210101.57652.vapier@gentoo.org>
Message-ID: <200810222101.58936.rob@landley.net>

On Tuesday 21 October 2008 00:01:56 Mike Frysinger wrote:
> -	if ((pid = fork()) == -1)
> +#ifdef __uClinux__
> +	pid = vfork();
> +#else
> +	pid = fork();
> +#endif /* __uClinux__ */
> +	if (pid == -1)
>  		fatal("do_local_cmd: fork: %s", strerror(errno));

If it's ever safe to call vfork() from a given place, then it should always be 
safe to call it from that place, so the #ifdef isn't really necessary.

Although vfork() has more restrictive semantics than fork() does, it's not 
really less efficient than doing a fork().  Just less flexible.  A system 
with an mmu can do a vfork() just fine, so if you've cleared that it's ok to 
use it there, there's no real reason for not to just do it all the time.  In 
fact, being consistent means you have a single codepath and the same behavior 
on uClinux as everywhere else.

Rob


From michael.wiedmann at aastra.com  Thu Oct 23 16:34:56 2008
From: michael.wiedmann at aastra.com (Michael Wiedmann)
Date: Thu, 23 Oct 2008 10:34:56 +0200
Subject: 'IPC'  between dropbear master and child processes
Message-ID: <448067AB8643614285E9B1DC376F273C0241F84C@bermail.de.aastra.com>

Hi,

I'm evaluating to use 'dropbear' as an SSH server (on Cygwin) for the following scenario:

Embedded devices contact the central dropbear server as clients requesting 'remote port forwarding' for two local ports (23 and 80) which are used to configure the embedded devices.

This works in general very well.

I need visualize all ssh connections in a Web application to let the 'admin' monitor/control them. Therefore I need some kind of list of all connections in the 'master' process. This list can be provided to the Web application (.NET) using some IPC  system (still has to be determined).

Now I'm looking for the easiest way to communicate from the forked child processes to the master process. The information needed from the child processes are mainly the chosen forwarded ports and the remote IP address (to be able to display a link in the web browser for any given embedded device).

I've seen the 'childpipes' but I'm not sure what are they used for. 

Can I use the 'childpipe' (which is passed to 'svr_session(...)' as an argument and stored in the 'struct serversession') to write back to the master server process
(I've seen the comment 'kept open until we successfully authenticate' in 'session.h')?

Another solution would be to use Unix domain sockets as IPC between the processes.

Any hints/remarks would be highly appreciated.

Cheers
Michael


From vapier at gentoo.org  Thu Oct 23 16:51:17 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 23 Oct 2008 04:51:17 -0400
Subject: [PATCH] dropbear-051: uClinux vfork
In-Reply-To: <200810222101.58936.rob@landley.net>
References: <3ba466150809191504l5599fd02l7a2278b955dd7367@mail.gmail.com>
	<200810210101.57652.vapier@gentoo.org>
	<200810222101.58936.rob@landley.net>
Message-ID: <200810230451.17674.vapier@gentoo.org>

On Wednesday 22 October 2008, Rob Landley wrote:
> On Tuesday 21 October 2008 00:01:56 Mike Frysinger wrote:
> > -	if ((pid = fork()) == -1)
> > +#ifdef __uClinux__
> > +	pid = vfork();
> > +#else
> > +	pid = fork();
> > +#endif /* __uClinux__ */
> > +	if (pid == -1)
> >  		fatal("do_local_cmd: fork: %s", strerror(errno));
>
> If it's ever safe to call vfork() from a given place, then it should always
> be safe to call it from that place, so the #ifdef isn't really necessary.
>
> Although vfork() has more restrictive semantics than fork() does, it's not
> really less efficient than doing a fork().  Just less flexible.  A system
> with an mmu can do a vfork() just fine, so if you've cleared that it's ok
> to use it there, there's no real reason for not to just do it all the time.
>  In fact, being consistent means you have a single codepath and the same
> behavior on uClinux as everywhere else.

this is certainly all true ... ive just given up on trying to convince people 
as vfork() tends to scare them.  especially if they dont understand vfork() 
semantics and the app starts behaving in ways they dont recognize.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081023/901700f7/attachment.pgp 

From jamie at shareable.org  Thu Oct 23 18:12:03 2008
From: jamie at shareable.org (Jamie Lokier)
Date: Thu, 23 Oct 2008 11:12:03 +0100
Subject: [PATCH] dropbear-051: uClinux vfork
In-Reply-To: <200810222101.58936.rob@landley.net>
References: <3ba466150809191504l5599fd02l7a2278b955dd7367@mail.gmail.com>
	<20080920155956.GF6061@shareable.org>
	<200810210101.57652.vapier@gentoo.org>
	<200810222101.58936.rob@landley.net>
Message-ID: <20081023101203.GB19801@shareable.org>

Rob Landley wrote:
> On Tuesday 21 October 2008 00:01:56 Mike Frysinger wrote:
> > -	if ((pid = fork()) == -1)
> > +#ifdef __uClinux__
> > +	pid = vfork();
> > +#else
> > +	pid = fork();
> > +#endif /* __uClinux__ */
> > +	if (pid == -1)
> >  		fatal("do_local_cmd: fork: %s", strerror(errno));
> 
> If it's ever safe to call vfork() from a given place, then it should
> always be safe to call it from that place, so the #ifdef isn't
> really necessary.

Not always true.  This is true if you're following the portable rules
for what a vfork-child can do, or if you expect the code to only run
on Linux.

On uClinux (and Linux), a vfork-child can get away with quite a lot of
things that are not safe on other OSes.  For example, malloc() and
printf() are probably fine, because they update memory in the same way
as the parent would anyway.  Thread-local storage keys off the stack
address, if you're using LinuxThreads not NPTL, so again the
vfork-child updates memory the same way as the parent.  Setting signal
handlers or masks in the vfork-child are fine and don't affect the
parent in Linux, same for chdir().  execvp() is ok, even though that
calls malloc() (in at least one Glibc version I looked at).

In my own library of portable code, I use vfork() on OSes where either
the child is following the very restrictive rules, or it's uClinux and
there's no choice and it'll work when the child doesn't follow all the
rules.  I don't use vfork() for daemon() though, as that doesn't work
(I've seen some uClinux patches do that and it's just broken); clone()
works for that.  I get nervous when it's uClinux _and_ threaded. :-)

-- Jamie


From vapier at gentoo.org  Thu Oct 23 18:43:19 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 23 Oct 2008 06:43:19 -0400
Subject: [PATCH] dropbear-051: uClinux vfork
In-Reply-To: <20081023101203.GB19801@shareable.org>
References: <3ba466150809191504l5599fd02l7a2278b955dd7367@mail.gmail.com>
	<200810222101.58936.rob@landley.net>
	<20081023101203.GB19801@shareable.org>
Message-ID: <200810230643.20533.vapier@gentoo.org>

On Thursday 23 October 2008, Jamie Lokier wrote:
> execvp() is ok, even though that
> calls malloc() (in at least one Glibc version I looked at).

yes, most of the exec calls need memory in order to construct an argv[] based 
on the function arguments.  in glibc, i imagine that the memory leaked is 
permanently lost (although ive never looked at the glibc implementation).  in 
uClibc we minimize the leakage by re-using it in the next call to exec that 
needs memory.

thanks for the other tidbits
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081023/fea1a754/attachment.pgp 

From rob at landley.net  Thu Oct 23 18:50:30 2008
From: rob at landley.net (Rob Landley)
Date: Thu, 23 Oct 2008 05:50:30 -0500
Subject: [PATCH] dropbear-051: uClinux vfork
In-Reply-To: <200810230451.17674.vapier@gentoo.org>
References: <3ba466150809191504l5599fd02l7a2278b955dd7367@mail.gmail.com>
	<200810222101.58936.rob@landley.net>
	<200810230451.17674.vapier@gentoo.org>
Message-ID: <200810230550.30741.rob@landley.net>

On Thursday 23 October 2008 03:51:17 Mike Frysinger wrote:
> On Wednesday 22 October 2008, Rob Landley wrote:
> > On Tuesday 21 October 2008 00:01:56 Mike Frysinger wrote:
> > > -	if ((pid = fork()) == -1)
> > > +#ifdef __uClinux__
> > > +	pid = vfork();
> > > +#else
> > > +	pid = fork();
> > > +#endif /* __uClinux__ */
> > > +	if (pid == -1)
> > >  		fatal("do_local_cmd: fork: %s", strerror(errno));
> >
> > If it's ever safe to call vfork() from a given place, then it should
> > always be safe to call it from that place, so the #ifdef isn't really
> > necessary.
> >
> > Although vfork() has more restrictive semantics than fork() does, it's
> > not really less efficient than doing a fork().  Just less flexible.  A
> > system with an mmu can do a vfork() just fine, so if you've cleared that
> > it's ok to use it there, there's no real reason for not to just do it all
> > the time. In fact, being consistent means you have a single codepath and
> > the same behavior on uClinux as everywhere else.
>
> this is certainly all true ... ive just given up on trying to convince
> people as vfork() tends to scare them.  especially if they dont understand
> vfork() semantics and the app starts behaving in ways they dont recognize.

Dropbear's maintained by a smart guy, I think he can cope.

I remember I wrote up some extensive vfork() documentation, but I suspect it 
was when I was working for timesys and they probably put it on their 
proprietary customer-only mailing list so you have a to pay them to see it.  
I could write up another one, I suppose, but I remember getting all the 
details right in the explanation was fiddly.  Here's a quick "sort of wrong 
but you'll understand how to use it" explanation.

You can sort of treat vfork() as a sort of kernel-side setjmp().  After 
vfork(), you still only have one process running, you've just told the kernel 
to checkpoint the old state.  As soon as you do an exec() it'll launch the 
new process and longjmp() the current process back to the vfork() point.  As 
with all uses of setjmp()/longjmp(), if you've changed the stack or the heap 
since then it's still that way after the longjmp(), so you really really 
don't want to do things like return from the function that called vfork() 
before calling exec() to longjmp() you back to the vfork() point.

Telling the process to exit() also does the longjmp() thing (gotta have a way 
to clean up if the exec() fails), but the problem is that exit() also 
does "cleanup" work (it closes stdout, frees memory, and calls atexit(), and 
who knows what else), and doing a longjmp() back into the middle of the 
program after closing down stdio isn't going to end well.  But since it's the 
exit _system_call_ that does the longjmp() back to the vfork() checkpoint 
(remember, vfork() is handled by the kernel, not by libc) then you can use 
the special _exit() call which just callsthe system call without flushing 
stdout or calling atexit() or any of the other "cleanup" things.  (You _only_ 
want to do that to trigger the longjmp() back to the vfork() point, 
ordinarily you _want_ the cleanup exit() does.)

This explanation isn't quite what the kernel's actually doing behind the 
scenes, but it should give you a good mental model of how to use vfork.  
Treat is as a setjmp() that makes the next exec() or _exit() system call act 
like a longjmp() (and makes exec() spawn a new process).

This whole song and dance is simply to avoid having to do "copy on write" 
memory mappings, which fork() relies on and which a nommu system hasn't got 
hardware support for.

Sigh, I should write up some new vfork documentation.  The vfork man page is 
useless...

> -mike

Rob


From brent at mbari.org  Tue Oct 28 12:46:51 2008
From: brent at mbari.org (Brent Roman)
Date: Mon, 27 Oct 2008 20:46:51 -0700
Subject: [PATCH]  Allow coredumps
Message-ID: <750D5B1F-DABB-447A-9EDF-C496AE71A43C@mbari.org>

This is a patch to v0.51 that introduces a new configure time option
ALLOW_COREDUMPS
to allow coredumps from processes
started via dropbear server (and client)

It conditionally rolls back a change introduced around version 0.49
In some environments, coredumps are a very useful debugging tool.

  Brent Roman
  mailto:brent at mbari.org  http://www.mbari.org/~brent


--- dropbear-0.51-original/dbutil.c	2008-10-27 15:31:08.000000000 -0700
+++ dropbear-0.51/dbutil.c	2008-10-27 15:38:01.000000000 -0700
@@ -694,8 +694,10 @@
  	TRACE(("leave setnonblocking"))
  }

+#ifndef ALLOW_COREDUMPS
  void disallow_core() {
  	struct rlimit lim;
  	lim.rlim_cur = lim.rlim_max = 0;
  	setrlimit(RLIMIT_CORE, &lim);
  }
+#endif
--- dropbear-0.51-original/dbutil.h	2008-10-27 17:32:04.000000000 -0700
+++ dropbear-0.51/dbutil.h	2008-10-27 17:32:43.000000000 -0700
@@ -63,7 +63,13 @@
  void __m_free(void* ptr);
  void m_burn(void* data, unsigned int len);
  void setnonblocking(int fd);
+
+#ifdef ALLOW_COREDUMPS
+#define disallow_core()
+#else
  void disallow_core();
+#endif
+

  /* Used to force mp_ints to be initialised */
  #define DEF_MP_INT(X) mp_int X = {0, 0, 0, NULL}

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

From maszuari at gmail.com  Tue Oct 28 14:43:05 2008
From: maszuari at gmail.com (Noor Maszuari)
Date: Tue, 28 Oct 2008 13:43:05 +0800
Subject: How to setup SSH tunneling in dropbear?
Message-ID: <3bb3f3af0810272243r23ca7ec9t8b67a3752da543af@mail.gmail.com>

Hi,
I'm newbie in dropbear and I would like to know how to setup SSH tunneling
using dropbear?
What if I use private key that is generated by PuTTYgen and the location of
the private key is /home/abc/xyz/pk.ppk?
How is my command line looks like?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081028/9abbf6c2/attachment.htm 

From matt at ucc.asn.au  Tue Oct 28 18:48:15 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 28 Oct 2008 18:48:15 +0900
Subject: [PATCH]  Allow coredumps
In-Reply-To: <750D5B1F-DABB-447A-9EDF-C496AE71A43C@mbari.org>
References: <750D5B1F-DABB-447A-9EDF-C496AE71A43C@mbari.org>
Message-ID: <20081028094815.GE4444@ucc.gu.uwa.edu.au>

On Mon, Oct 27, 2008 at 08:46:51PM -0700, Brent Roman wrote:
> This is a patch to v0.51 that introduces a new configure time option
> ALLOW_COREDUMPS
> to allow coredumps from processes
> started via dropbear server (and client)
> 
> It conditionally rolls back a change introduced around version 0.49
> In some environments, coredumps are a very useful debugging tool.

Thanks for the patch. The change was introduced to avoid
leaving sensitive details like passwords about in core dump
files (perhaps overly paranoid? - should a separate ulimit
be enforcing that anyway...). The #ifdef makes sense.

Cheers,
Matt

From mingching.tiew at redtone.com  Tue Oct 28 19:06:16 2008
From: mingching.tiew at redtone.com (Ming-Ching Tiew)
Date: Tue, 28 Oct 2008 18:06:16 +0800
Subject: show more details in failed attempts in the syslog
References: <750D5B1F-DABB-447A-9EDF-C496AE71A43C@mbari.org>
	<20081028094815.GE4444@ucc.gu.uwa.edu.au>
Message-ID: <01ed01c938e4$d113e250$8119fea9@MingChing>


I am wondering if it makes sense to put failed 
attempts to login into the syslog including the
information like user and password ?

Right now it only logs information that there 
is a failed attempt when there is invalid user. 

The motivation for writing these information into
syslog is to figure out if there is an auditable trail
of the brute force attempts ( example dictionary attack )
or just the user forgot the password.

I supposed the downside this scheme is that 
whoever got hold of read access to the log 
will know what is considered invalid attempts ?

Any comments ?


From matt at ucc.asn.au  Tue Oct 28 21:16:34 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 28 Oct 2008 21:16:34 +0900
Subject: show more details in failed attempts in the syslog
In-Reply-To: <01ed01c938e4$d113e250$8119fea9@MingChing>
References: <750D5B1F-DABB-447A-9EDF-C496AE71A43C@mbari.org>
	<20081028094815.GE4444@ucc.gu.uwa.edu.au>
	<01ed01c938e4$d113e250$8119fea9@MingChing>
Message-ID: <20081028121634.GF4444@ucc.gu.uwa.edu.au>

On Tue, Oct 28, 2008 at 06:06:16PM +0800, Ming-Ching Tiew wrote:
> 
> I am wondering if it makes sense to put failed 
> attempts to login into the syslog including the
> information like user and password ?
> 
> Right now it only logs information that there 
> is a failed attempt when there is invalid user. 
> 
> The motivation for writing these information into
> syslog is to figure out if there is an auditable trail
> of the brute force attempts ( example dictionary attack )
> or just the user forgot the password.
> 
> I supposed the downside this scheme is that 
> whoever got hold of read access to the log 
> will know what is considered invalid attempts ?

The problem with logging invalid usernames is that the
invalid username may actually be the valid password. As you
noted, while the logs are secure for that machine, it's
nicer not to be storing sensitive information there. I
personally have found myself typing my password instead of
username a few times when using PuTTY, just because the
order of prompts is different to Unix clients. Avoiding
logging usernames was shamelessly taken from OpenSSH, I
think it makes sense. If the username is valid, it will get
logged.

Also, it takes a fair amount of time to perform an online brute
force attack against an SSH server. Attackers tend to use
simple passwords ("chicken" and "alex" were two examples I've seen
guessed that way). It would seem much better to concentrate
your defensive efforts on just running John or similar on
/etc/passwd every now and then.

Matt

From mingching.tiew at redtone.com  Wed Oct 29 10:52:48 2008
From: mingching.tiew at redtone.com (Ming-Ching Tiew)
Date: Wed, 29 Oct 2008 09:52:48 +0800
Subject: show more details in failed attempts in the syslog
References: <750D5B1F-DABB-447A-9EDF-C496AE71A43C@mbari.org>
	<20081028094815.GE4444@ucc.gu.uwa.edu.au>
	<01ed01c938e4$d113e250$8119fea9@MingChing>
	<20081028121634.GF4444@ucc.gu.uwa.edu.au>
Message-ID: <002f01c93969$0f36d1d0$8119fea9@MingChing>

Matt Johnston wrote:
> 
> Also, it takes a fair amount of time to perform an online brute
> force attack against an SSH server. Attackers tend to use
> simple passwords ("chicken" and "alex" were two examples I've seen
> guessed that way). It would seem much better to concentrate
> your defensive efforts on just running John or similar on
> /etc/passwd every now and then.
> 

Well I agree with you that there is some sensitivity regarding
logging invalid username and password, however the motivation
here is not so much of "defence". It's more like an "audit trail",
or a proof of someone intentionally attempting an attack and it
is not casual or accidental.

Just to clarify.

Regards.


From michael.wiedmann at aastra.com  Thu Oct 30 22:37:44 2008
From: michael.wiedmann at aastra.com (Michael Wiedmann)
Date: Thu, 30 Oct 2008 14:37:44 +0100
Subject: More than one remote port fwd request for the same local port
Message-ID: <448067AB8643614285E9B1DC376F273C0241F85A@bermail.de.aastra.com>

Hi,

how deals dropbear with different clients which are requesting each a remote port forwarding to the same local port (on the server side), e.g.

system-1> dbclient -l user1 -N -R 7777:client-ip-1:80 server-ip
...
system-2> dbclient -l user2 -N -R 7777:client-ip-2:80 server-ip

Doing a quick test it looks like dropbear accepts the client requests but the port forwarding does not work (actually it cannot because there is more than one 'target').

Cheers
Michael


From matt at ucc.asn.au  Thu Oct 30 22:45:00 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 30 Oct 2008 22:45:00 +0900
Subject: More than one remote port fwd request for the same local port
In-Reply-To: <448067AB8643614285E9B1DC376F273C0241F85A@bermail.de.aastra.com>
References: <448067AB8643614285E9B1DC376F273C0241F85A@bermail.de.aastra.com>
Message-ID: <20081030134500.GG4444@ucc.gu.uwa.edu.au>

On Thu, Oct 30, 2008 at 02:37:44PM +0100, Michael Wiedmann wrote:
> Hi,
> 
> how deals dropbear with different clients which are requesting each a remote port forwarding to the same local port (on the server side), e.g.
> 
> system-1> dbclient -l user1 -N -R 7777:client-ip-1:80 server-ip
> ...
> system-2> dbclient -l user2 -N -R 7777:client-ip-2:80 server-ip
> 
> Doing a quick test it looks like dropbear accepts the client requests but the port forwarding does not work (actually it cannot because there is more than one 'target').

Unix sockets inherently only allow a single process (so a
single user) to listen on a port. What behaviour would
you expect?

Matt

From mingching.tiew at redtone.com  Fri Oct 31 10:10:35 2008
From: mingching.tiew at redtone.com (Ming-Ching Tiew)
Date: Fri, 31 Oct 2008 09:10:35 +0800
Subject: More than one remote port fwd request for the same local port
References: <448067AB8643614285E9B1DC376F273C0241F85A@bermail.de.aastra.com>
	<20081030134500.GG4444@ucc.gu.uwa.edu.au>
Message-ID: <002301c93af5$7adef380$8119fea9@MingChing>

Matt Johnston wrote:
> On Thu, Oct 30, 2008 at 02:37:44PM +0100, Michael Wiedmann wrote:
>> Hi,
>> 
>> how deals dropbear with different clients which are requesting each
>> a remote port forwarding to the same local port (on the server
>> side), e.g.  
>> 
>> system-1> dbclient -l user1 -N -R 7777:client-ip-1:80 server-ip
>> ...
>> system-2> dbclient -l user2 -N -R 7777:client-ip-2:80 server-ip
>> 
>> Doing a quick test it looks like dropbear accepts the client
>> requests but the port forwarding does not work (actually it cannot
>> because there is more than one 'target').  
> 
> Unix sockets inherently only allow a single process (so a
> single user) to listen on a port. What behaviour would
> you expect?
> 

I do face the same issue. In my usage, more than one system
execute the same command ( ie client-ip is actually one only )
and I don't run any remote shell, the sole purpose of the 
dbclient connection is to establish remote port forward, I 
would prefer the last command succeed and it drops the previous 
connection. However, I do realise  such a behaviour is rather
 "unfair".

Of course the other implementation is to fail the second
command. If there is not remote shell executed, then I 
would imagine this is a fair behaviour. However, what
happens if there is a remote shell to be executed and
it succeeds ? Should it be all or nothing, or should it be
as long as the remote shell succeeds ?

Since the second behaviour cannot really achieve what
I wish to achieve, so I have been keeping quiet about it.

Regards.




From mingching.tiew at redtone.com  Fri Oct 31 10:17:04 2008
From: mingching.tiew at redtone.com (Ming-Ching Tiew)
Date: Fri, 31 Oct 2008 09:17:04 +0800
Subject: More than one remote port fwd request for the same local port
References: <448067AB8643614285E9B1DC376F273C0241F85A@bermail.de.aastra.com><20081030134500.GG4444@ucc.gu.uwa.edu.au>
	<002301c93af5$7adef380$8119fea9@MingChing>
Message-ID: <005701c93af6$649a00f0$8119fea9@MingChing>

Ming-Ching Tiew wrote:
> Matt Johnston wrote:
>> On Thu, Oct 30, 2008 at 02:37:44PM +0100, Michael Wiedmann wrote:
>>> Hi,
>>> 
>>> how deals dropbear with different clients which are requesting each
>>> a remote port forwarding to the same local port (on the server
>>> side), e.g.
>>> 
>>> system-1> dbclient -l user1 -N -R 7777:client-ip-1:80 server-ip
>>> ...
>>> system-2> dbclient -l user2 -N -R 7777:client-ip-2:80 server-ip
>>> 
>>> Doing a quick test it looks like dropbear accepts the client
>>> requests but the port forwarding does not work (actually it cannot
>>> because there is more than one 'target').
>> 
>> Unix sockets inherently only allow a single process (so a
>> single user) to listen on a port. What behaviour would
>> you expect?
>> 
> 
> I do face the same issue. In my usage, more than one system
> execute the same command ( ie client-ip is actually one only )
> and I don't run any remote shell, the sole purpose of the
> dbclient connection is to establish remote port forward, I
> would prefer the last command succeed and it drops the previous
> connection. However, I do realise  such a behaviour is rather
>  "unfair".
> 

And I did try implement a remote shell method to solve my 
problem, but I was stuck at a stage where I could not identify
the correct dropbear server process  to kill ( ie to kill the 
previous instance of dropbear which started up the 
same port forward ).



From rob at landley.net  Fri Oct 31 12:23:19 2008
From: rob at landley.net (Rob Landley)
Date: Thu, 30 Oct 2008 22:23:19 -0500
Subject: More than one remote port fwd request for the same local port
In-Reply-To: <005701c93af6$649a00f0$8119fea9@MingChing>
References: <448067AB8643614285E9B1DC376F273C0241F85A@bermail.de.aastra.com>
	<002301c93af5$7adef380$8119fea9@MingChing>
	<005701c93af6$649a00f0$8119fea9@MingChing>
Message-ID: <200810302223.19930.rob@landley.net>

On Thursday 30 October 2008 20:17:04 Ming-Ching Tiew wrote:
> Ming-Ching Tiew wrote:
> > Matt Johnston wrote:
> >> On Thu, Oct 30, 2008 at 02:37:44PM +0100, Michael Wiedmann wrote:
> >>> Hi,
> >>>
> >>> how deals dropbear with different clients which are requesting each
> >>> a remote port forwarding to the same local port (on the server
> >>> side), e.g.
> >>>
> >>> system-1> dbclient -l user1 -N -R 7777:client-ip-1:80 server-ip
> >>> ...
> >>> system-2> dbclient -l user2 -N -R 7777:client-ip-2:80 server-ip
> >>>
> >>> Doing a quick test it looks like dropbear accepts the client
> >>> requests but the port forwarding does not work (actually it cannot
> >>> because there is more than one 'target').
> >>
> >> Unix sockets inherently only allow a single process (so a
> >> single user) to listen on a port. What behaviour would
> >> you expect?
> >
> > I do face the same issue. In my usage, more than one system
> > execute the same command ( ie client-ip is actually one only )
> > and I don't run any remote shell, the sole purpose of the
> > dbclient connection is to establish remote port forward, I
> > would prefer the last command succeed and it drops the previous
> > connection. However, I do realise  such a behaviour is rather
> >  "unfair".
>
> And I did try implement a remote shell method to solve my
> problem, but I was stuck at a stage where I could not identify
> the correct dropbear server process  to kill ( ie to kill the
> previous instance of dropbear which started up the
> same port forward ).

lsof -i

(Note that you may have to run it as root to list the sockets belonging to 
processes other than your current user.)

Of course it may be easier to grovel around in /proc yourself than try to beat 
lsof into _not_ displaying port 80 as "www".  (You can always 
delete /etc/services...)

Rob


From mingching.tiew at redtone.com  Fri Oct 31 13:21:51 2008
From: mingching.tiew at redtone.com (Ming-Ching Tiew)
Date: Fri, 31 Oct 2008 12:21:51 +0800
Subject: More than one remote port fwd request for the same local port
References: <448067AB8643614285E9B1DC376F273C0241F85A@bermail.de.aastra.com>
	<002301c93af5$7adef380$8119fea9@MingChing>
	<005701c93af6$649a00f0$8119fea9@MingChing>
	<200810302223.19930.rob@landley.net>
Message-ID: <00f301c93b10$36e2f990$8119fea9@MingChing>

Rob Landley wrote:
> On Thursday 30 October 2008 20:17:04 Ming-Ching Tiew wrote:
>> Ming-Ching Tiew wrote:
>>> Matt Johnston wrote:
>>>> On Thu, Oct 30, 2008 at 02:37:44PM +0100, Michael Wiedmann wrote:
>>>>> Hi,
>>>>> 
>>>>> how deals dropbear with different clients which are requesting
>>>>> each a remote port forwarding to the same local port (on the
>>>>> server side), e.g.
>>>>> 
>>>>> system-1> dbclient -l user1 -N -R 7777:client-ip-1:80 server-ip
>>>>> ...
>>>>> system-2> dbclient -l user2 -N -R 7777:client-ip-2:80 server-ip
>>>>> 
>>>>> Doing a quick test it looks like dropbear accepts the client
>>>>> requests but the port forwarding does not work (actually it cannot
>>>>> because there is more than one 'target').
>>>> 
>>>> Unix sockets inherently only allow a single process (so a
>>>> single user) to listen on a port. What behaviour would
>>>> you expect?
>>> 
>>> I do face the same issue. In my usage, more than one system
>>> execute the same command ( ie client-ip is actually one only )
>>> and I don't run any remote shell, the sole purpose of the
>>> dbclient connection is to establish remote port forward, I
>>> would prefer the last command succeed and it drops the previous
>>> connection. However, I do realise  such a behaviour is rather
>>>  "unfair".
>> 
>> And I did try implement a remote shell method to solve my
>> problem, but I was stuck at a stage where I could not identify
>> the correct dropbear server process  to kill ( ie to kill the
>> previous instance of dropbear which started up the
>> same port forward ).
> 
> lsof -i
> 
> (Note that you may have to run it as root to list the sockets
> belonging to processes other than your current user.)
> 
> Of course it may be easier to grovel around in /proc yourself than
> try to beat lsof into _not_ displaying port 80 as "www".  (You can
> always 
> delete /etc/services...)
> 

Cool, that looks like what I need.

Thanks.


From michael.wiedmann at aastra.com  Mon Nov  3 15:52:14 2008
From: michael.wiedmann at aastra.com (Michael Wiedmann)
Date: Mon, 3 Nov 2008 07:52:14 +0100
Subject: Remote Port Forwarding: local port on client
Message-ID: <448067AB8643614285E9B1DC376F273C0241F85F@bermail.de.aastra.com>

Hi,

am I correct, that the local port used on the client ('YY' in '-R XXXX:client-ip:YY') is not part of the SSH_MSG_GLOBAL_REQUEST packet (see http://www.faqs.org/rfcs/rfc4254.html, 7.1.  Requesting Port Forwarding)?

I'd like to know on the server side (child process) the port the clients wish to forward to so that I can build an URL for this port forwarding if the port is forwarded to an HTTP port.

Alternatively are there any plans to support remote port forwarding with an unspecified port (=0) so that the server can choose the next unprivileged port (see also RFC 4254. Marked as unsupported in svr-tcpfwd.c)?

Cheers
Michael


From matt at ucc.asn.au  Mon Nov  3 22:36:47 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon, 3 Nov 2008 22:36:47 +0900
Subject: Remote Port Forwarding: local port on client
In-Reply-To: <448067AB8643614285E9B1DC376F273C0241F85F@bermail.de.aastra.com>
References: <448067AB8643614285E9B1DC376F273C0241F85F@bermail.de.aastra.com>
Message-ID: <20081103133647.GC6579@ucc.gu.uwa.edu.au>

On Mon, Nov 03, 2008 at 07:52:14AM +0100, Michael Wiedmann wrote:
> Hi,
> 
> am I correct, that the local port used on the client ('YY' in '-R XXXX:client-ip:YY') is not part of the SSH_MSG_GLOBAL_REQUEST packet (see http://www.faqs.org/rfcs/rfc4254.html, 7.1.  Requesting Port Forwarding)?
> 
> I'd like to know on the server side (child process) the port the clients wish to forward to so that I can build an URL for this port forwarding if the port is forwarded to an HTTP port.
> 
> Alternatively are there any plans to support remote port forwarding with an unspecified port (=0) so that the server can choose the next unprivileged port (see also RFC 4254. Marked as unsupported in svr-tcpfwd.c)?

Neither client-ip nor the YY port are given to the remote
server in the SSH_MSG_GLOBAL_REQUEST packet. I don't quite
see how it would be useful though?

Adding unspecified-port remote forwarding would probably be
fairly straightforward - I just didn't see a need for it
previously. If the client printed a message 
    Remote port <server-port> forwarded to <host:port>
on standard error would that be a useful interface?

Also, I've implemented printing an error message if the
remote forward fails, it'll be in the next release (or the
current development tree)

Matt

From michael.wiedmann at aastra.com  Mon Nov  3 23:22:20 2008
From: michael.wiedmann at aastra.com (Michael Wiedmann)
Date: Mon, 3 Nov 2008 15:22:20 +0100
Subject: Remote Port Forwarding: local port on client
In-Reply-To: <20081103133647.GC6579@ucc.gu.uwa.edu.au>
Message-ID: <448067AB8643614285E9B1DC376F273C0241F860@bermail.de.aastra.com>

Matt Johnston wrote:

> Neither client-ip nor the YY port are given to the remote
> server in the SSH_MSG_GLOBAL_REQUEST packet. I don't quite
> see how it would be useful though?

The need in my (special) case would be to be able to provide
a web-application with a list of only those URLs which are really
being forwarded to an HTTP server on the client side. In my use 
case many clients request two remote port forwardings each,
one for telnet, the other for HTTP on the client. For the web 
application I only want to provide those links for the HTTP 
remote ports (filtering out the others).

For the first step I can live without this, postponing the
'telnet' port forwarding until I find a solution.

> Adding unspecified-port remote forwarding would probably be
> fairly straightforward - I just didn't see a need for it
> previously. If the client printed a message
>     Remote port <server-port> forwarded to <host:port>
> on standard error would that be a useful interface?

This would not be sufficient in my case, because I have to
know this on the server side. 

I've already a hook in 'svr_remotetcpreq()' to build a 
status msg to be written into the server pipe. If I would know
at this stage the client local port I could include this
information into the status msg.

Adding support for unspecified-port remote forwarding would
also mean adding support for this in the client (we use a 
modified 'dbclient'). The actual implementation does not expect
a repsonse of type SSH_MSG_REQUEST_SUCCESS with the port no.

> Also, I've implemented printing an error message if the
> remote forward fails, it'll be in the next release (or the
> current development tree)

Thanks for that.

Michael


From sunknight at gmail.com  Mon Nov  3 23:39:01 2008
From: sunknight at gmail.com (=?gb2312?B?U3VuS25pZ2h0IMvvtqvAtA==?=)
Date: Mon, 3 Nov 2008 22:39:01 +0800
Subject: Fw: how to use a dropbear authorized key certification without a
	ssh-keygen?
References: <200811032129210624209@gmail.com>
Message-ID: <200811032238545467070@gmail.com>

Hey, there
  I am new here, and I just have a question.How to use a dropbear authorized key certification without a ssh-keygen? For I want do some test on a embedded system with dropbear, but there's no ssh-keygen inside the OS. anyone can help me? Thx a lot..
                                                                                          sun




From amery at opensde.org  Tue Nov  4 00:15:06 2008
From: amery at opensde.org (Alejandro Mery)
Date: Mon, 03 Nov 2008 16:15:06 +0100
Subject: Fw: how to use a dropbear authorized key certification without
	a	ssh-keygen?
In-Reply-To: <200811032238545467070@gmail.com>
References: <200811032129210624209@gmail.com> <200811032238545467070@gmail.com>
Message-ID: <490F157A.9060208@opensde.org>

SunKnight ??? wrote:
> Hey, there
>   I am new here, and I just have a question.How to use a dropbear authorized key certification without a ssh-keygen? For I want do some test on a embedded system with dropbear, but there's no ssh-keygen inside the OS. anyone can help me? Thx a lot..
>                                                                                           sun
>
>   
try `dropbearkey -h`

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5013 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081103/260f1d49/attachment.bin 

From matt at ucc.asn.au  Tue Nov  4 20:41:44 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 4 Nov 2008 20:41:44 +0900
Subject: How to setup SSH tunneling in dropbear?
In-Reply-To: <3bb3f3af0810272243r23ca7ec9t8b67a3752da543af@mail.gmail.com>
References: <3bb3f3af0810272243r23ca7ec9t8b67a3752da543af@mail.gmail.com>
Message-ID: <20081104114144.GD6579@ucc.gu.uwa.edu.au>

On Tue, Oct 28, 2008 at 01:43:05PM +0800, Noor Maszuari wrote:
> Hi,
> I'm newbie in dropbear and I would like to know how to setup SSH tunneling
> using dropbear?

What sort of tunnelling do you want to use? You probably
would do something like:

dbclient -i /path/to/dropbear.key -L 1234:remotehost:remoteport tunnelhost

Where remotehost:remoteport is your destination and
tunnelhost is where you want to go through.

> What if I use private key that is generated by PuTTYgen and the location of
> the private key is /home/abc/xyz/pk.ppk?
> How is my command line looks like?

You can convert OpenSSH style keys to dropbear keys using
"dropbearconvert", or create a new dropbear key with
dropbearkey. puttygen can convert PuTTY keys to OpenSSH
style I think.

Matt

From maszuari at gmail.com  Wed Nov  5 10:45:55 2008
From: maszuari at gmail.com (Noor Maszuari)
Date: Wed, 5 Nov 2008 09:45:55 +0800
Subject: How to setup SSH tunneling in dropbear?
In-Reply-To: <20081104114144.GD6579@ucc.gu.uwa.edu.au>
References: <3bb3f3af0810272243r23ca7ec9t8b67a3752da543af@mail.gmail.com>
	<20081104114144.GD6579@ucc.gu.uwa.edu.au>
Message-ID: <3bb3f3af0811041745w7219c16fue2636ac81618fd13@mail.gmail.com>

Hi Matt,
Thanks for your tips.

-maszuari

On Tue, Nov 4, 2008 at 7:41 PM, Matt Johnston <matt at ucc.asn.au> wrote:

> On Tue, Oct 28, 2008 at 01:43:05PM +0800, Noor Maszuari wrote:
> > Hi,
> > I'm newbie in dropbear and I would like to know how to setup SSH
> tunneling
> > using dropbear?
>
> What sort of tunnelling do you want to use? You probably
> would do something like:
>
> dbclient -i /path/to/dropbear.key -L 1234:remotehost:remoteport tunnelhost
>
> Where remotehost:remoteport is your destination and
> tunnelhost is where you want to go through.
>
> > What if I use private key that is generated by PuTTYgen and the location
> of
> > the private key is /home/abc/xyz/pk.ppk?
> > How is my command line looks like?
>
> You can convert OpenSSH style keys to dropbear keys using
> "dropbearconvert", or create a new dropbear key with
> dropbearkey. puttygen can convert PuTTY keys to OpenSSH
> style I think.
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081105/82b3bddd/attachment.htm 

From ssh at sgi.com  Thu Nov  6 22:00:08 2008
From: ssh at sgi.com (Steve Hein)
Date: Thu, 06 Nov 2008 07:00:08 -0600
Subject: Configure dropbear to be fast/insecure? (need a Microblaze speed-up!)
Message-ID: <4912EA58.9060205@sgi.com>

Hi All--

I know that the subject of this email sounds ridiculous....
but let me explain my scenario!

I am running dropbear on a Microblaze-MMU platform
(Spartan-3A FPGA, running @ 62.5MHz).
I've optimized things as far as I know how, but making
an ssh connection to dropbear still takes about 12 seconds,
and the scp and port forwarding performance is still very
slow.     The Microblaze platform is in a completely private
environment    (that is, the network access to the outside
world is via another faster embedded processor within the
same enclosure).     Since all security can be handled from
the node that is accessible to the outside.....I was wondering
if it is possible to configure dropbear in an "insecure" mode,
even to the point of not using encryption?     I know that
there are other alternatives such as rsh/rcp, but I would like
to stay with the ssh method (and I may have a need for
some port forwarding in the future).

Has anyone had any experience with this type of
configuration?    I guess I should also ask:  does anyone
know of any way to improve the speed performance of
ssh on a slow platform like the Microblaze?  Our access
to the Microbaze will require frequent, repeated ssh
sessions, so any real delay in establishing connections
isn't acceptable.

Thanks for tolerating this "dumb question", and thanks
in advance for any help!

Steve Hein,
SGI, Inc.


From matt at ucc.asn.au  Thu Nov  6 22:44:18 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 6 Nov 2008 22:44:18 +0900
Subject: Configure dropbear to be fast/insecure? (need a Microblaze
	speed-up!)
In-Reply-To: <4912EA58.9060205@sgi.com>
References: <4912EA58.9060205@sgi.com>
Message-ID: <20081106134418.GF6579@ucc.gu.uwa.edu.au>

On Thu, Nov 06, 2008 at 07:00:08AM -0600, Steve Hein wrote:
> Hi All--
> I am running dropbear on a Microblaze-MMU platform
> (Spartan-3A FPGA, running @ 62.5MHz).
> I've optimized things as far as I know how, but making
> an ssh connection to dropbear still takes about 12 seconds,
> and the scp and port forwarding performance is still very
> slow.    
>...
> Since all security can be handled from
> the node that is accessible to the outside.....I was wondering
> if it is possible to configure dropbear in an "insecure" mode,
> even to the point of not using encryption?   

There's a (fairly untested) branch^
http://viewmtn.angrygoats.net/all/branch/changes/au.asn.ucc.matt.dropbear.insecure-nocrypto
that allows using the 'none' cipher and mac algorithms.
You'll have to compile a custom client/server of course, and
if you want to use password auth grep for "sorry" and remove
those checks :)

I'm not sure about improving the initial connection time -
using small DSS hostkeys will probably be the best
approach, though you've probably already tried that.
There were a few internet-drafts about elliptic curve
Diffie-Hellman for SSH, though I haven't looked at those
much. Of course if security isn't any issue then perhaps a
'none' key-exchange method could be invented too ;)

Cheers,
Matt


^ The web mirror hasn't updated yet to my current commit
though, give it a little while for "Update nocrypto branch to
current head" to appear. You can grab a tarball under
"browse files", you'll have to run "autoconf; autoheader"
before configure.

From rob at landley.net  Fri Nov  7 10:15:05 2008
From: rob at landley.net (Rob Landley)
Date: Thu, 6 Nov 2008 19:15:05 -0600
Subject: Configure dropbear to be fast/insecure? (need a Microblaze
	speed-up!)
In-Reply-To: <20081106134418.GF6579@ucc.gu.uwa.edu.au>
References: <4912EA58.9060205@sgi.com>
	<20081106134418.GF6579@ucc.gu.uwa.edu.au>
Message-ID: <200811061915.06350.rob@landley.net>

On Thursday 06 November 2008 07:44:18 Matt Johnston wrote:
> I'm not sure about improving the initial connection time -
> using small DSS hostkeys will probably be the best
> approach, though you've probably already tried that.
> There were a few internet-drafts about elliptic curve
> Diffie-Hellman for SSH, though I haven't looked at those
> much. Of course if security isn't any issue then perhaps a
> 'none' key-exchange method could be invented too ;)

Also make sure you've disabled the reverse dns lookups for the log entries; 
those generally add _horrible_ latency to connections, and logging the IP 
address is all you actually _need_.

Back in 2001, on a 200 mhz pentium III, I was getting 3.2 connections/second, 
and around 300k/second throughput.  (That wasn't with dropbear, but that was 
a performance ballpark for comparison.)

If your microblaze really is taking 12 seconds to connect, you should profile 
this and see what's going on.  Is the CPU really busy the whole time?

Rob


From vapier at gentoo.org  Fri Nov  7 13:52:13 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 6 Nov 2008 23:52:13 -0500
Subject: Configure dropbear to be fast/insecure? (need a Microblaze
	speed-up!)
In-Reply-To: <4912EA58.9060205@sgi.com>
References: <4912EA58.9060205@sgi.com>
Message-ID: <1aad82fa0811062052m2020f01ay279a9b946deaffde@mail.gmail.com>

if it's all private / development, why dont you just use telnet w/out login ?
-mike


From jamie at shareable.org  Fri Nov  7 14:10:55 2008
From: jamie at shareable.org (Jamie Lokier)
Date: Fri, 7 Nov 2008 05:10:55 +0000
Subject: Configure dropbear to be fast/insecure? (need a Microblaze
	speed-up!)
In-Reply-To: <1aad82fa0811062052m2020f01ay279a9b946deaffde@mail.gmail.com>
References: <4912EA58.9060205@sgi.com>
	<1aad82fa0811062052m2020f01ay279a9b946deaffde@mail.gmail.com>
Message-ID: <20081107051055.GF17593@shareable.org>

Mike Frysinger wrote:
> if it's all private / development, why dont you just use telnet w/out login ?

Maybe because "ssh command < file > file2" works while it doesn't work
with telnet?  ssh is a much more convenient and reliable interface.

-- Jamie


From vapier at gentoo.org  Fri Nov  7 14:46:35 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Fri, 7 Nov 2008 00:46:35 -0500
Subject: Configure dropbear to be fast/insecure? (need a Microblaze
	speed-up!)
In-Reply-To: <20081107051055.GF17593@shareable.org>
References: <4912EA58.9060205@sgi.com>
	<1aad82fa0811062052m2020f01ay279a9b946deaffde@mail.gmail.com>
	<20081107051055.GF17593@shareable.org>
Message-ID: <1aad82fa0811062146j6100de05j3d3adc62505d58f8@mail.gmail.com>

On Fri, Nov 7, 2008 at 12:10 AM, Jamie Lokier wrote:
> Mike Frysinger wrote:
>> if it's all private / development, why dont you just use telnet w/out login ?
>
> Maybe because "ssh command < file > file2" works while it doesn't work
> with telnet?  ssh is a much more convenient and reliable interface.

maybe for your needs, but this is about Steve's needs.  the extended
scriptability of ssh often times is irrelevant if you just want to
interact with a board.  telnet is a hell of a lot simpler than ssh.
-mike


From ssh at sgi.com  Fri Nov  7 21:42:12 2008
From: ssh at sgi.com (Steven Hein)
Date: Fri, 07 Nov 2008 06:42:12 -0600
Subject: Configure dropbear to be fast/insecure? (need a Microblaze
	speed-up!)
In-Reply-To: <1aad82fa0811062146j6100de05j3d3adc62505d58f8@mail.gmail.com>
References: <4912EA58.9060205@sgi.com>	
	<1aad82fa0811062052m2020f01ay279a9b946deaffde@mail.gmail.com>	
	<20081107051055.GF17593@shareable.org>
	<1aad82fa0811062146j6100de05j3d3adc62505d58f8@mail.gmail.com>
Message-ID: <491437A4.9030101@sgi.com>

Mike Frysinger wrote:
> On Fri, Nov 7, 2008 at 12:10 AM, Jamie Lokier wrote:
>   
>> Mike Frysinger wrote:
>>     
>>> if it's all private / development, why dont you just use telnet w/out login ?
>>>       
>> Maybe because "ssh command < file > file2" works while it doesn't work
>> with telnet?  ssh is a much more convenient and reliable interface.
>>     
>
> maybe for your needs, but this is about Steve's needs.  the extended
> scriptability of ssh often times is irrelevant if you just want to
> interact with a board.  telnet is a hell of a lot simpler than ssh.
> -mike
>   
Mike--

Thanks for the comments, you are absolutely right. But in this
case, Jamie is dead-on.   I've definitely used ssh alternatives in
the past; if I didn't want to stick with the ssh interface, I would
probably switch over to rsh.    But we will likely be scripting
in this environment, and will probably be using a layer over
ssh to allow commands to be sent to multiple Microblaze
targets (within the same private environment) in parallel.
And, we also may want to use port forwarding, which ssh
also handles nicely.

The environment is private, as in within a single enclosure
where the only access point is through another embedded
processor, but it will be production (eventually!).

Steve


From qarce at yahoo.com  Sun Nov  9 17:02:36 2008
From: qarce at yahoo.com (Quentin Arce)
Date: Sun, 9 Nov 2008 00:02:36 -0800 (PST)
Subject: why no DSA support?
Message-ID: <119265.9156.qm@web65613.mail.ac4.yahoo.com>

Hi,

I'm sure this is noted some place.  I couldn't find why in the source / doc / google.  So, why doesn't dropbear support DSA keys?

Thanks,

Quentin


      


From amery at opensde.org  Sun Nov  9 18:56:07 2008
From: amery at opensde.org (Alejandro Mery)
Date: Sun, 09 Nov 2008 10:56:07 +0100
Subject: why no DSA support?
In-Reply-To: <119265.9156.qm@web65613.mail.ac4.yahoo.com>
References: <119265.9156.qm@web65613.mail.ac4.yahoo.com>
Message-ID: <4916B3B7.5090705@opensde.org>

Quentin Arce escribi?:
> I'm sure this is noted some place.  I couldn't find why in the source / doc / google.  So, why doesn't dropbear support DSA keys?
Hi Quentin,
dropbear does support them
<http://en.wikipedia.org/wiki/Digital_Signature_Algorithm>.

$ dropbearkey
Must specify a key filename
Usage: dropbearkey -t <type> -f <filename> [-s bits]
Options are:
-t type    Type of key to generate. One of:
        rsa
        dss
-f filename    Use filename for the secret key
-s bits    Key size in bits, should be a multiple of 8 (optional)
           (DSS has a fixed size of 1024 bits)
-y        Just print the publickey and fingerprint for the
        private key in <filename>.


Regards,
Alejandro Mery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5013 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081109/0cd74935/attachment.bin 

From michael.wiedmann at aastra.com  Mon Nov 10 21:57:08 2008
From: michael.wiedmann at aastra.com (Michael Wiedmann)
Date: Mon, 10 Nov 2008 13:57:08 +0100
Subject: Remote Port Forwarding: local port on client
In-Reply-To: <20081103133647.GC6579@ucc.gu.uwa.edu.au>
Message-ID: <448067AB8643614285E9B1DC376F273C0241F870@bermail.de.aastra.com>

Matt Johnston wrote:

> Adding unspecified-port remote forwarding would probably be
> fairly straightforward - I just didn't see a need for it
> previously.

I need some hints about implementing remote port forwarding 
w/o specifying a remote port on the client side:

I know already how to handle the server side:

Adding a hook in svr-tcpfwd.c:svr_remotetcpreq() by calling
a custom function if (port == 0) to let this function 
choose somehow an unused port.

The thing I'm not sure about is the client side:

The relevant part of RFC 4254, '7.1. Requesting Port Forwarding'
reads:

  If a client passes 0 as port number to bind and has 'want reply' 
  as TRUE, then the server allocates the next available unprivileged 
  port number and replies with the following message; otherwise, 
  there is no response-specific data.

Does this mean, that the client does _not_ necessarily wait for a
response from the server? If yes, there is no need to modify 
existing dropbear source code to work with an unspecifed 
remote-port?
Otherwise I'm not sure how to change the client code to handle
the the 'SSH_MSG_REQUEST_SUCCESS' message (containing the port
chosen by the server).

Without the need to modify the client side it really would be 
trivial to add this at the server side. This would be great for 
my usage scenario.

Michael


From fja0568 at gmail.com  Tue Nov 11 00:54:47 2008
From: fja0568 at gmail.com (Farrell Aultman)
Date: Mon, 10 Nov 2008 10:54:47 -0500
Subject: why no DSA support?
In-Reply-To: <4916B3B7.5090705@opensde.org>
References: <119265.9156.qm@web65613.mail.ac4.yahoo.com>
	<4916B3B7.5090705@opensde.org>
Message-ID: <3ba466150811100754n10e339fbud6f79157931eafc9@mail.gmail.com>

They are called DSS in dropbear.  DSA and DSS are the same thing.

On Sun, Nov 9, 2008 at 4:56 AM, Alejandro Mery <amery at opensde.org> wrote:

> Quentin Arce escribi?:
> > I'm sure this is noted some place.  I couldn't find why in the source /
> doc / google.  So, why doesn't dropbear support DSA keys?
> Hi Quentin,
> dropbear does support them
> <http://en.wikipedia.org/wiki/Digital_Signature_Algorithm>.
>
> $ dropbearkey
> Must specify a key filename
> Usage: dropbearkey -t <type> -f <filename> [-s bits]
> Options are:
> -t type    Type of key to generate. One of:
>        rsa
>        dss
> -f filename    Use filename for the secret key
> -s bits    Key size in bits, should be a multiple of 8 (optional)
>           (DSS has a fixed size of 1024 bits)
> -y        Just print the publickey and fingerprint for the
>        private key in <filename>.
>
>
> Regards,
> Alejandro Mery
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081110/1a52c740/attachment.htm 

From qarce at yahoo.com  Tue Nov 11 02:26:47 2008
From: qarce at yahoo.com (Quentin Arce)
Date: Mon, 10 Nov 2008 09:26:47 -0800 (PST)
Subject: why no DSA support?
In-Reply-To: <3ba466150811100754n10e339fbud6f79157931eafc9@mail.gmail.com>
Message-ID: <251507.33068.qm@web65613.mail.ac4.yahoo.com>


Thank you very much.




--- On Mon, 11/10/08, Farrell Aultman <fja0568 at gmail.com> wrote:

> From: Farrell Aultman <fja0568 at gmail.com>
> Subject: Re: why no DSA support?
> To: "Alejandro Mery" <amery at opensde.org>
> Cc: qarce at yahoo.com, "dropbear" <dropbear at ucc.asn.au>
> Date: Monday, November 10, 2008, 9:54 AM
> They are called DSS in dropbear.  DSA and DSS are the same
> thing.
> 
> On Sun, Nov 9, 2008 at 4:56 AM, Alejandro Mery
> <amery at opensde.org> wrote:
> 
> > Quentin Arce escribi?:
> > > I'm sure this is noted some place.  I
> couldn't find why in the source /
> > doc / google.  So, why doesn't dropbear support
> DSA keys?
> > Hi Quentin,
> > dropbear does support them
> >
> <http://en.wikipedia.org/wiki/Digital_Signature_Algorithm>.
> >
> > $ dropbearkey
> > Must specify a key filename
> > Usage: dropbearkey -t <type> -f <filename>
> [-s bits]
> > Options are:
> > -t type    Type of key to generate. One of:
> >        rsa
> >        dss
> > -f filename    Use filename for the secret key
> > -s bits    Key size in bits, should be a multiple of 8
> (optional)
> >           (DSS has a fixed size of 1024 bits)
> > -y        Just print the publickey and fingerprint for
> the
> >        private key in <filename>.
> >
> >
> > Regards,
> > Alejandro Mery
> >
> >


      


From roman at rs-labs.com  Tue Nov 11 04:47:47 2008
From: roman at rs-labs.com (Roman Medina-Heigl Hernandez)
Date: Mon, 10 Nov 2008 20:47:47 +0100
Subject: SecureCRT -> SSH-2.0-dropbear_0.36
Message-ID: <49188FE3.1030209@rs-labs.com>

Hello,

I'm having problems trying to connect to an old version of Dropbear (v0.36)
from SecureCRT (v5.5.1). Dropbear server is embeded in my home ADSL router.

Please, correct me if I'm wrong, but it seems that Dropbear is dropping the
connection. Why? Is there any known compatibility problem which I'm not
aware of?

This is the connection's log:

[LOCAL] : SSH2Core version 4.3.0.407
[LOCAL] : Connecting to 192.168.1.1:22 ...
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT
[LOCAL] : Using protocol SSH2
[LOCAL] : RECV : Remote Identifier = "SSH-2.0-dropbear_0.36"
[LOCAL] : CAP  : Remote can re-key
[LOCAL] : CAP  : Remote sends language in password change requests
[LOCAL] : CAP  : Remote sends algorithm name in PK_OK packets
[LOCAL] : CAP  : Remote sends algorithm name in public key packets
[LOCAL] : CAP  : Remote sends algorithm name in signatures
[LOCAL] : CAP  : Remote sends error text in open failure packets
[LOCAL] : CAP  : Remote sends name in service accept packets
[LOCAL] : CAP  : Remote includes port number in x11 open packets
[LOCAL] : CAP  : Remote uses 160 bit keys for SHA1 MAC
[LOCAL] : CAP  : Remote supports new diffie-hellman group exchange messages
[LOCAL] : CAP  : Remote correctly handles unknown SFTP extensions
[LOCAL] : CAP  : Remote correctly encodes OID for gssapi
[LOCAL] : CAP  : Remote correctly uses connected addresses in
forwarded-tcpip requests
[LOCAL] : CAP  : Remote can do SFTP version 4
[LOCAL] : CAP  : Remote uses SHA1 hash in RSA signatures for x.509v3
[LOCAL] : CAP  : Remote x.509v3 uses ASN.1 encoding for DSA signatures
[LOCAL] : SEND : KEXINIT
[LOCAL] : RECV : Read kexinit
[LOCAL] : Available Remote Kex Methods = diffie-hellman-group1-sha1
[LOCAL] : Selected Kex Method = diffie-hellman-group1-sha1
[LOCAL] : Available Remote Host Key Algos = ssh-rsa
[LOCAL] : Selected Host Key Algo = ssh-rsa
[LOCAL] : Available Remote Send Ciphers = 3des-cbc
[LOCAL] : Selected Send Cipher = 3des-cbc
[LOCAL] : Available Remote Recv Ciphers = 3des-cbc
[LOCAL] : Selected Recv Cipher = 3des-cbc
[LOCAL] : Available Remote Send Macs = hmac-sha1,hmac-md5
[LOCAL] : Selected Send Mac = hmac-md5
[LOCAL] : Available Remote Recv Macs = hmac-sha1,hmac-md5
[LOCAL] : Selected Recv Mac = hmac-md5
[LOCAL] : Available Remote Compressors = none
[LOCAL] : Selected Compressor = none
[LOCAL] : Available Remote Decompressors = none
[LOCAL] : Selected Decompressor = none
[LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_KEY_EXCHANGE
[LOCAL] : SEND : KEXDH_INIT
[LOCAL] : Changing state from STATE_KEY_EXCHANGE to STATE_CLOSED
[LOCAL] : Connected for 0 seconds, 503 bytes sent, 191 bytes received

Thank you.

-- 

Saludos,
-Roman

PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB  29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]


From matt at ucc.asn.au  Wed Nov 12 22:32:07 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed, 12 Nov 2008 22:32:07 +0900
Subject: Dropbear 0.52
Message-ID: <20081112133207.GL6579@ucc.gu.uwa.edu.au>

Hi all.

I've put together a release for Dropbear 0.52. It mostly has
new features, as well as a few bugfixes.

The client has gained a few new additions including the
ability to "onion-route" through a few SSH servers, all
established from the local host. Performance connecting to
an OpenSSH server with dbclient should improve now that
the zlib at openssh.com compression mode is supported.

The website http:/matt.ucc.asn.au/dropbear/dropbear.html 
has releases as usual.

Matt

0.52 - Wed 12 November 2008

- Add "netcat-alike" option (-B) to dbclient, allowing Dropbear to tunnel
  standard input/output to a TCP port-forwarded remote host.

- Add "proxy command" support to dbclient, to allow using a spawned process for
  IO rather than a direct TCP connection. eg
	  dbclient remotehost
  is equivalent to
	  dbclient -J 'nc remotehost 22' remotehost
  (the hostname is still provided purely for looking up saved host keys)

- Combine netcat-alike and proxy support to allow "multihop" connections, with
  comma-separated host syntax.  Allows running

	  dbclient user1 at host1,user2 at host2,user3 at host3

  to end up at host3 via the other two, using SSH TCP forwarding. It's a bit
  like onion-routing. All connections are established from the local machine.
  The comma-separated syntax can also be used for scp/rsync, eg

	  rsync -a -e dbclient m at gateway,m2 at host,martello:/home/matt/ ~/backup/

  to bounce through a few hosts.

- Add -I "idle timeout" option (contributed by Farrell Aultman)

- Allow restrictions on authorized_keys logins such as restricting commands
  to be run etc. This is a subset of those allowed by OpenSSH, doesn't
  yet allow restricting source host.

- Use vfork() for scp on uClinux

- Default to PATH=/usr/bin:/bin for shells.

- Report errors if -R forwarding fails

- Add counter mode cipher support, which avoids some security problems with the
  standard CBC mode.

- Support zlib at openssh.com delayed compression for client/server. It can be
  required for the Dropbear server with the '-Z' option. This is useful for
  security as it avoids exposing the server to attacks on zlib by
  unauthenticated remote users, though requires client side support.

- options.h has been split into options.h (user-changable) and sysoptions.h
  (less commonly changed)

- Support "dbclient -s sftp" to specify a subsystem

- Fix a bug in replies to channel requests that could be triggered by recent
  versions of PuTTY

From matt at ucc.asn.au  Wed Nov 12 22:36:05 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed, 12 Nov 2008 22:36:05 +0900
Subject: SecureCRT -> SSH-2.0-dropbear_0.36
In-Reply-To: <4919C761.1090902@rs-labs.com>
References: <49188FE3.1030209@rs-labs.com>
	<65f5245c89f56e47167f82f0052d6bce@mooneye.ucc.gu.uwa.edu.au>
	<4919C761.1090902@rs-labs.com>
Message-ID: <20081112133605.GM6579@ucc.gu.uwa.edu.au>

On Tue, Nov 11, 2008 at 06:56:49PM +0100, Roman Medina-Heigl Hernandez wrote:
> 
> Putty exposes similar behaviour. Summary:
> 2008-11-11 18:51:30	Looking up host "192.168.0.230"
> 2008-11-11 18:51:30	Connecting to 192.168.0.230 port 22
> 2008-11-11 18:51:30	Server version: SSH-2.0-dropbear_0.36
> 2008-11-11 18:51:30	We claim version: SSH-2.0-PuTTY_Release_0.60
> 2008-11-11 18:51:30	Using SSH protocol version 2
> 2008-11-11 18:51:30	Using Diffie-Hellman with standard group "group1"
> 2008-11-11 18:51:30	Doing Diffie-Hellman key exchange with hash SHA-1
> 2008-11-11 18:51:30	Network error: Connection reset by peer
> 
> Detailed logs:

I can't see anything obvious there. The only way to debug it
further really is to get a login to the device somehow and
have a look at what Dropbear is logging when it exits. I
suppose you could try connecting with dbclient (hopefully
it's compatible...), though it's also possible that the
binary on the router is just plain broken (the compiler has
generated incorrect crypto code, etc).

Cheers,
Matt

From michael.wiedmann at aastra.com  Wed Nov 19 22:41:16 2008
From: michael.wiedmann at aastra.com (Michael Wiedmann)
Date: Wed, 19 Nov 2008 14:41:16 +0100
Subject: Missing '#ifdef ENABLE_SVR_LOCALTCPFWD'
Message-ID: <448067AB8643614285E9B1DC376F273C0241F892@bermail.de.aastra.com>

Hi,

In 'svr-tcpfwd.c' is missing '#ifdef ENABLE_SVR_LOCALTCPFWD / #endif'
around line #301-304 (dropbear-0.52). Similiar omission exists for 
ENABLE_SVR_REMOTETCPFWD around line #85-88 in the same file.

Might be true also for the client code.

Cheers
Michael


From jeroen.van.der.vegt at technolution.eu  Fri Nov 21 00:54:14 2008
From: jeroen.van.der.vegt at technolution.eu (Jeroen van der Vegt)
Date: Thu, 20 Nov 2008 16:54:14 +0100
Subject: Dropbear turns into zombie process after killing
Message-ID: <3CB6B0DAAE9F4F7ABFB6F7D0CE0F66B7@intranet.technolution.nl>

Hello,


We're using Dropbear 0.51 to create a tunnel from an embedded ARM device to
a server (running openSSH). We use the precompiled dropbear version from
Debian, and ssh is symlinked to dbclient.
The tunnel is constructed in a script using this command:

	# ssh -i /etc/dropbear/dropbear_rsa_host_key $USER@$REMOTEHOST -L \
		$LOCALPORT:127.0.0.1:$REMOTEPORT -f -N

A tunnel created this way works fine. When the script is done, the tunnel
should be removed. We simply kill all instances of 'ssh' for this.
Unfortunately, this results in a zombie dropbear process on our ARM device.

I guess it might have something to do with using both the -f and the -N
command at the same time, as merely specifying '-f' returns an error that a
command is required.

If using both -f and -N is indeed the cause of this problem, then how do I
create a persistent tunnel while the rest of my script executes?


Regards,

Jeroen van der Vegt	 
System designer 
________________________________

Technolution B.V.	 
Telephone:         +31(0)182 59 40 00	 
Fax:              +31(0)182 53 97 36	 
E-mail:           Jeroen.van.der.Vegt at technolution.eu	 
Visit us at:      www.technolution.eu	 
Mailing address:  P.O. Box 2013 - 2800 BD Gouda - The Netherlands	 
Address:          Zuidelijk Halfrond 1 - 2801 DD Gouda - The Netherlands

________________________________

This e-mail is intended exclusively for the addressee(s), and may not be
passed on to, or made available for use by any person other than the
addressee(s). Technolution B.V. rules out any and every liability resulting
from any electronic transmission. 



From matt at ucc.asn.au  Fri Nov 21 08:09:43 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Fri, 21 Nov 2008 08:09:43 +0900
Subject: Dropbear turns into zombie process after killing
In-Reply-To: <3CB6B0DAAE9F4F7ABFB6F7D0CE0F66B7@intranet.technolution.nl>
References: <3CB6B0DAAE9F4F7ABFB6F7D0CE0F66B7@intranet.technolution.nl>
Message-ID: <20081120230943.GC11204@ucc.gu.uwa.edu.au>

On Thu, Nov 20, 2008 at 04:54:14PM +0100, Jeroen van der Vegt wrote:
> Hello,
> 
> 
> We're using Dropbear 0.51 to create a tunnel from an embedded ARM device to
> a server (running openSSH). We use the precompiled dropbear version from
> Debian, and ssh is symlinked to dbclient.
> The tunnel is constructed in a script using this command:
> 
> 	# ssh -i /etc/dropbear/dropbear_rsa_host_key $USER@$REMOTEHOST -L \
> 		$LOCALPORT:127.0.0.1:$REMOTEPORT -f -N
> 
> A tunnel created this way works fine. When the script is done, the tunnel
> should be removed. We simply kill all instances of 'ssh' for this.
> Unfortunately, this results in a zombie dropbear process on our ARM device.

How are you running that command? Cleaning up zombie
processes is the responsibility of the parent process that
spawns a process (using waitpid() etc, most shells etc would
take care of it). I don't think there's much that the
Dropbear client could be doing (or not doing) that would
influence whether it's zombified?

Matt

From michael.wiedmann at aastra.com  Fri Nov 21 19:27:25 2008
From: michael.wiedmann at aastra.com (Michael Wiedmann)
Date: Fri, 21 Nov 2008 11:27:25 +0100
Subject: How to support cipher 'none'?
Message-ID: <448067AB8643614285E9B1DC376F273C0241F896@bermail.de.aastra.com>

Hi,

I wonder how I could support 'none' as sshcipher.
I tried to add 

	{"none", 0, NULL, 1},

as first entry in 'sshciphers[]' and rebuilt the server and client.
In the TRACE msgs I can see, that client and server agree on 'none' 
as encryption method:

TRACE: buf_match_algo: none,aes128-cbc,3des-cbc,aes256-cbc
TRACE: enc c2s is  none
TRACE: buf_match_algo: none,aes128-cbc,3des-cbc,aes256-cbc
TRACE: enc s2c is  none

But the client dumps core before authentication is completed:

TRACE: leave send_msg_newkeys
TRACE: leave recv_msg_kexdh_init
TRACE: leave process_packet
TRACE: maybe_empty_reply_queue - no data allowed
TRACE: enter cli_sessionloop
TRACE: leave cli_sessionloop: kex_state != KEX_NOTHING
TRACE: enter write_packet
TRACE: empty queue dequeing
TRACE: leave write_packet
TRACE: enter read_packet
TRACE: enter decrypt_packet
TRACE: leave decrypt_packet
TRACE: leave read_packet
TRACE: enter process_packet
TRACE: process_packet: packet type = 21
TRACE: <- MSG_NEWKEYS
TRACE: enter recv_msg_newkeys
TRACE: while SENTNEWKEYS=1
TRACE: enter gen_new_keys
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
Segmentation fault (core dumped)

Cheers
Michael
PS: I try to find out how much overhead causes e.g. "aes128-cbc" and looking for 
    an easy way to switch between the offered ciphers from the client so that we
    can optionally setup an unencrypted connection.


From michael.wiedmann at aastra.com  Fri Nov 21 19:31:57 2008
From: michael.wiedmann at aastra.com (Michael Wiedmann)
Date: Fri, 21 Nov 2008 11:31:57 +0100
Subject: How to support cipher 'none'?
In-Reply-To: <448067AB8643614285E9B1DC376F273C0241F896@bermail.de.aastra.com>
Message-ID: <448067AB8643614285E9B1DC376F273C0241F897@bermail.de.aastra.com>

Michael Wiedmann wrote:
 
> But the client dumps core before authentication is completed:

Additional information from gdb:

Program received signal SIGSEGV, Segmentation fault.
gen_new_keys () at common-kex.c:275
275                 C2S_keysize = ses.newkeys->trans_algo_crypt->keysize;
(gdb) where
#0  gen_new_keys () at common-kex.c:275
#1  0x00405ea0 in recv_msg_newkeys () at common-kex.c:167
#2  0x004084d6 in process_packet () at process-packet.c:111
#3  0x004049bf in session_loop (loophandler=0x409776 <cli_sessionloop>)
    at common-session.c:200
#4  0x00408a97 in main (argc=10, argv=0x6d3308) at cli-main.c:75
(gdb)

Michael


From ssh at sgi.com  Fri Nov 21 21:14:59 2008
From: ssh at sgi.com (Steven Hein)
Date: Fri, 21 Nov 2008 06:14:59 -0600
Subject: How to support cipher 'none'?
In-Reply-To: <448067AB8643614285E9B1DC376F273C0241F897@bermail.de.aastra.com>
References: <448067AB8643614285E9B1DC376F273C0241F897@bermail.de.aastra.com>
Message-ID: <4926A643.1080108@sgi.com>

Hi Michael--

Check out this thread from earlier this month:

http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2008q4/000819.html

This week, I finally got around to testing this nocrypto
branch of dropbear, and it worked well for me.
(As the comment in options.h says, in order to have one
client that would run run to secure or insecure servers,
there's a bit of work left on the client side, but it appears
that the server side works well).

For my needs I had to go a step further and speed up the
key exchange   (since I'm running on a very slow platform
the Microblaze @ 62.5MHz).    I don't have anything
working there yet......I've just been hacking up the
kex code to remove the key validation checks and skip
the mp_exptmod() call (which appears to take *seconds* to
execute on the Microblaze).    Not a solution yet, but I'm
still working on it!

Steve


Michael Wiedmann wrote:
> Michael Wiedmann wrote:
>  
>   
>> But the client dumps core before authentication is completed:
>>     
>
> Additional information from gdb:
>
> Program received signal SIGSEGV, Segmentation fault.
> gen_new_keys () at common-kex.c:275
> 275                 C2S_keysize = ses.newkeys->trans_algo_crypt->keysize;
> (gdb) where
> #0  gen_new_keys () at common-kex.c:275
> #1  0x00405ea0 in recv_msg_newkeys () at common-kex.c:167
> #2  0x004084d6 in process_packet () at process-packet.c:111
> #3  0x004049bf in session_loop (loophandler=0x409776 <cli_sessionloop>)
>     at common-session.c:200
> #4  0x00408a97 in main (argc=10, argv=0x6d3308) at cli-main.c:75
> (gdb)
>
> Michael
>
>
>   



From jeroen.van.der.vegt at technolution.eu  Mon Nov 24 23:23:13 2008
From: jeroen.van.der.vegt at technolution.eu (Jeroen van der Vegt)
Date: Mon, 24 Nov 2008 15:23:13 +0100
Subject: Dropbear turns into zombie process after killing
In-Reply-To: <20081120230943.GC11204@ucc.gu.uwa.edu.au>
References: <3CB6B0DAAE9F4F7ABFB6F7D0CE0F66B7@intranet.technolution.nl>
	<20081120230943.GC11204@ucc.gu.uwa.edu.au>
Message-ID: <11EE60AF202240B1B8373D8032BC2CF5@intranet.technolution.nl>

Hi Matt,


I found the issue, and indeed it had nothing to do with dropbear.
Apparently, 'init' was only  half-way its start-up procedure. One of the
scripts in ::sysinit:: had a loop like this though:

while /bin/true; do
        /bin/sh
done

which prevented 'init' from finishing completely. It also triggered a 'Job
control turned off' warning on the serial console, but I had no clue what it
meant. I did find out about the command 'kill 0' command though, which
allowed me to break out of the while-loop and make 'init' finish its work,
removing all zombie processes with it.


Sorry to bother you,

Jeroen van der Vegt	 
System designer 
________________________________

Technolution B.V.	 
Telephone:         +31(0)182 59 40 00	 
Fax:              +31(0)182 53 97 36	 
E-mail:           Jeroen.van.der.Vegt at technolution.eu	 
Visit us at:      www.technolution.eu	 
Mailing address:  P.O. Box 2013 - 2800 BD Gouda - The Netherlands	 
Address:          Zuidelijk Halfrond 1 - 2801 DD Gouda - The Netherlands

________________________________

This e-mail is intended exclusively for the addressee(s), and may not be
passed on to, or made available for use by any person other than the
addressee(s). Technolution B.V. rules out any and every liability resulting
from any electronic transmission. 
> -----Original Message-----
> From: dropbear-bounces at ucc.asn.au [mailto:dropbear-bounces at ucc.asn.au] On
> Behalf Of Matt Johnston
> Sent: vrijdag 21 november 2008 0:10
> To: Jeroen van der Vegt
> Cc: dropbear at ucc.asn.au
> Subject: Re: Dropbear turns into zombie process after killing
> 
> On Thu, Nov 20, 2008 at 04:54:14PM +0100, Jeroen van der Vegt wrote:
> > Hello,
> >
> >
> > We're using Dropbear 0.51 to create a tunnel from an embedded ARM device
> to
> > a server (running openSSH). We use the precompiled dropbear version from
> > Debian, and ssh is symlinked to dbclient.
> > The tunnel is constructed in a script using this command:
> >
> > 	# ssh -i /etc/dropbear/dropbear_rsa_host_key $USER@$REMOTEHOST -L \
> > 		$LOCALPORT:127.0.0.1:$REMOTEPORT -f -N
> >
> > A tunnel created this way works fine. When the script is done, the
> tunnel
> > should be removed. We simply kill all instances of 'ssh' for this.
> > Unfortunately, this results in a zombie dropbear process on our ARM
> device.
> 
> How are you running that command? Cleaning up zombie
> processes is the responsibility of the parent process that
> spawns a process (using waitpid() etc, most shells etc would
> take care of it). I don't think there's much that the
> Dropbear client could be doing (or not doing) that would
> influence whether it's zombified?
> 
> Matt



From id0_316118 at yahoo.com  Sat Dec  6 08:12:33 2008
From: id0_316118 at yahoo.com (GeorgeM)
Date: Fri, 5 Dec 2008 23:12:33 +0000 (UTC)
Subject: port forwarding really really slow
Message-ID: <loom.20081205T225716-542@post.gmane.org>

i'm using dropbear for dynamic port forwarding. i've noticed that if i 
instruct the socks clients to do dns lookups via tunnel the connection 
becomes unusably slow. for example trying to open youtube, or other reasonably
complex site will timeout during page load. my question is: does dropbear 
do dns lookups asynchroneously? does it cache recent queries? is there
an option i've missed out?



From matt at ucc.asn.au  Mon Dec  8 10:43:09 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon, 08 Dec 2008 09:43:09 +0800
Subject: port forwarding really really slow
In-Reply-To: <loom.20081205T225716-542@post.gmane.org>
References: <loom.20081205T225716-542@post.gmane.org>
Message-ID: <7fd6f1b57638394b7f5557030c2739e7@mooneye.ucc.gu.uwa.edu.au>

On Fri, 5 Dec 2008 23:12:33 +0000 (UTC), GeorgeM <id0_316118 at yahoo.com>
wrote:
> i'm using dropbear for dynamic port forwarding. i've noticed that if i 
> instruct the socks clients to do dns lookups via tunnel the connection 
> becomes unusably slow. for example trying to open youtube, or other
> reasonably
> complex site will timeout during page load. my question is: does dropbear

> do dns lookups asynchroneously? does it cache recent queries? is there
> an option i've missed out?

Hi,

Currently Dropbear doesn't do anything clever with DNS, it just calls get
getaddrinfo() synchronously. I'll take a look at how hard it would be to do
asynchronous lookups. I'm not sure that caching really belongs in
individual apps - if anything it should be the socks client doing caching?

Matt

From brian at minton.name  Fri Dec 12 04:14:13 2008
From: brian at minton.name (Brian Minton)
Date: Thu, 11 Dec 2008 14:14:13 -0500
Subject: CPNI-957037
Message-ID: <81aa6b5a0812111114o404c0d7dx69a77e1f705cbf72@mail.gmail.com>

Is dropbear vulnerable to the CBC mode plaintext recovery attack described at
 http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt

thanks,
Brian


From rpjday at crashcourse.ca  Fri Dec 12 04:18:22 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Thu, 11 Dec 2008 14:18:22 -0500 (EST)
Subject: where does dropbear remember that its already created its key(s)?
Message-ID: <alpine.LFD.2.00.0812111413200.8574@localhost.localdomain>


  started dropbear for the very first on an embedded system with an
NFS-mounted root filesystem, it worked flawlessly creating the keys.
next day, someone else commandeered the system and mounted *their*
root filesystem which, not surprisingly, had no /etc/dropbear
directory, so dropbear immediately failed complaining about a lack of
the /etc/dropbear key file.

  i'm assuming that dropbear must have recorded somewhere that it
created the keys and therefore will complain if that file is missing.
where did dropbear record this event?  thanks.

  (or am i totally misunderstanding what happened here?)

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From rpjday at crashcourse.ca  Fri Dec 12 05:46:36 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Thu, 11 Dec 2008 15:46:36 -0500 (EST)
Subject: is the following patch still required?
Message-ID: <alpine.LFD.2.00.0812111539280.17985@localhost.localdomain>


  trying to make a long story short, i'm using freescale's "ltib"
utility to build a cross-compiled (m68k) root filesystem, and their
utility sometimes bundles patches with the pristine source tarballs
for packages.

  for dropbear-0.45, this is the single associated patch that is
incorporated into the ltib build that i'm using:

=======================================
--- dropbear-0.45/scp.c	2005-03-07 04:27:02.000000000 +0000
+++ dropbear-0.45.modified/scp.c	2005-06-16 11:20:40.000000000 +0100
@@ -249,9 +249,11 @@

 	args.list = NULL;
 	addargs(&args, "ssh");		/* overwritten with ssh_program */
+#ifndef DROPBEAR_CLIENT
 	addargs(&args, "-x");
 	addargs(&args, "-oForwardAgent no");
 	addargs(&args, "-oClearAllForwardings yes");
+#endif

 	fflag = tflag = 0;
 	while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:")) != -1)
=======================================

  i can't use dropbear-0.45 since i need port forwarding so i figure i
might as well upgrade to 0.52.  i've downloaded the source tarball for
0.52 and that patch no longer applies very well.  is it (or some
equivalent) even needed anymore?  if not, i can just replace the older
source with the newer and toss any reference to a patch.  thanks.

rday
--


========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From rpjday at crashcourse.ca  Fri Dec 12 21:33:12 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Fri, 12 Dec 2008 07:33:12 -0500 (EST)
Subject: how to invoke dropbear automatically with specific options?
Message-ID: <alpine.LFD.2.00.0812120731360.5160@localhost.localdomain>


  i'm guessing i already know the answer to this but if i want to
invoke dropbear each time with port forwarding enabled, is the proper
technique to edit /etc/rc.d/init.d/dropbear and add the "-a" option to
the actual /usr/sbin/dropbear invocation?

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From rpjday at crashcourse.ca  Fri Dec 12 22:50:00 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Fri, 12 Dec 2008 08:50:00 -0500 (EST)
Subject: setting up dropbear for local port forwarding
Message-ID: <alpine.LFD.2.00.0812120845270.5646@localhost.localdomain>


  undoubtedly a trivial question but i want to make sure i have this
mentally worked out before i get to the office and try it.

  i want to set up a system running dropbear to do local port
forwarding to a remote host running a regular sshd listening on the
default port 22.

  as i read it, on my forwarding system (with dropbear 0.52), i need
to do two things:

  1) invoke dropbear with "-a" (no other changes)

  2) invoke dbclient thusly:

  # dbclient -L 1234:localhost:22 root at remotehost

is that about it?  or have i misread something in the docs?  thanks.

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From haizaar at haizaar.com  Sun Dec 14 20:30:12 2008
From: haizaar at haizaar.com (Hai Zaar)
Date: Sun, 14 Dec 2008 13:30:12 +0200
Subject: dbclient - read from standard input
In-Reply-To: <76d9e2a30812111413u468ce998gb66565d8f49307c8@mail.gmail.com>
References: <76d9e2a30812111413u468ce998gb66565d8f49307c8@mail.gmail.com>
Message-ID: <76d9e2a30812140330p396d6e5ew6177882271323fc8@mail.gmail.com>

Good day!
Why does dbclient reads data from tty and not from standard input? For
example, OpenSSH reads password from tty and data from standard input,
enabling piping command's stdout to remove host via ssh, like this:
$> echo asdf | ssh remotehost cat
asdf
And with dropbear we have:
$> echo asdf | dbclient remotehost cat
$>
However this hack works:
$> echo asdf > $(tty) | dbclient remotehost cat
asdf
$>
But we not always have a tty (i.e. dbclient run from system script).
Can I force dbclient to read data from stdin? (Or is there any
workaround of this problem?)

dbclient version 0.52 on x86 (same behavior on ARM).

P.S. I'm not on the list, so please CC me. Thanks.
--
Zaar



-- 
Zaar


From matt at ucc.asn.au  Mon Dec 15 22:33:22 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon, 15 Dec 2008 22:33:22 +0900
Subject: CPNI-957037
In-Reply-To: <81aa6b5a0812111114o404c0d7dx69a77e1f705cbf72@mail.gmail.com>
References: <81aa6b5a0812111114o404c0d7dx69a77e1f705cbf72@mail.gmail.com>
Message-ID: <20081215133322.GA6097@ucc.gu.uwa.edu.au>

On Thu, Dec 11, 2008 at 02:14:13PM -0500, Brian Minton wrote:
> Is dropbear vulnerable to the CBC mode plaintext recovery attack described at
>  http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt

Yes, Dropbear is most likely vulnerable to that attack. The
best workaround (if you're running in the risky situation of
a script that will automatically reconnect) is probably to
use 0.52 which uses Counter Mode by default, which doesn't
have problems. On average an active attacker would have to
disconnect several thousand connections before determining
any cleartext, so the risk of attack for interactive
sessions is low.

Matt

From matt at ucc.asn.au  Mon Dec 15 22:36:47 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon, 15 Dec 2008 22:36:47 +0900
Subject: setting up dropbear for local port forwarding
In-Reply-To: <alpine.LFD.2.00.0812120845270.5646@localhost.localdomain>
References: <alpine.LFD.2.00.0812120845270.5646@localhost.localdomain>
Message-ID: <20081215133647.GB6097@ucc.gu.uwa.edu.au>

On Fri, Dec 12, 2008 at 08:50:00AM -0500, Robert P. J. Day wrote:
> 
>   undoubtedly a trivial question but i want to make sure i have this
> mentally worked out before i get to the office and try it.
> 
>   i want to set up a system running dropbear to do local port
> forwarding to a remote host running a regular sshd listening on the
> default port 22.
> 
>   as i read it, on my forwarding system (with dropbear 0.52), i need
> to do two things:
> 
>   1) invoke dropbear with "-a" (no other changes)
> 
>   2) invoke dbclient thusly:
> 
>   # dbclient -L 1234:localhost:22 root at remotehost
> 
> is that about it?  or have i misread something in the docs?  thanks.

I'm not totally sure what you want to do. If you have

host1     <---->   host2     <------->   host3
runs               runs                  runs
dbclient           dropbear              openssh

then you would run on host1
dbclient -L 1234:host3:22 host2

and "dropbear -a" on host2 (the "forwarding system").

Does that make sense?

Matt

From rpjday at crashcourse.ca  Mon Dec 15 22:47:15 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Mon, 15 Dec 2008 08:47:15 -0500 (EST)
Subject: setting up dropbear for local port forwarding
In-Reply-To: <20081215133647.GB6097@ucc.gu.uwa.edu.au>
References: <alpine.LFD.2.00.0812120845270.5646@localhost.localdomain>
	<20081215133647.GB6097@ucc.gu.uwa.edu.au>
Message-ID: <alpine.LFD.2.00.0812150841370.6263@localhost.localdomain>

On Mon, 15 Dec 2008, Matt Johnston wrote:

> On Fri, Dec 12, 2008 at 08:50:00AM -0500, Robert P. J. Day wrote:
> >
> >   undoubtedly a trivial question but i want to make sure i have this
> > mentally worked out before i get to the office and try it.
> >
> >   i want to set up a system running dropbear to do local port
> > forwarding to a remote host running a regular sshd listening on the
> > default port 22.
> >
> >   as i read it, on my forwarding system (with dropbear 0.52), i need
> > to do two things:
> >
> >   1) invoke dropbear with "-a" (no other changes)
> >
> >   2) invoke dbclient thusly:
> >
> >   # dbclient -L 1234:localhost:22 root at remotehost
> >
> > is that about it?  or have i misread something in the docs?  thanks.
>
> I'm not totally sure what you want to do. If you have
>
> host1     <---->   host2     <------->   host3
> runs               runs                  runs
> dbclient           dropbear              openssh
>
> then you would run on host1
> dbclient -L 1234:host3:22 host2
>
> and "dropbear -a" on host2 (the "forwarding system").
>
> Does that make sense?

   hmmmmmm ... that's not the way i understood it from my reading, but
i probably misread.  what i'm after:

  host1     <----->     host2    <----->     host3

* i'm on host1 from where i will log in to some remote host, so i will
obviously need dbclient on host1

* both host2 and host3 will have some flavour of ssh server -- host2
will *definitely* have dropbear and host3 will have either dropbear or
regular openssh

* from host1, i want to be able to ssh and log into host2 normally.

* from host1, i want to be able to (somehow) log into host2 and have
it port forward my login to host3.

  i can see, then, how i need to be running "dropbear -a" on host2, to
allow the port forwarding to host3.  so i'll give the above a shot.
thanks.

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From rpjday at crashcourse.ca  Mon Dec 15 23:16:27 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Mon, 15 Dec 2008 09:16:27 -0500 (EST)
Subject: setting up dropbear for local port forwarding
In-Reply-To: <20081215133647.GB6097@ucc.gu.uwa.edu.au>
References: <alpine.LFD.2.00.0812120845270.5646@localhost.localdomain>
	<20081215133647.GB6097@ucc.gu.uwa.edu.au>
Message-ID: <alpine.LFD.2.00.0812150914420.6558@localhost.localdomain>

On Mon, 15 Dec 2008, Matt Johnston wrote:

> On Fri, Dec 12, 2008 at 08:50:00AM -0500, Robert P. J. Day wrote:
> >
> >   undoubtedly a trivial question but i want to make sure i have this
> > mentally worked out before i get to the office and try it.
> >
> >   i want to set up a system running dropbear to do local port
> > forwarding to a remote host running a regular sshd listening on the
> > default port 22.
> >
> >   as i read it, on my forwarding system (with dropbear 0.52), i need
> > to do two things:
> >
> >   1) invoke dropbear with "-a" (no other changes)
> >
> >   2) invoke dbclient thusly:
> >
> >   # dbclient -L 1234:localhost:22 root at remotehost
> >
> > is that about it?  or have i misread something in the docs?  thanks.
>
> I'm not totally sure what you want to do. If you have
>
> host1     <---->   host2     <------->   host3
> runs               runs                  runs
> dbclient           dropbear              openssh
>
> then you would run on host1
> dbclient -L 1234:host3:22 host2       <----???????????
>
> and "dropbear -a" on host2 (the "forwarding system").
>
> Does that make sense?
>
> Matt

  if i'm running that on host1, wouldn't that be

  dbclient -R 1234:host3:22 host2    ("-R", not "-L"??)

rday

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From matt at ucc.asn.au  Mon Dec 15 23:35:22 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon, 15 Dec 2008 23:35:22 +0900
Subject: setting up dropbear for local port forwarding
In-Reply-To: <alpine.LFD.2.00.0812150914420.6558@localhost.localdomain>
References: <alpine.LFD.2.00.0812120845270.5646@localhost.localdomain>
	<20081215133647.GB6097@ucc.gu.uwa.edu.au>
	<alpine.LFD.2.00.0812150914420.6558@localhost.localdomain>
Message-ID: <20081215143522.GA8640@ucc.gu.uwa.edu.au>

On Mon, Dec 15, 2008 at 09:16:27AM -0500, Robert P. J. Day wrote:
> >
> > host1     <---->   host2     <------->   host3
> > runs               runs                  runs
> > dbclient           dropbear              openssh
> >
> > then you would run on host1
> > dbclient -L 1234:host3:22 host2       <----???????????
> 
>   if i'm running that on host1, wouldn't that be
> 
>   dbclient -R 1234:host3:22 host2    ("-R", not "-L"??)

Sorry, you're right, I was thinking -R.

Cheers,
Matt

From matt at ucc.asn.au  Tue Dec 16 23:09:06 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 16 Dec 2008 23:09:06 +0900
Subject: dbclient - read from standard input
In-Reply-To: <76d9e2a30812140330p396d6e5ew6177882271323fc8@mail.gmail.com>
References: <76d9e2a30812111413u468ce998gb66565d8f49307c8@mail.gmail.com>
	<76d9e2a30812140330p396d6e5ew6177882271323fc8@mail.gmail.com>
Message-ID: <20081216140906.GB8640@ucc.gu.uwa.edu.au>

On Sun, Dec 14, 2008 at 01:30:12PM +0200, Hai Zaar wrote:
> Good day!
> Why does dbclient reads data from tty and not from standard input? For
> example, OpenSSH reads password from tty and data from standard input,
> enabling piping command's stdout to remove host via ssh, like this:
> $> echo asdf | ssh remotehost cat
> asdf
> And with dropbear we have:
> $> echo asdf | dbclient remotehost cat
> $>
> However this hack works:
> $> echo asdf > $(tty) | dbclient remotehost cat
> asdf
> $>
> But we not always have a tty (i.e. dbclient run from system script).
> Can I force dbclient to read data from stdin? (Or is there any
> workaround of this problem?)

It looks like a bug with dbclient closing the connection too
soon - I'll investigate.

Matt

From bodrato at mail.dm.unipi.it  Thu Dec 18 07:20:07 2008
From: bodrato at mail.dm.unipi.it (bodrato at mail.dm.unipi.it)
Date: Wed, 17 Dec 2008 23:20:07 +0100 (CET)
Subject: Patch to speed-up LibTomMath
Message-ID: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>

Dear dropbear developers,

I was experimenting with the Toom-Cook multiplication algorithm, for large
numbers, and I run across LibTomMath. Unfortunately the main project seems
dead and forgotten, so I searched for an active project using its code and
I've found Dropbear!
I patched the 3-way Toom from libtommath with some simple optimizations
( http://ln.bodrato.it/FasterToomConvolution_pdf ), now it is
significantly faster: on my laptop it "obsoletes" the Karatsuba code,
since it is as fast a Karatsuba for small operands, but faster for bigger
ones.
Now the question is: are you interested in the patch?
(maybe you prefer not to modify an "external and imported" library...)
In the case you are interested, how should I submit the new files?

Thank you for any answer,
Marco

-- 
http://bodrato.it/



From matt at ucc.asn.au  Thu Dec 18 20:19:36 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 18 Dec 2008 20:19:36 +0900
Subject: Patch to speed-up LibTomMath
In-Reply-To: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
Message-ID: <20081218111936.GC8640@ucc.gu.uwa.edu.au>

On Wed, Dec 17, 2008 at 11:20:07PM +0100, bodrato at mail.dm.unipi.it wrote:
> I patched the 3-way Toom from libtommath with some simple optimizations
> ( http://ln.bodrato.it/FasterToomConvolution_pdf ), now it is
> significantly faster: on my laptop it "obsoletes" the Karatsuba code,
> since it is as fast a Karatsuba for small operands, but faster for bigger
> ones.
> Now the question is: are you interested in the patch?
> (maybe you prefer not to modify an "external and imported" library...)
> In the case you are interested, how should I submit the new files?

Hi Marco,

Speedups for libtommath would be of interest. I guess the
easiest way would be to email me off-list with a patch or
a set of the relevant files? I won't guarantee that I'll include 
the changes (given I haven't dealt with the LibTomMath code 
much in depth) though it sounds useful. I'm not 100% sure 
whether Tom is still interested in work on LibTom* 
or not - the releases page suggests not.

Cheers,
Matt

From rob at landley.net  Fri Dec 19 08:28:24 2008
From: rob at landley.net (Rob Landley)
Date: Thu, 18 Dec 2008 17:28:24 -0600
Subject: is the following patch still required?
In-Reply-To: <alpine.LFD.2.00.0812111539280.17985@localhost.localdomain>
References: <alpine.LFD.2.00.0812111539280.17985@localhost.localdomain>
Message-ID: <200812181728.24748.rob@landley.net>

On Thursday 11 December 2008 14:46:36 Robert P. J. Day wrote:
>   trying to make a long story short, i'm using freescale's "ltib"
> utility to build a cross-compiled (m68k) root filesystem, and their
> utility sometimes bundles patches with the pristine source tarballs
> for packages.
>
>   for dropbear-0.45, this is the single associated patch that is
> incorporated into the ltib build that i'm using:
>
> =======================================
> --- dropbear-0.45/scp.c	2005-03-07 04:27:02.000000000 +0000
> +++ dropbear-0.45.modified/scp.c	2005-06-16 11:20:40.000000000 +0100
> @@ -249,9 +249,11 @@
>
>  	args.list = NULL;
>  	addargs(&args, "ssh");		/* overwritten with ssh_program */
> +#ifndef DROPBEAR_CLIENT
>  	addargs(&args, "-x");
>  	addargs(&args, "-oForwardAgent no");
>  	addargs(&args, "-oClearAllForwardings yes");
> +#endif

These days the chunk of code looks like:

            addargs(&alist, "%s", ssh_program);
            if (verbose_mode)
                addargs(&alist, "-v");
            addargs(&alist, "-x");
            addargs(&alist, "-oClearAllForwardings yes");
            addargs(&alist, "-n");

So it really looks like you don't need it.

Rob


From rob at landley.net  Fri Dec 19 08:29:57 2008
From: rob at landley.net (Rob Landley)
Date: Thu, 18 Dec 2008 17:29:57 -0600
Subject: how to invoke dropbear automatically with specific options?
In-Reply-To: <alpine.LFD.2.00.0812120731360.5160@localhost.localdomain>
References: <alpine.LFD.2.00.0812120731360.5160@localhost.localdomain>
Message-ID: <200812181729.57544.rob@landley.net>

On Friday 12 December 2008 06:33:12 Robert P. J. Day wrote:
>   i'm guessing i already know the answer to this but if i want to
> invoke dropbear each time with port forwarding enabled, is the proper
> technique to edit /etc/rc.d/init.d/dropbear and add the "-a" option to
> the actual /usr/sbin/dropbear invocation?

Sounds good to me.

Rob


From rob at landley.net  Fri Dec 19 08:42:47 2008
From: rob at landley.net (Rob Landley)
Date: Thu, 18 Dec 2008 17:42:47 -0600
Subject: Patch to speed-up LibTomMath
In-Reply-To: <20081218111936.GC8640@ucc.gu.uwa.edu.au>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
	<20081218111936.GC8640@ucc.gu.uwa.edu.au>
Message-ID: <200812181742.48261.rob@landley.net>

On Thursday 18 December 2008 05:19:36 Matt Johnston wrote:
> On Wed, Dec 17, 2008 at 11:20:07PM +0100, bodrato at mail.dm.unipi.it wrote:
> > I patched the 3-way Toom from libtommath with some simple optimizations
> > ( http://ln.bodrato.it/FasterToomConvolution_pdf ), now it is
> > significantly faster: on my laptop it "obsoletes" the Karatsuba code,
> > since it is as fast a Karatsuba for small operands, but faster for bigger
> > ones.
> > Now the question is: are you interested in the patch?
> > (maybe you prefer not to modify an "external and imported" library...)
> > In the case you are interested, how should I submit the new files?
>
> Hi Marco,
>
> Speedups for libtommath would be of interest. I guess the
> easiest way would be to email me off-list with a patch or
> a set of the relevant files? I won't guarantee that I'll include
> the changes (given I haven't dealt with the LibTomMath code
> much in depth) though it sounds useful. I'm not 100% sure
> whether Tom is still interested in work on LibTom*
> or not - the releases page suggests not.

Speaking of which:

Last year I posted to this list asking what would be involved in adding 
stunnel support to dropbear:

http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2007q3/000638.html

I got forarded to an embedded openssl clone and xrelayd that can presumably 
stunnel on top of that:
http://www.ohloh.net/p/xyssl
http://znerol.ch/

Since dropbear already contains libtomcrypt, it seems like it would be smaller 
(and simpler) to have this functionality integrated, but I dunno how to do it.  
(It would be really nice if dropbear provided stunnel, that would allow the 
busybox web server to trivially grow https support.)

Matt: do you have any idea how much work this would be to add to dropbear?  (I 
downloaded the RFCs on https last year and spent several hours reading them, 
but my brain melted and I never got back to it...)

Rob


From rob at landley.net  Fri Dec 19 08:42:47 2008
From: rob at landley.net (Rob Landley)
Date: Thu, 18 Dec 2008 17:42:47 -0600
Subject: Patch to speed-up LibTomMath
In-Reply-To: <20081218111936.GC8640@ucc.gu.uwa.edu.au>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
	<20081218111936.GC8640@ucc.gu.uwa.edu.au>
Message-ID: <200812181742.48261.rob@landley.net>

On Thursday 18 December 2008 05:19:36 Matt Johnston wrote:
> On Wed, Dec 17, 2008 at 11:20:07PM +0100, bodrato at mail.dm.unipi.it wrote:
> > I patched the 3-way Toom from libtommath with some simple optimizations
> > ( http://ln.bodrato.it/FasterToomConvolution_pdf ), now it is
> > significantly faster: on my laptop it "obsoletes" the Karatsuba code,
> > since it is as fast a Karatsuba for small operands, but faster for bigger
> > ones.
> > Now the question is: are you interested in the patch?
> > (maybe you prefer not to modify an "external and imported" library...)
> > In the case you are interested, how should I submit the new files?
>
> Hi Marco,
>
> Speedups for libtommath would be of interest. I guess the
> easiest way would be to email me off-list with a patch or
> a set of the relevant files? I won't guarantee that I'll include
> the changes (given I haven't dealt with the LibTomMath code
> much in depth) though it sounds useful. I'm not 100% sure
> whether Tom is still interested in work on LibTom*
> or not - the releases page suggests not.

Speaking of which:

Last year I posted to this list asking what would be involved in adding 
stunnel support to dropbear:

http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2007q3/000638.html

I got forarded to an embedded openssl clone and xrelayd that can presumably 
stunnel on top of that:
http://www.ohloh.net/p/xyssl
http://znerol.ch/

Since dropbear already contains libtomcrypt, it seems like it would be smaller 
(and simpler) to have this functionality integrated, but I dunno how to do it.  
(It would be really nice if dropbear provided stunnel, that would allow the 
busybox web server to trivially grow https support.)

Matt: do you have any idea how much work this would be to add to dropbear?  (I 
downloaded the RFCs on https last year and spent several hours reading them, 
but my brain melted and I never got back to it...)

Rob


From peter at turczak.de  Fri Dec 19 18:46:14 2008
From: peter at turczak.de (Peter Turczak)
Date: Fri, 19 Dec 2008 10:46:14 +0100
Subject: Patch to speed-up LibTomMath
In-Reply-To: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
Message-ID: <89C8C386-64F9-4239-9E50-77B37726567E@turczak.de>

Hi there,

while working on a quite low-power embedded System (a 68k derivative  
clocked at 166 MHz), I realised that libtommath was simply too slow.  
Just connecting to an ssh-server using dbclient took about 30-40 sec.  
Therefore I adapted the whole dropbear code and libtomcrypt (which  
already comes with an appropriate interface) to use libtomsfastmath,  
which heavily uses fix-precision numbers and assembly.

The patch is nearing its completion, for now a connection using  
dbclient takes about 11 sec, from local commandline to logoff after a  
remote "echo hello". Unfortunately the dropbear server seems to have  
broken while doing m68k assembly speedups, but this should be  
fixable. On an X86 this patch likewise greatly increases the  
performance of all public-key algorithms.

It would be interesting how close Marcos and my approaches regarding  
speedups are under real word conditions, say slow/underpowered/ 
embedded computers like routers, ,,netbooks'', dboxen,etc.

If there is any demand for a pre-alpha release maybe I would put it  
on my webpage for you to download, just let me know.

Best regards,
   Peter

On Dec 17, 2008, at 11:20 PM, bodrato at mail.dm.unipi.it wrote:

> Dear dropbear developers,
>
> I was experimenting with the Toom-Cook multiplication algorithm,  
> for large
> numbers, and I run across LibTomMath. Unfortunately the main  
> project seems
> dead and forgotten, so I searched for an active project using its  
> code and
> I've found Dropbear!
> I patched the 3-way Toom from libtommath with some simple  
> optimizations
> ( http://ln.bodrato.it/FasterToomConvolution_pdf ), now it is
> significantly faster: on my laptop it "obsoletes" the Karatsuba code,
> since it is as fast a Karatsuba for small operands, but faster for  
> bigger
> ones.
> Now the question is: are you interested in the patch?
> (maybe you prefer not to modify an "external and imported" library...)
> In the case you are interested, how should I submit the new files?
>
> Thank you for any answer,
> Marco
>
> -- 
> http://bodrato.it/
>
>
>



From bodrato at mail.dm.unipi.it  Fri Dec 19 21:24:46 2008
From: bodrato at mail.dm.unipi.it (bodrato at mail.dm.unipi.it)
Date: Fri, 19 Dec 2008 13:24:46 +0100 (CET)
Subject: Patch to speed-up LibTomMath
In-Reply-To: <20081218111936.GC8640@ucc.gu.uwa.edu.au>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
	<20081218111936.GC8640@ucc.gu.uwa.edu.au>
Message-ID: <54606.151.21.92.160.1229689486.squirrel@mail.dm.unipi.it>

> On Wed, Dec 17, 2008 at 11:20:07PM +0100, bodrato at mail.dm.unipi.it wrote:
>> I patched the 3-way Toom from libtommath with some simple optimizations
>> ( http://bodrato.it/software/toom.html ), now it is
>> significantly faster: on my laptop it "obsoletes" the Karatsuba code,
>
> Hi Marco,
>
> Speedups for libtommath would be of interest. I guess the
> easiest way would be to email me off-list with a patch or
> a set of the relevant files? I won't guarantee that I'll include
> the changes (given I haven't dealt with the LibTomMath code
> much in depth) though it sounds useful. I'm not 100% sure

Hi Matt,

I'll send you my code in minutes. I just have to test it against the
libtommath-0.40 included in Dropbear... since I developed it with 0.41.
The TOOM_MUL_CUTOFF and TOOM_SQR_CUTOFF constants should be computed and
set to lower values to see if this impacts somehow on performances.
If not, the best thing to do would be to completely remove Toom code, by
un-defining BN_MP_TOOM_MUL_C and BN_MP_TOOM_SQR_C.

Marco
-- 
http://bodrato.it/papers/



From bodrato at mail.dm.unipi.it  Fri Dec 19 23:14:32 2008
From: bodrato at mail.dm.unipi.it (bodrato at mail.dm.unipi.it)
Date: Fri, 19 Dec 2008 15:14:32 +0100 (CET)
Subject: Patch to speed-up LibTomMath
In-Reply-To: <20081218111936.GC8640@ucc.gu.uwa.edu.au>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
	<20081218111936.GC8640@ucc.gu.uwa.edu.au>
Message-ID: <33863.151.21.92.160.1229696072.squirrel@mail.dm.unipi.it>

Hi Matt, hi everybody,

> On Wed, Dec 17, 2008 at 11:20:07PM +0100, bodrato at mail.dm.unipi.it wrote:
>> I patched the 3-way Toom from libtommath with some simple optimizations
>> ( http://ln.bodrato.it/FasterToomConvolution_pdf ), now it is
>> significantly faster: on my laptop it "obsoletes" the Karatsuba code,
>> since it is as fast a Karatsuba for small operands, but faster for
>
> Speedups for libtommath would be of interest. I guess the
> easiest way would be to email me off-list with a patch or
> a set of the relevant files? I won't guarantee that I'll include

I send you the two files. Not the differences as a patch because I
completely rewrote the files. The "full archive" is so small that I think
I can send it to the list too...

Cheers,
m

-- 
http://bodrato.it/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libtommat-toom-substitute.tgz
Type: application/x-compressed
Size: 3234 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081219/91495d4f/attachment.bin 

From peter at turczak.de  Sat Dec 20 00:22:07 2008
From: peter at turczak.de (Peter Turczak)
Date: Fri, 19 Dec 2008 16:22:07 +0100
Subject: Patch to speed-up LibTomMath
In-Reply-To: <52021.151.21.92.160.1229698637.squirrel@mail.dm.unipi.it>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
	<89C8C386-64F9-4239-9E50-77B37726567E@turczak.de>
	<52021.151.21.92.160.1229698637.squirrel@mail.dm.unipi.it>
Message-ID: <39728748-F01B-4356-A533-C5A4C8BC606D@turczak.de>

Hi Marco,
On Dec 19, 2008, at 3:57 PM, bodrato at mail.dm.unipi.it wrote:

> Hi Peter,
>
>> clocked at 166 MHz), I realised that libtommath was simply too slow.
>
> I agree. LibTomMath has two basic advantages: it is simple, it is  
> portable.
> Speed is not it's main goal, nor memory efficiency (on my 32-bit CPU  
> it
> stores 28 bit per word).
Ok, here you are right. Libtomsfastmath contains ansi-C for  
portability reasons as well as assembler-snippets. So portability  
should not be an issue, more the maintainability.  (See http://tfm.libtomcrypt.com/features.html 
  )
>
>
>> Therefore I adapted the whole dropbear code and libtomcrypt (which
>> already comes with an appropriate interface) to use libtomsfastmath,
>> which heavily uses fix-precision numbers and assembly.
>
> On the other side, assembly coding can give huge improvements to  
> speed, at
> the expense of portability.
You may see above. I tested the code both on an i386 a ppc-mac and a  
m68k, both with assembler and ansi-c, all these test where successful.  
As it was to be expected there where significant speedups when using  
asm snippets.
>
>
>> It would be interesting how close Marco's and my approaches regarding
>> speedups are under real word conditions, say slow/underpowered/
>
> I'm sure that for medium sized integers (exponentiations needed for
> 1024-bit RSA, for example) it is possible to obtain better results by
> introducing efficient base case operations than by fine tuning higher
> level algorithms.
>

Maybe we could use the same abstraction in dropbear as in libtomcrypt  
which seems to work quite well, and let the use decide while compiling.

Furthermore it would be interesting to port your idea to tomsfastmath,  
so we could get even faster ;)


>
>> If there is any demand for a pre-alpha release maybe I would put it
>> on my webpage for you to download, just let me know.
>>
>> Best regards,
>>   Peter
>
> Regards,
> Marco

Regards
   Peter
>


From rob at landley.net  Sun Dec 21 11:49:09 2008
From: rob at landley.net (Rob Landley)
Date: Sat, 20 Dec 2008 20:49:09 -0600
Subject: Patch to speed-up LibTomMath
In-Reply-To: <39728748-F01B-4356-A533-C5A4C8BC606D@turczak.de>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
	<52021.151.21.92.160.1229698637.squirrel@mail.dm.unipi.it>
	<39728748-F01B-4356-A533-C5A4C8BC606D@turczak.de>
Message-ID: <200812202049.09844.rob@landley.net>

On Friday 19 December 2008 09:22:07 Peter Turczak wrote:
> Hi Marco,
>
> On Dec 19, 2008, at 3:57 PM, bodrato at mail.dm.unipi.it wrote:
> > Hi Peter,
> >
> >> clocked at 166 MHz), I realised that libtommath was simply too slow.
> >
> > I agree. LibTomMath has two basic advantages: it is simple, it is
> > portable.
> > Speed is not it's main goal, nor memory efficiency (on my 32-bit CPU
> > it
> > stores 28 bit per word).
>
> Ok, here you are right. Libtomsfastmath contains ansi-C for
> portability reasons as well as assembler-snippets. So portability
> should not be an issue, more the maintainability.  (See
> http://tfm.libtomcrypt.com/features.html )

Matt mentioned that libtomcrypt might not be particularly maintained anymore, 
did Libtomsfastmath replace it or has the maintainer gone on to other things 
entirely?

Also, does the assembly in libtomsfastmath potentially make it less portable, 
or is it just optional alternative implementations you can use if you happen 
to build on a supported platform, with C fallback for everything?

The freshmeat project was last updated over 2 years ago, libtomcrypt.org isn't 
resolving at the DNS level, and the google cache says it moved to libtom.org 
which times out when I try to connect to it.

Rob


From rob at landley.net  Sun Dec 21 11:49:09 2008
From: rob at landley.net (Rob Landley)
Date: Sat, 20 Dec 2008 20:49:09 -0600
Subject: Patch to speed-up LibTomMath
In-Reply-To: <39728748-F01B-4356-A533-C5A4C8BC606D@turczak.de>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
	<52021.151.21.92.160.1229698637.squirrel@mail.dm.unipi.it>
	<39728748-F01B-4356-A533-C5A4C8BC606D@turczak.de>
Message-ID: <200812202049.09844.rob@landley.net>

On Friday 19 December 2008 09:22:07 Peter Turczak wrote:
> Hi Marco,
>
> On Dec 19, 2008, at 3:57 PM, bodrato at mail.dm.unipi.it wrote:
> > Hi Peter,
> >
> >> clocked at 166 MHz), I realised that libtommath was simply too slow.
> >
> > I agree. LibTomMath has two basic advantages: it is simple, it is
> > portable.
> > Speed is not it's main goal, nor memory efficiency (on my 32-bit CPU
> > it
> > stores 28 bit per word).
>
> Ok, here you are right. Libtomsfastmath contains ansi-C for
> portability reasons as well as assembler-snippets. So portability
> should not be an issue, more the maintainability.  (See
> http://tfm.libtomcrypt.com/features.html )

Matt mentioned that libtomcrypt might not be particularly maintained anymore, 
did Libtomsfastmath replace it or has the maintainer gone on to other things 
entirely?

Also, does the assembly in libtomsfastmath potentially make it less portable, 
or is it just optional alternative implementations you can use if you happen 
to build on a supported platform, with C fallback for everything?

The freshmeat project was last updated over 2 years ago, libtomcrypt.org isn't 
resolving at the DNS level, and the google cache says it moved to libtom.org 
which times out when I try to connect to it.

Rob


From matt at ucc.asn.au  Sun Dec 21 13:20:57 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Sun, 21 Dec 2008 13:20:57 +0900
Subject: Patch to speed-up LibTomMath
In-Reply-To: <200812202049.09844.rob@landley.net>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
	<52021.151.21.92.160.1229698637.squirrel@mail.dm.unipi.it>
	<39728748-F01B-4356-A533-C5A4C8BC606D@turczak.de>
	<200812202049.09844.rob@landley.net>
Message-ID: <20081221042057.GE8640@ucc.gu.uwa.edu.au>

On Sat, Dec 20, 2008 at 08:49:09PM -0600, Rob Landley wrote:
> Matt mentioned that libtomcrypt might not be particularly maintained anymore, 
> did Libtomsfastmath replace it or has the maintainer gone on to other things 
> entirely?

I think tomsfastmath was meant to be a bit more limited in
what it provides (though probably enough for RSA/DSS/DH),
a bit less friendly to read/learn from, but quicker. I've
mirrored the last release at
http://matt.ucc.asn.au/mirror/tfm-0.10.tar.bz2

> The freshmeat project was last updated over 2 years ago,
> libtomcrypt.org isn't resolving at the DNS level, and the
> google cache says it moved to libtom.org which times out
> when I try to connect to it.

libtomcrypt.com was working a couple of days ago, though
seems to be timing out currently. Might be on the end of a
DSL line.

Matt

From matt at ucc.asn.au  Sun Dec 21 13:20:57 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Sun, 21 Dec 2008 13:20:57 +0900
Subject: Patch to speed-up LibTomMath
In-Reply-To: <200812202049.09844.rob@landley.net>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
	<52021.151.21.92.160.1229698637.squirrel@mail.dm.unipi.it>
	<39728748-F01B-4356-A533-C5A4C8BC606D@turczak.de>
	<200812202049.09844.rob@landley.net>
Message-ID: <20081221042057.GE8640@ucc.gu.uwa.edu.au>

On Sat, Dec 20, 2008 at 08:49:09PM -0600, Rob Landley wrote:
> Matt mentioned that libtomcrypt might not be particularly maintained anymore, 
> did Libtomsfastmath replace it or has the maintainer gone on to other things 
> entirely?

I think tomsfastmath was meant to be a bit more limited in
what it provides (though probably enough for RSA/DSS/DH),
a bit less friendly to read/learn from, but quicker. I've
mirrored the last release at
http://matt.ucc.asn.au/mirror/tfm-0.10.tar.bz2

> The freshmeat project was last updated over 2 years ago,
> libtomcrypt.org isn't resolving at the DNS level, and the
> google cache says it moved to libtom.org which times out
> when I try to connect to it.

libtomcrypt.com was working a couple of days ago, though
seems to be timing out currently. Might be on the end of a
DSL line.

Matt

From rpjday at crashcourse.ca  Mon Dec 22 23:53:15 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Mon, 22 Dec 2008 09:53:15 -0500 (EST)
Subject: how to run dropbear on a system with a R/O /dev?
Message-ID: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>


  i suspect i already know the answer to this, but is there any way to
run dropbear on a system whose /dev directory is part of a larger
romfs?

  ssh to such a system worked fine during development when the root
filesystem was NFS mounted and, therefore, writable.  but once that
rootfs is flashed and is now mounted as a romfs, not surprisingly,
dropbear can no longer accept incoming requests because (i'm
guessing) while the appropriate /dev/ttyp[0-9] device files are there,
dropbear has no ability to change their owner/perms, is that it?
which generates the log error message:

   pty_allocate: openpty: No child processes
   no pty was allocated, couldn't execute

  is there a way around this?  i would have guessed not, but i'm
willing to be pleasantly surprised.

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From rpjday at crashcourse.ca  Tue Dec 23 00:00:02 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Mon, 22 Dec 2008 10:00:02 -0500 (EST)
Subject: how to run dropbear on a system with a R/O /dev?
In-Reply-To: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>
References: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0812220957570.3880@localhost.localdomain>

On Mon, 22 Dec 2008, Robert P. J. Day wrote:

>
>   i suspect i already know the answer to this, but is there any way to
> run dropbear on a system whose /dev directory is part of a larger
> romfs?
>
>   ssh to such a system worked fine during development when the root
> filesystem was NFS mounted and, therefore, writable.  but once that
> rootfs is flashed and is now mounted as a romfs, not surprisingly,
> dropbear can no longer accept incoming requests because (i'm
> guessing) while the appropriate /dev/ttyp[0-9] device files are there,
> dropbear has no ability to change their owner/perms, is that it?
> which generates the log error message:
>
>    pty_allocate: openpty: No child processes
>    no pty was allocated, couldn't execute
>
>   is there a way around this?  i would have guessed not, but i'm
> willing to be pleasantly surprised.

  actually, a thought just occurred to me.  i checked and, with an NFS
mount with a writable /dev, an ssh session comes in and is associated
with a /dev/ttyp[0-9] device file (the first available one).

  is another option to mount the /dev/pts filesystem and, if so, would
dropbear try to grab one of *those* device files instead?  since
that's a pseudo filesystem, its device files should be writable, no?
even when /dev itself isn't.

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From grahame at angrygoats.net  Tue Dec 23 00:08:39 2008
From: grahame at angrygoats.net (Grahame Bowland)
Date: Tue, 23 Dec 2008 00:08:39 +0900
Subject: how to run dropbear on a system with a R/O /dev?
In-Reply-To: <alpine.LFD.2.00.0812220957570.3880@localhost.localdomain>
References: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>
	<alpine.LFD.2.00.0812220957570.3880@localhost.localdomain>
Message-ID: <be544bf70812220708p4a2969b3vbe370d341cc90ea1@mail.gmail.com>

2008/12/23 Robert P. J. Day <rpjday at crashcourse.ca>:
> On Mon, 22 Dec 2008, Robert P. J. Day wrote:
>
>>
>>   i suspect i already know the answer to this, but is there any way to
>> run dropbear on a system whose /dev directory is part of a larger
>> romfs?
>>
>>   ssh to such a system worked fine during development when the root
>> filesystem was NFS mounted and, therefore, writable.  but once that
>> rootfs is flashed and is now mounted as a romfs, not surprisingly,
>> dropbear can no longer accept incoming requests because (i'm
>> guessing) while the appropriate /dev/ttyp[0-9] device files are there,
>> dropbear has no ability to change their owner/perms, is that it?
>> which generates the log error message:
>>
>>    pty_allocate: openpty: No child processes
>>    no pty was allocated, couldn't execute
>>
>>   is there a way around this?  i would have guessed not, but i'm
>> willing to be pleasantly surprised.
>
>  actually, a thought just occurred to me.  i checked and, with an NFS
> mount with a writable /dev, an ssh session comes in and is associated
> with a /dev/ttyp[0-9] device file (the first available one).
>
>  is another option to mount the /dev/pts filesystem and, if so, would
> dropbear try to grab one of *those* device files instead?  since
> that's a pseudo filesystem, its device files should be writable, no?
> even when /dev itself isn't.

Hi Robert

Couldn't you mount a ramfs over /dev and create the necessary device files
in it? Should be easy enough to copy /dev to the ramfs first using tar or cpio.

Cheers
Grahame


From rpjday at crashcourse.ca  Tue Dec 23 00:10:55 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Mon, 22 Dec 2008 10:10:55 -0500 (EST)
Subject: how to run dropbear on a system with a R/O /dev?
In-Reply-To: <be544bf70812220708p4a2969b3vbe370d341cc90ea1@mail.gmail.com>
References: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>
	<alpine.LFD.2.00.0812220957570.3880@localhost.localdomain>
	<be544bf70812220708p4a2969b3vbe370d341cc90ea1@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0812221010140.4027@localhost.localdomain>

On Tue, 23 Dec 2008, Grahame Bowland wrote:

> 2008/12/23 Robert P. J. Day <rpjday at crashcourse.ca>:
> > On Mon, 22 Dec 2008, Robert P. J. Day wrote:
> >
> >>
> >>   i suspect i already know the answer to this, but is there any way to
> >> run dropbear on a system whose /dev directory is part of a larger
> >> romfs?
> >>
> >>   ssh to such a system worked fine during development when the root
> >> filesystem was NFS mounted and, therefore, writable.  but once that
> >> rootfs is flashed and is now mounted as a romfs, not surprisingly,
> >> dropbear can no longer accept incoming requests because (i'm
> >> guessing) while the appropriate /dev/ttyp[0-9] device files are there,
> >> dropbear has no ability to change their owner/perms, is that it?
> >> which generates the log error message:
> >>
> >>    pty_allocate: openpty: No child processes
> >>    no pty was allocated, couldn't execute
> >>
> >>   is there a way around this?  i would have guessed not, but i'm
> >> willing to be pleasantly surprised.
> >
> >  actually, a thought just occurred to me.  i checked and, with an NFS
> > mount with a writable /dev, an ssh session comes in and is associated
> > with a /dev/ttyp[0-9] device file (the first available one).
> >
> >  is another option to mount the /dev/pts filesystem and, if so, would
> > dropbear try to grab one of *those* device files instead?  since
> > that's a pseudo filesystem, its device files should be writable, no?
> > even when /dev itself isn't.
>
> Hi Robert
>
> Couldn't you mount a ramfs over /dev and create the necessary device files
> in it? Should be easy enough to copy /dev to the ramfs first using tar or cpio.

  that's possible, but i'd like to know about the mountable /dev/pts
option first, since that seems like a lot less work.

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From jacmet at sunsite.dk  Tue Dec 23 00:29:22 2008
From: jacmet at sunsite.dk (Peter Korsgaard)
Date: Mon, 22 Dec 2008 16:29:22 +0100
Subject: how to run dropbear on a system with a R/O /dev?
In-Reply-To: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>
	(Robert P. J. Day's message of "Mon\,
	22 Dec 2008 09\:53\:15 -0500 \(EST\)")
References: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>
Message-ID: <878wq8b54d.fsf@macbook.be.48ers.dk>

>>>>> "Robert" == Robert P J Day <rpjday at crashcourse.ca> writes:

Hi,

 Robert>   i suspect i already know the answer to this, but is there
 Robert> any way to run dropbear on a system whose /dev directory is
 Robert> part of a larger romfs?

Yes, we do that all the time.

 Robert>   ssh to such a system worked fine during development when
 Robert> the root filesystem was NFS mounted and, therefore, writable.
 Robert> but once that rootfs is flashed and is now mounted as a
 Robert> romfs, not surprisingly, dropbear can no longer accept
 Robert> incoming requests because (i'm guessing) while the
 Robert> appropriate /dev/ttyp[0-9] device files are there, dropbear
 Robert> has no ability to change their owner/perms, is that it?
 Robert> which generates the log error message:

Strange - Is this as root or any other user? We normally only use root,
but I'm pretty sure I have done it before as non-root.

We do have /dev/pts mounted, that may or may not make a difference
(didn't check the code).

-- 
Bye, Peter Korsgaard


From rpjday at crashcourse.ca  Tue Dec 23 00:51:26 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Mon, 22 Dec 2008 10:51:26 -0500 (EST)
Subject: how to run dropbear on a system with a R/O /dev?
In-Reply-To: <878wq8b54d.fsf@macbook.be.48ers.dk>
References: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>
	<878wq8b54d.fsf@macbook.be.48ers.dk>
Message-ID: <alpine.LFD.2.00.0812221042550.4414@localhost.localdomain>

On Mon, 22 Dec 2008, Peter Korsgaard wrote:

> >>>>> "Robert" == Robert P J Day <rpjday at crashcourse.ca> writes:
>
> Hi,
>
>  Robert>   i suspect i already know the answer to this, but is there
>  Robert> any way to run dropbear on a system whose /dev directory is
>  Robert> part of a larger romfs?
>
> Yes, we do that all the time.
>
>  Robert>   ssh to such a system worked fine during development when
>  Robert> the root filesystem was NFS mounted and, therefore, writable.
>  Robert> but once that rootfs is flashed and is now mounted as a
>  Robert> romfs, not surprisingly, dropbear can no longer accept
>  Robert> incoming requests because (i'm guessing) while the
>  Robert> appropriate /dev/ttyp[0-9] device files are there, dropbear
>  Robert> has no ability to change their owner/perms, is that it?
>  Robert> which generates the log error message:
>
> Strange - Is this as root or any other user? We normally only use root,
> but I'm pretty sure I have done it before as non-root.
>
> We do have /dev/pts mounted, that may or may not make a difference
> (didn't check the code).

  i may do that at the earliest possible opportunity, but here's
what's happening.  certainly, without mounting /dev/pts, i expect a
login failure since all of /dev is read-only.

  however, after i mount /dev/pts RW, i can see that i have two char
device files under there:  /dev/pts[01].  and i've verified i can
change their permissions with "chmod".  so that's a good sign -- that
the contents under /dev/pts are modifiable, at least to that extent.

  however, when i try to ssh into that system from elsewhere and i
watch the destination system /var/log/messages, i can see that the
password authentication succeeds, after which i get an authpriv.warn
log message complaining about syslogin_perform_logout: logout(pts/2)
returned an error: No such file or directory

  well, that's not surprising since, after mounting /dev/pts, i have
only two /dev/pts device files: 0 and 1.  and even as root, i don't
seem to have permission to create extras with "mknod".  i tried to
create a corresponding /dev/pts/2 using busybox's mknod, and got
"Operation not permitted."  in fact, if i "cd" to /dev/pts, i can't
even touch a regular file:  "Permission denied".

  do i need to mount /dev/pts with some special perms to allow new
files to be created?  and am i on the right path, since it *seems*
that my attempts to ssh in are at least trying to do *something* with
/dev/pts/2, so i'm taking that as a good sign.

rday
--



========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From fja0568 at gmail.com  Tue Dec 23 01:34:30 2008
From: fja0568 at gmail.com (Farrell Aultman)
Date: Mon, 22 Dec 2008 11:34:30 -0500
Subject: Patch to speed-up LibTomMath
In-Reply-To: <20081221042057.GE8640@ucc.gu.uwa.edu.au>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
	<52021.151.21.92.160.1229698637.squirrel@mail.dm.unipi.it>
	<39728748-F01B-4356-A533-C5A4C8BC606D@turczak.de>
	<200812202049.09844.rob@landley.net>
	<20081221042057.GE8640@ucc.gu.uwa.edu.au>
Message-ID: <3ba466150812220834m45aea524o3dea8743707a3f8e@mail.gmail.com>

The developer, Tom St. Denis got a job at a company called Elliptic
Engineering.  So, I guess he has less time for open source now.  Apparently
he developed his libraries when he was very young and and in his own works
"totally unhirable".

http://libtomcrypt.com/whatis.html


On Sat, Dec 20, 2008 at 11:20 PM, Matt Johnston <matt at ucc.asn.au> wrote:

> On Sat, Dec 20, 2008 at 08:49:09PM -0600, Rob Landley wrote:
> > Matt mentioned that libtomcrypt might not be particularly maintained
> anymore,
> > did Libtomsfastmath replace it or has the maintainer gone on to other
> things
> > entirely?
>
> I think tomsfastmath was meant to be a bit more limited in
> what it provides (though probably enough for RSA/DSS/DH),
> a bit less friendly to read/learn from, but quicker. I've
> mirrored the last release at
> http://matt.ucc.asn.au/mirror/tfm-0.10.tar.bz2
>
> > The freshmeat project was last updated over 2 years ago,
> > libtomcrypt.org isn't resolving at the DNS level, and the
> > google cache says it moved to libtom.org which times out
> > when I try to connect to it.
>
> libtomcrypt.com was working a couple of days ago, though
> seems to be timing out currently. Might be on the end of a
> DSL line.
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081222/3fc138b6/attachment.htm 

From fja0568 at gmail.com  Tue Dec 23 01:34:30 2008
From: fja0568 at gmail.com (Farrell Aultman)
Date: Mon, 22 Dec 2008 11:34:30 -0500
Subject: Patch to speed-up LibTomMath
In-Reply-To: <20081221042057.GE8640@ucc.gu.uwa.edu.au>
References: <42442.151.21.91.8.1229552407.squirrel@mail.dm.unipi.it>
	<52021.151.21.92.160.1229698637.squirrel@mail.dm.unipi.it>
	<39728748-F01B-4356-A533-C5A4C8BC606D@turczak.de>
	<200812202049.09844.rob@landley.net>
	<20081221042057.GE8640@ucc.gu.uwa.edu.au>
Message-ID: <3ba466150812220834m45aea524o3dea8743707a3f8e@mail.gmail.com>

The developer, Tom St. Denis got a job at a company called Elliptic
Engineering.  So, I guess he has less time for open source now.  Apparently
he developed his libraries when he was very young and and in his own works
"totally unhirable".

http://libtomcrypt.com/whatis.html


On Sat, Dec 20, 2008 at 11:20 PM, Matt Johnston <matt at ucc.asn.au> wrote:

> On Sat, Dec 20, 2008 at 08:49:09PM -0600, Rob Landley wrote:
> > Matt mentioned that libtomcrypt might not be particularly maintained
> anymore,
> > did Libtomsfastmath replace it or has the maintainer gone on to other
> things
> > entirely?
>
> I think tomsfastmath was meant to be a bit more limited in
> what it provides (though probably enough for RSA/DSS/DH),
> a bit less friendly to read/learn from, but quicker. I've
> mirrored the last release at
> http://matt.ucc.asn.au/mirror/tfm-0.10.tar.bz2
>
> > The freshmeat project was last updated over 2 years ago,
> > libtomcrypt.org isn't resolving at the DNS level, and the
> > google cache says it moved to libtom.org which times out
> > when I try to connect to it.
>
> libtomcrypt.com was working a couple of days ago, though
> seems to be timing out currently. Might be on the end of a
> DSL line.
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20081222/3fc138b6/attachment-0001.htm 

From matt at ucc.asn.au  Tue Dec 23 22:54:05 2008
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 23 Dec 2008 22:54:05 +0900
Subject: how to run dropbear on a system with a R/O /dev?
In-Reply-To: <alpine.LFD.2.00.0812221042550.4414@localhost.localdomain>
References: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>
	<878wq8b54d.fsf@macbook.be.48ers.dk>
	<alpine.LFD.2.00.0812221042550.4414@localhost.localdomain>
Message-ID: <20081223135405.GF8640@ucc.gu.uwa.edu.au>

On Mon, Dec 22, 2008 at 10:51:26AM -0500, Robert P. J. Day wrote:
> > We do have /dev/pts mounted, that may or may not make a difference
> > (didn't check the code).
> 
>   i may do that at the earliest possible opportunity, but here's
> what's happening.  certainly, without mounting /dev/pts, i expect a
> login failure since all of /dev is read-only.
> 
>   however, after i mount /dev/pts RW, i can see that i have two char
> device files under there:  /dev/pts[01].  and i've verified i can
> change their permissions with "chmod".  so that's a good sign -- that
> the contents under /dev/pts are modifiable, at least to that extent.
> 
>   however, when i try to ssh into that system from elsewhere and i
> watch the destination system /var/log/messages, i can see that the
> password authentication succeeds, after which i get an authpriv.warn
> log message complaining about syslogin_perform_logout: logout(pts/2)
> returned an error: No such file or directory

Devices in /dev/pts get "automatically" created by the
openpty() call made by Dropbear - you don't create files
there yourself.  The usual tool I use for debugging things
like this is strace - run "strace -f" on the main Dropbear
process, if it's available. Are there any other log messages
suggesting why it's failing? 

The "logout" log warning isn't something to worry about -
that just means that it couldn't write user login/logout
details to /var/log/wtmp or /var/log/utmp.  You can
configure Dropbear with --disable-loginfunc to avoid it
trying that.

Also to eliminate other factors, check that "ssh -T" to the
host works. That will skip the tty allocation stage
entirely, you should still be able to run commands like "ls"
and get output.

Cheers,
Matt

From rpjday at crashcourse.ca  Tue Dec 23 23:19:39 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Tue, 23 Dec 2008 09:19:39 -0500 (EST)
Subject: how to run dropbear on a system with a R/O /dev?
In-Reply-To: <20081223135405.GF8640@ucc.gu.uwa.edu.au>
References: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>
	<878wq8b54d.fsf@macbook.be.48ers.dk>
	<alpine.LFD.2.00.0812221042550.4414@localhost.localdomain>
	<20081223135405.GF8640@ucc.gu.uwa.edu.au>
Message-ID: <alpine.LFD.2.00.0812230919340.8306@localhost.localdomain>

On Tue, 23 Dec 2008, Matt Johnston wrote:

> On Mon, Dec 22, 2008 at 10:51:26AM -0500, Robert P. J. Day wrote:
> > > We do have /dev/pts mounted, that may or may not make a
> > > difference (didn't check the code).
> >
> >   i may do that at the earliest possible opportunity, but here's
> > what's happening.  certainly, without mounting /dev/pts, i expect
> > a login failure since all of /dev is read-only.
> >
> >   however, after i mount /dev/pts RW, i can see that i have two
> > char device files under there:  /dev/pts[01].  and i've verified i
> > can change their permissions with "chmod".  so that's a good sign
> > -- that the contents under /dev/pts are modifiable, at least to
> > that extent.
> >
> >   however, when i try to ssh into that system from elsewhere and i
> > watch the destination system /var/log/messages, i can see that the
> > password authentication succeeds, after which i get an
> > authpriv.warn log message complaining about
> > syslogin_perform_logout: logout(pts/2) returned an error: No such
> > file or directory
>
> Devices in /dev/pts get "automatically" created by the
> openpty() call made by Dropbear - you don't create files
> there yourself.

  here's the first issue.  when i'm connecting to a system that has
its root FS mounted via NFS, i can connect one of two ways.  if i
connect using busybox's telnetd running on the system, "tty" shows me
that telnetd uses one of the /dev/pts/ tty devices.  if, however, i
connect to dropbear using "ssh", "tty" shows me that dropbear used one
of the /dev/ttyp? devices.  what does this mean?  that dropbear will
try to use one of those types, then the other if none are available?
or what?

  i ask since you mentioned /dev/pts specifically above, but that's
not the device file that dropbear is using here.  and that could make
a huge difference in what happens later.

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From rpjday at crashcourse.ca  Wed Dec 24 03:30:10 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Tue, 23 Dec 2008 13:30:10 -0500 (EST)
Subject: how to run dropbear on a system with a R/O /dev?
In-Reply-To: <20081223135405.GF8640@ucc.gu.uwa.edu.au>
References: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>
	<878wq8b54d.fsf@macbook.be.48ers.dk>
	<alpine.LFD.2.00.0812221042550.4414@localhost.localdomain>
	<20081223135405.GF8640@ucc.gu.uwa.edu.au>
Message-ID: <alpine.LFD.2.00.0812231325090.10245@localhost.localdomain>

On Tue, 23 Dec 2008, Matt Johnston wrote:

> On Mon, Dec 22, 2008 at 10:51:26AM -0500, Robert P. J. Day wrote:
> > > We do have /dev/pts mounted, that may or may not make a difference
> > > (didn't check the code).
> >
> >   i may do that at the earliest possible opportunity, but here's
> > what's happening.  certainly, without mounting /dev/pts, i expect
> > a login failure since all of /dev is read-only.
> >
> >   however, after i mount /dev/pts RW, i can see that i have two
> > char device files under there:  /dev/pts[01].  and i've verified i
> > can change their permissions with "chmod".  so that's a good sign
> > -- that the contents under /dev/pts are modifiable, at least to
> > that extent.
> >
> >   however, when i try to ssh into that system from elsewhere and i
> > watch the destination system /var/log/messages, i can see that the
> > password authentication succeeds, after which i get an
> > authpriv.warn log message complaining about
> > syslogin_perform_logout: logout(pts/2) returned an error: No such
> > file or directory
>
> Devices in /dev/pts get "automatically" created by the openpty()
> call made by Dropbear - you don't create files there yourself.  The
> usual tool I use for debugging things like this is strace - run
> "strace -f" on the main Dropbear process, if it's available. Are
> there any other log messages suggesting why it's failing?

  to summarize what i'm seeing via "strace -f dropbear" (and i'm
reproducing this manually looking from one system to another):

 *  stat64("/dev/ttyp0", ...)
 *  ...
 *  lchown32("/dev/ttyp0", 0, 5) = -1 EROFS (Read-only file system)

  can i take a guess at what's happening?  dropbear wants to open a
session on /dev/ttyp0, it stat's that device file, finds it and
commits to it, only to find later that it can't modify the file
attributes and craps out.  is that remotely accurate?

  and i don't see how dropbear gets around to working with anything
under /dev/pts.  on another system that is NFS-mounted and on which
dropbear works fine, any ssh session always corresponds to a
/dev/ttyp* file.  so what does /dev/pts/? have to do with any of this?

rday
--



========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================


From rpjday at crashcourse.ca  Wed Dec 24 05:12:02 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Tue, 23 Dec 2008 15:12:02 -0500 (EST)
Subject: how to run dropbear on a system with a R/O /dev?  [SOLVED!]
In-Reply-To: <20081223135405.GF8640@ucc.gu.uwa.edu.au>
References: <alpine.LFD.2.00.0812220946280.3790@localhost.localdomain>
	<878wq8b54d.fsf@macbook.be.48ers.dk>
	<alpine.LFD.2.00.0812221042550.4414@localhost.localdomain>
	<20081223135405.GF8640@ucc.gu.uwa.edu.au>
Message-ID: <alpine.LFD.2.00.0812231510070.11143@localhost.localdomain>

On Tue, 23 Dec 2008, Matt Johnston wrote:

> On Mon, Dec 22, 2008 at 10:51:26AM -0500, Robert P. J. Day wrote:
> > > We do have /dev/pts mounted, that may or may not make a difference
> > > (didn't check the code).
> >
> >   i may do that at the earliest possible opportunity, but here's
> > what's happening.  certainly, without mounting /dev/pts, i expect
> > a login failure since all of /dev is read-only.
> >
> >   however, after i mount /dev/pts RW, i can see that i have two
> > char device files under there:  /dev/pts[01].  and i've verified i
> > can change their permissions with "chmod".  so that's a good sign
> > -- that the contents under /dev/pts are modifiable, at least to
> > that extent.
> >
> >   however, when i try to ssh into that system from elsewhere and i
> > watch the destination system /var/log/messages, i can see that the
> > password authentication succeeds, after which i get an
> > authpriv.warn log message complaining about
> > syslogin_perform_logout: logout(pts/2) returned an error: No such
> > file or directory
>
> Devices in /dev/pts get "automatically" created by the
> openpty() call made by Dropbear - you don't create files
> there yourself.  The usual tool I use for debugging things
> like this is strace - run "strace -f" on the main Dropbear
> process, if it's available. Are there any other log messages
> suggesting why it's failing?

  i hacked into the flashed system, and simply added a mount of the
/dev/pts filesystem and, upon reboot, an attempt to ssh to the system
caused dropbear to allocate /dev/pts/1.  so this is progress.
apparently, mounting that filesystem manually before didn't work, but
having it mounted as part of the normal boot process was sufficient.

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================