From matt at ucc.asn.au  Mon Jan  3 23:13:07 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon Jan  3 23:13:15 2005
Subject: Dropbear 0.44 release
Message-ID: <20050103151307.GB14942@morwong.ucc.gu.uwa.edu.au>

Hi all.

I've packaged up Dropbear 0.44, which I've deemed to be a
stable release with client and server functionality. 

 From the previous 0.44test4 release there were a couple of
new features added, notably pristine compilation support
(run configure from a directory elsewhere then run make
there), scp -i has been fixed, and various compilation
problems have been fixed. 

As usual there are a number of less noticable bugfixes - in
particular if you were using PAM functionality in 0.44test4
(by default it wasn't enabled), a fairly serious security
double-free() bug has been fixed in this release. This is
probably remotely exploitable, so you are very strongly
advised to upgrade.


Compared to 0.43, some of the noteworthy changes include:

- client support
- IPv6 support
- improved channel window sizing (should improve transfer
  rates for incoming data)
- in terms of code design, the common, client, and server
  portions have been seperated out
Of course there are also numerous bugfixes etc - see CHANGES
for details.

I've switched to using monotone for version control, I'll
have the repository linked off the main page in the next day
or so.

Matt
From claas+maillinglists.dropbear at jucs-kramkiste.de  Mon Jan 10 18:06:25 2005
From: claas+maillinglists.dropbear at jucs-kramkiste.de (Claas Hilbrecht)
Date: Mon Jan 10 19:02:40 2005
Subject: Dropbear 0.44 release
In-Reply-To: <20050103151307.GB14942@morwong.ucc.gu.uwa.edu.au>
References: <20050103151307.GB14942@morwong.ucc.gu.uwa.edu.au>
Message-ID: <3661FA3D8BF58F0FD8111006@[192.168.1.22]>

--Am Montag, 3. Januar 2005 23:13 +0800 Matt Johnston <matt@ucc.asn.au> 
schrieb:

> I've packaged up Dropbear 0.44, which I've deemed to be a
> stable release with client and server functionality.

I've found three problems with the 0.44 release:

a) Running scp with dbclient gives everytime the following messages:

WARNING: Ignoring unknown argument '-x'
WARNING: Ignoring unknown argument '-oForwardAgent no'
WARNING: Ignoring unknown argument '-oClearAllForwardings yes'

With the -v option and additional line with

WARNING: Ignoring unknown argument '-v'

is given. Nevertheless the scp will work so this is only a cosmetic thing.

b) Run a "scp <file> <host>" command to a host you never connected before. 
Now the following question is issued:

Host '192.168.193.251' is not in the trusted hosts file.
(fingerprint md5 c0:e0:89:a3:62:36:3b:16:86:13:2e:9b:11:f3:6b:71)
Do you want to continue connecting? (y/n)

Whatever I type I can't continue. Only a CTRL-C will work (or a kill from 
another terminal). Running the dbclient before the scp command and adding 
the host to the list of known hosts solves the problem.

c) I can't connect to a host that is running OpenSSH 3.9.0pl1. Every login 
attempt is recorded as a password failure on the sshd server side. What is 
causing the password failure is not loggable, even with LogInfo DEBUG2 on 
the sshd server side. The only noticable thing is that the sshd server is 
patched with a "Dynamic Window patch" (see 
<http://www.psc.edu/networking/projects/hpn-ssh/>). Other clients (putty, 
ssh from debian woody, sarge, aix) can connect to the host without problems.


-- 
 Claas Hilbrecht
 http://www.jucs-kramkiste.de


From matt at ucc.asn.au  Mon Jan 10 23:30:00 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon Jan 10 23:30:19 2005
Subject: Dropbear 0.44 release
In-Reply-To: <3661FA3D8BF58F0FD8111006@[192.168.1.22]>
References: <20050103151307.GB14942@morwong.ucc.gu.uwa.edu.au>
	<3661FA3D8BF58F0FD8111006@[192.168.1.22]>
Message-ID: <20050110153000.GC13692@morwong.ucc.gu.uwa.edu.au>

(forgot to cc to the list)

On Mon, Jan 10, 2005 at 11:06:25AM +0100, Claas Hilbrecht wrote:
> --Am Montag, 3. Januar 2005 23:13 +0800 Matt Johnston <matt@ucc.asn.au> 
> schrieb:
> 
> >I've packaged up Dropbear 0.44, which I've deemed to be a
> >stable release with client and server functionality.
> 
> I've found three problems with the 0.44 release:
> 
> a) Running scp with dbclient gives everytime the following messages:
> 
> WARNING: Ignoring unknown argument '-x'
> WARNING: Ignoring unknown argument '-oForwardAgent no'
> WARNING: Ignoring unknown argument '-oClearAllForwardings yes'
> 
> With the -v option and additional line with
> 
> WARNING: Ignoring unknown argument '-v'
> 
> is given. Nevertheless the scp will work so this is only a cosmetic thing.

*nod* I don't really want to ignore unknown arguments in the
general case, since that would make debugging more awkward.
I'll have a look at ignoring just scp's arguments or
something.
> 
> b) Run a "scp <file> <host>" command to a host you never connected before. 
> Now the following question is issued:
> 
> Host '192.168.193.251' is not in the trusted hosts file.
> (fingerprint md5 c0:e0:89:a3:62:36:3b:16:86:13:2e:9b:11:f3:6b:71)
> Do you want to continue connecting? (y/n)
> 
> Whatever I type I can't continue. Only a CTRL-C will work (or a kill from 
> another terminal). Running the dbclient before the scp command and adding 
> the host to the list of known hosts solves the problem.

Ah, I had forgotten that this was the issue, I was thinking
it was that password auth failed with scp - sorry. I'll look
at a patch for it.
> 
> c) I can't connect to a host that is running OpenSSH 3.9.0pl1. Every login 
> attempt is recorded as a password failure on the sshd server side. What is 
> causing the password failure is not loggable, even with LogInfo DEBUG2 on 
> the sshd server side. The only noticable thing is that the sshd server is 
> patched with a "Dynamic Window patch" (see 
> <http://www.psc.edu/networking/projects/hpn-ssh/>). Other clients (putty, 
> ssh from debian woody, sarge, aix) can connect to the host without problems.

Is "PasswordAuthentication" enabled in /etc/ssh/sshd_config?
I think in 3.8.something it was disabled by default in
debian at least - Dropbear doesn't currently support it. If
that's not the problem, the output of ssh -vvv would be
useful.

Cheers,
Matt
From gavinux at yahoo.com  Thu Jan 13 03:34:08 2005
From: gavinux at yahoo.com (Gavinux)
Date: Thu Jan 13 03:34:43 2005
Subject: dropbearkey freeze
Message-ID: <20050112193408.29238.qmail@web50310.mail.yahoo.com>

my embedded system's root file system is on a NFS
server which is running RedHat7.3
I put the command dropbearkey -t dss -f
/etc/dropbear/dropbear_dss_host_key in my embedded
system's /etc/rc.d/rcS, this dropbearkey takes more
than half hour to create the key. But After I boot the
system up, I login as root and removed the key file,
then I do dropbearkey -t dss -f
/etc/dropbear/dropbear_dss_host_key in bash command
line, it finished in just a few seconds.


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 


From matt at ucc.asn.au  Thu Jan 13 11:17:28 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu Jan 13 11:17:33 2005
Subject: dropbearkey freeze
In-Reply-To: <20050112193408.29238.qmail@web50310.mail.yahoo.com>
References: <20050112193408.29238.qmail@web50310.mail.yahoo.com>
Message-ID: <20050113031728.GA166310@morwong.ucc.gu.uwa.edu.au>

On Wed, Jan 12, 2005 at 11:34:08AM -0800, Gavinux wrote:
> my embedded system's root file system is on a NFS
> server which is running RedHat7.3
> I put the command dropbearkey -t dss -f
> /etc/dropbear/dropbear_dss_host_key in my embedded
> system's /etc/rc.d/rcS, this dropbearkey takes more
> than half hour to create the key. But After I boot the
> system up, I login as root and removed the key file,
> then I do dropbearkey -t dss -f
> /etc/dropbear/dropbear_dss_host_key in bash command
> line, it finished in just a few seconds.

Are you using 0.44 to generate the key? I wonder if
dropbearkey is blocking waiting for random data from
/dev/random - at boot the system possibly doesn't have
enough entropy, so won't produce output from /dev/random.

Versions prior to 0.44 used /dev/urandom (set in options.h),
which does not block - this is insecure if the system hasn't
got enough entropy, as the "random" data may actually be
near-guessable.

Would there be any possibility of securely storing a
seed between reboots, and feeding that to /dev/urandom at
boot time? Look at the comment "Ensuring unpredictability at
system startup" in Linux's random.c [1] for an example. I
don't think adding data will actually increase the entropy
count so /dev/random will probably still block, though if
you're certain there is sufficient entropy, /dev/urandom may
be suitable. The best solution is probably to find an
improved random source, though that could be difficult
depending on your device.

As an aside, are you sure that dropbearkey should be run
every time at startup?  (If it's just exiting since the key
already exists then that's fine).

Matt

[1] http://kernel.kernelnotes.de/linux-2.6.3/drivers/char/random.c
From erik at hovland.org  Fri Jan 14 05:10:00 2005
From: erik at hovland.org (Erik Hovland)
Date: Fri Jan 14 05:10:23 2005
Subject: [Familiar] problem w/ dropbear ssh
In-Reply-To: <1105567766.7927.26.camel@localhost.localdomain>
References: <20050112215335.GB28452@mage.jpl.nasa.gov>
	<1105567766.7927.26.camel@localhost.localdomain>
Message-ID: <20050113211000.GB27101@mage.jpl.nasa.gov>

On Wed, Jan 12, 2005 at 10:09:25PM +0000, Phil Blundell wrote:
> On Wed, 2005-01-12 at 13:53 -0800, Erik Hovland wrote:
> > Any advice? I am happy to use openssh. But its large size makes it
> > unattractive to others. Is there a way to provide dropbear for sshd and
> > openssh for ssh? It probably is more cumbersome for package maintainers
> > but more flexible for users.
> 
> Yeah, this would just be a question of making the packages a bit more
> granular and using update-alternatives.  There's also a third ssh client
> option available, namely putty.
> 
> Of course, the best thing would be to fix the bug in Dropbear.  I don't
> imagine this can be terribly difficult.  Maybe someone would like to
> have a go at that?

Ok, I'll have a go. Patch attached. It seems ssh was barfing on the
2048-bit key the remote host was offering.

This fixed the problem for me. But I have no idea if there are
ramifications for increasing the kex buffer size by 50%.

E

-- 
Erik Hovland
mail: erik AT hovland DOT org
web: http://hovland.org/
PGP/GPG public key available on request
-------------- next part --------------
--- kex.h.orig	2005-01-13 12:39:26.081910000 -0800
+++ kex.h	2005-01-13 12:36:46.929681000 -0800
@@ -64,6 +64,6 @@
 
 };
 
-#define MAX_KEXHASHBUF 2000
+#define MAX_KEXHASHBUF 3000
 
 #endif /* _KEX_H_ */
From matt at ucc.asn.au  Fri Jan 14 13:11:15 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Fri Jan 14 13:11:36 2005
Subject: Dropbear 0.44 release
In-Reply-To: <20050110153000.GC13692@morwong.ucc.gu.uwa.edu.au>
References: <20050103151307.GB14942@morwong.ucc.gu.uwa.edu.au>
	<3661FA3D8BF58F0FD8111006@[192.168.1.22]>
	<20050110153000.GC13692@morwong.ucc.gu.uwa.edu.au>
Message-ID: <20050114051115.GD178047@morwong.ucc.gu.uwa.edu.au>

On Mon, Jan 10, 2005 at 11:30:00PM +0800, Matt Johnston wrote:
> > b) Run a "scp <file> <host>" command to a host you never connected before. 
> > Now the following question is issued:
> > 
> > Host '192.168.193.251' is not in the trusted hosts file.
> > (fingerprint md5 c0:e0:89:a3:62:36:3b:16:86:13:2e:9b:11:f3:6b:71)
> > Do you want to continue connecting? (y/n)
> > 
> > Whatever I type I can't continue. Only a CTRL-C will work (or a kill from 
> > another terminal). Running the dbclient before the scp command and adding 
> > the host to the list of known hosts solves the problem.
> 
> Ah, I had forgotten that this was the issue, I was thinking
> it was that password auth failed with scp - sorry. I'll look
> at a patch for it.

Attached is a patch which should fix the issue, it'll be in
the next release.  As usual let me know if there are any
issues with it.

Matt
-------------- next part --------------
--- cli-kex.c
+++ cli-kex.c
@@ -115,13 +115,23 @@
 static void ask_to_confirm(unsigned char* keyblob, unsigned int keybloblen) {
 
 	char* fp = NULL;
+	FILE *tty = NULL;
+	char response = 'z';
 
 	fp = sign_key_fingerprint(keyblob, keybloblen);
 	fprintf(stderr, "\nHost '%s' is not in the trusted hosts file.\n(fingerprint %s)\nDo you want to continue connecting? (y/n)\n", 
 			cli_opts.remotehost, 
 			fp);
 
-	if (getc(stdin) == 'y') {
+	tty = fopen(_PATH_TTY, "r");
+	if (tty) {
+		response = getc(tty);
+		fclose(tty);
+	} else {
+		response = getc(stdin);
+	}
+
+	if (response == 'y') {
 		m_free(fp);
 		return;
 	}
From matt at ucc.asn.au  Fri Jan 14 13:53:06 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Fri Jan 14 13:53:29 2005
Subject: [Familiar] problem w/ dropbear ssh
In-Reply-To: <20050113211000.GB27101@mage.jpl.nasa.gov>
References: <20050112215335.GB28452@mage.jpl.nasa.gov>
	<1105567766.7927.26.camel@localhost.localdomain>
	<20050113211000.GB27101@mage.jpl.nasa.gov>
Message-ID: <20050114055306.GE178047@morwong.ucc.gu.uwa.edu.au>

On Thu, Jan 13, 2005 at 01:10:00PM -0800, Erik Hovland wrote:

> Ok, I'll have a go. Patch attached. It seems ssh was barfing on the
> 2048-bit key the remote host was offering.
> 
> This fixed the problem for me. But I have no idea if there are
> ramifications for increasing the kex buffer size by 50%.

Yep, that patch looks fairly sane, I think the 2000 bytes
was somewhat arbitrary. The proper solution might be to set
the size at runtime rather than a fixed value - I'll look at
that for the next release.

Cheers,
Matt

> --- kex.h.orig	2005-01-13 12:39:26.081910000 -0800
> +++ kex.h	2005-01-13 12:36:46.929681000 -0800
> @@ -64,6 +64,6 @@
>  
>  };
>  
> -#define MAX_KEXHASHBUF 2000
> +#define MAX_KEXHASHBUF 3000
>  
>  #endif /* _KEX_H_ */

From david at aogsquid.ucsd.edu  Tue Jan 11 04:53:05 2005
From: david at aogsquid.ucsd.edu (David Horwitt)
Date: Fri Jan 14 13:54:48 2005
Subject: bad buf_getbyte
Message-ID: <41E2EB31.7040300@aogsquid.ucsd.edu>

I'm getting "bad buf_getbyte" errors (and session closing) when connecting from Solaris SSH to dropbearmulti
0.44 running on Linux 2.6.8.1. At least one other person is having problems as well 
(http://www.dbforums.com/t1086039.html; this has some trace info as well).

Setup works OK with FreeBSD, Linux test systems. Any ideas on fixes/workarounds?

Thanks,
David Horwitt
Scripps Institution of Oceanography

From claas+maillinglists.dropbear at jucs-kramkiste.de  Fri Jan 14 20:47:03 2005
From: claas+maillinglists.dropbear at jucs-kramkiste.de (Claas Hilbrecht)
Date: Fri Jan 14 21:04:52 2005
Subject: Dropbear 0.44 release
In-Reply-To: <20050114051115.GD178047@morwong.ucc.gu.uwa.edu.au>
References: <20050103151307.GB14942@morwong.ucc.gu.uwa.edu.au>
	<3661FA3D8BF58F0FD8111006@[192.168.1.22]>
	<20050110153000.GC13692@morwong.ucc.gu.uwa.edu.au>
	<20050114051115.GD178047@morwong.ucc.gu.uwa.edu.au>
Message-ID: <88B7E09C82E31118251A8D83@[192.168.1.22]>

--Am Freitag, 14. Januar 2005 13:11 +0800 Matt Johnston <matt@ucc.asn.au> 
schrieb:

> Attached is a patch which should fix the issue, it'll be in
> the next release.  As usual let me know if there are any
> issues with it.

Yes, the patch works fine. Good work.

-- 
 Claas Hilbrecht
 http://www.jucs-kramkiste.de


From oleg at cs.msu.su  Fri Jan 14 23:41:36 2005
From: oleg at cs.msu.su (Oleg I. Vdovikin)
Date: Fri Jan 14 23:41:57 2005
Subject: DO_HOST_LOOKUP option is ignored
Message-ID: <002501c4fa4f$8957a780$8102180a@mlab.cs.msu.su>

Hi,

    0.44 release is silently ignores DO_HOST_LOOKUP option from the
options.h. It's always performs host lookups, which results in long initial
password prompt delays, when reverse mapping is not established or not
known... Version prior to 0.44 worked fine.

    Is there any fix already available?

Regards,
Oleg.


From erik at hovland.org  Sun Jan 16 06:34:48 2005
From: erik at hovland.org (Erik Hovland)
Date: Sun Jan 16 06:34:36 2005
Subject: bad buf_getbyte
In-Reply-To: <41E2EB31.7040300@aogsquid.ucsd.edu>
References: <41E2EB31.7040300@aogsquid.ucsd.edu>
Message-ID: <20050115223448.GB6531@hovland.org>

On Mon, Jan 10, 2005 at 12:53:05PM -0800, David Horwitt wrote:
> I'm getting "bad buf_getbyte" errors (and session closing) when connecting 
> from Solaris SSH to dropbearmulti
> 0.44 running on Linux 2.6.8.1. At least one other person is having problems 
> as well (http://www.dbforums.com/t1086039.html; this has some trace info as 
> well).
> 
> Setup works OK with FreeBSD, Linux test systems. Any ideas on 
> fixes/workarounds?

Don't know. Did you see my patch that just increased the kex buffer?
http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2005q1/000152.html

The symptom of my problem was that the host key was too large (2048 bit)
to fit in the buffer. Probably your's and Dragan's are similar in that a
buffer that dropbear is using is too small for whatever is being sent to
it.

I have access to solaris boxen. If you give me a better idea of what
ssh, what version of solaris and if there is any thing exotic about your
config I could try to recreate it and maybe improve the trace of the
problem.

E

-- 
Erik Hovland
mail: erik@hovland.org
web: http://hovland.org/
PGP/GPG public key available on request

From lupsyn at mojodo.it  Tue Jan 18 07:52:55 2005
From: lupsyn at mojodo.it (Enrico lupsyn Del Zotto)
Date: Tue Jan 18 07:53:32 2005
Subject: Problem with login without password
Message-ID: <E894D39C-68E2-11D9-809A-000A95C0B12C@mojodo.it>

So this is the problem, i try to find a clear solution in google and in 
ml archive but i don't have clear ideas ...so please can you help me?

This is the problem :

redragon (the little linux terminal in that there is a version of 
dropbear )

Joshua ( the server )

So i must login and scp in Joshua without the request of password (i'm 
coding a sh script in that i can't wait the password prompt)...
i understand that i must work with the ssh keys but i can't understand 
how generate ( ssh-keygen in the server but in the client  ? ) it
and how file i have to export in the server or viceversa.

I don't have clear ideas .... !

Thx

Enrico "lupsyn" Del Zotto

Home page     http://hell.homelinux.com
Co-founder of http://www.mojodo.it
Icq 18119699
Msn lupsyn@mojodo.it
Aol-ichat lupsyn
irc lupsyn@irc.net #mojodo,#linux-it

Public pgp key available here
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2B2CAEAA


From lupsyn at mojodo.it  Tue Jan 18 19:29:28 2005
From: lupsyn at mojodo.it (Enrico lupsyn Del Zotto)
Date: Tue Jan 18 19:30:21 2005
Subject: Problem with login without password
In-Reply-To: <41ECBD38.2050309@freesco.info>
References: <E894D39C-68E2-11D9-809A-000A95C0B12C@mojodo.it>
	<41ECBD38.2050309@freesco.info>
Message-ID: <371C7D4E-6944-11D9-B606-000A95C0B12C@mojodo.it>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

i try ti do it with ssh-keygen in my linux but  when i try to pass the 
generate file drop bear ssh client says that the string is too long or 
can't load the key...

Il giorno 18/gen/05, alle 08:39, Lewis ha scritto:

> Well personally I don't  use dropbear in that manor, but basically 
> what you have to do is to copy the rsa key  file from the server side 
> into the client users home directory under a .ssh directory. Then 
> configure the appropriate flag to tell the client to send the key 
> rather than asking for a password prompt. Of course some of this is a 
> little dependent on the client, but all ssh clients are compliant to 
> be able to do it.
>
> Regards,
> Lewis
>
>
> Enrico lupsyn Del Zotto wrote:
>
>> So this is the problem, i try to find a clear solution in google and 
>> in ml archive but i don't have clear ideas ...so please can you help 
>> me?
>>
>> This is the problem :
>>
>> redragon (the little linux terminal in that there is a version of 
>> dropbear )
>>
>> Joshua ( the server )
>>
>> So i must login and scp in Joshua without the request of password 
>> (i'm coding a sh script in that i can't wait the password prompt)...
>> i understand that i must work with the ssh keys but i can't 
>> understand how generate ( ssh-keygen in the server but in the client  
>> ? ) it
>> and how file i have to export in the server or viceversa.
>>
>> I don't have clear ideas .... !
>>
>> Thx
>>
>> Enrico "lupsyn" Del Zotto
>>
>> Home page     http://hell.homelinux.com
>> Co-founder of http://www.mojodo.it
>> Icq 18119699
>> Msn lupsyn@mojodo.it
>> Aol-ichat lupsyn
>> irc lupsyn@irc.net #mojodo,#linux-it
>>
>> Public pgp key available here
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2B2CAEAA
>>
>>
>>
>>
>>
>>
>>
>
>
>
> -- 
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 1/17/05
>
>
>
>
Enrico "lupsyn" Del Zotto

Home page     http://hell.homelinux.com
Co-founder of http://www.mojodo.it
Icq 18119699
Msn lupsyn@mojodo.it
Aol-ichat lupsyn
irc lupsyn@irc.net #mojodo,#linux-it

Public pgp key available here
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2B2CAEAA


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB7PMaZOGtEyssrqoRAksvAKCUFT9/xX3XBsM8G7C9ylke2MCLAgCcCLHv
6k/a4OAjdjIdcf6pF12tXZc=
=lY1C
-----END PGP SIGNATURE-----


From matt at ucc.asn.au  Wed Jan 19 01:20:32 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed Jan 19 01:20:39 2005
Subject: Problem with login without password
In-Reply-To: <371C7D4E-6944-11D9-B606-000A95C0B12C@mojodo.it>
References: <E894D39C-68E2-11D9-809A-000A95C0B12C@mojodo.it>
	<41ECBD38.2050309@freesco.info>
	<371C7D4E-6944-11D9-B606-000A95C0B12C@mojodo.it>
Message-ID: <20050118172032.GB444829@morwong.ucc.gu.uwa.edu.au>

On Tue, Jan 18, 2005 at 12:29:28PM +0100, Enrico lupsyn Del Zotto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> i try ti do it with ssh-keygen in my linux but  when i try to pass the 
> generate file drop bear ssh client says that the string is too long or 
> can't load the key...

Could you paste the commands you're trying and the output it
gives?

Matt
From david at aogsquid.ucsd.edu  Wed Jan 19 04:06:34 2005
From: david at aogsquid.ucsd.edu (David Horwitt)
Date: Wed Jan 19 04:07:05 2005
Subject: bad buf_getbyte patch
Message-ID: <41ED6C4A.4020003@aogsquid.ucsd.edu>

I created a workaround/fix for my bad buf_getbyte problem:

*** svr-chansession.c   2005-01-11 13:14:54.000000000 -0800
--- svr-chansession.c.orig      2005-01-03 01:24:04.000000000 -0800
***************
*** 439,445 ****

         if (len == 0) {
                 TRACE(("leave get_termmodes: empty terminal modes string"))
-               return;
         }

         while (((opcode = buf_getbyte(ses.payload)) != 0x00) && opcode <= 159) {
--- 439,444 ----

This seems to work OK w/out ill effects; the TRACE message implies that the return that I added may have
been intended all along.

Cheers,
David Horwitt

From pgf at brightstareng.com  Wed Jan 19 04:29:24 2005
From: pgf at brightstareng.com (Paul Fox)
Date: Wed Jan 19 04:29:40 2005
Subject: bad buf_getbyte
Message-ID: <26211.1106080164@brightstareng.com>

 > I'm getting "bad buf_getbyte" errors (and session closing) when
 > connecting from Solaris SSH to dropbearmulti

i got this too, using a java ssh client.  if your problem is the
same as mine, it's because of an apparent edit error in [what
used to be sessionpty(), but what is now] get_termmodes(), in
svr-chansession.c.

i believe there's a missing "return" at line 441:

        if (len == 0) {
                TRACE(("leave get_termmodes: empty terminal modes string"))
 missing -->    return;
        }       



this begs a question for me -- how much upheaval was there in the
0.44 release?  i'm planning on using dropbear in an application
that doesn't need client functionality.  should i stick with 0.43
for this use?

paul


=---------------------
 paul fox, pgf@brightstareng.com

From pgf at brightstareng.com  Wed Jan 19 04:44:38 2005
From: pgf at brightstareng.com (Paul Fox)
Date: Wed Jan 19 04:45:04 2005
Subject: bad buf_getbyte 
In-Reply-To: pgf's message of Tue, 18 Jan 2005 15:29:24 -0500.
	<26211.1106080164@brightstareng.com> 
Message-ID: <434.1106081078@brightstareng.com>

it seems that in between the time i a) read the archives, b) found
the bug, and c) subscribed to the list, that david found the problem
independently.  nice to see there's an active development effort
going on!  :-) 

paul

i wrote:
 >  > I'm getting "bad buf_getbyte" errors (and session closing) when
 >  > connecting from Solaris SSH to dropbearmulti
 > 
 > i got this too, using a java ssh client.  if your problem is the
 > same as mine, it's because of an apparent edit error in [what
 > used to be sessionpty(), but what is now] get_termmodes(), in
 > svr-chansession.c.
 > 
 > i believe there's a missing "return" at line 441:
 > 
 >         if (len == 0) {
 >                 TRACE(("leave get_termmodes: empty terminal modes string"))
 >  missing -->    return;
 >         }       
 > 
 > 
 > 
 > this begs a question for me -- how much upheaval was there in the
 > 0.44 release?  i'm planning on using dropbear in an application
 > that doesn't need client functionality.  should i stick with 0.43
 > for this use?
 > 

=---------------------
 paul fox, pgf@brightstareng.com

From erik at hovland.org  Wed Jan 19 06:46:14 2005
From: erik at hovland.org (Erik Hovland)
Date: Wed Jan 19 06:46:48 2005
Subject: bad buf_getbyte patch
In-Reply-To: <41ED6C4A.4020003@aogsquid.ucsd.edu>
References: <41ED6C4A.4020003@aogsquid.ucsd.edu>
Message-ID: <20050118224614.GC3437@mage.jpl.nasa.gov>

I am sure everyone gets the idea. But I wanted to have a patch in the
mail archive which was appliable straight away.

E

On Tue, Jan 18, 2005 at 12:06:34PM -0800, David Horwitt wrote:
> I created a workaround/fix for my bad buf_getbyte problem:
> 
> *** svr-chansession.c   2005-01-11 13:14:54.000000000 -0800
> --- svr-chansession.c.orig      2005-01-03 01:24:04.000000000 -0800
> ***************
> *** 439,445 ****
> 
>         if (len == 0) {
>                 TRACE(("leave get_termmodes: empty terminal modes string"))
> -               return;
>         }
> 
>         while (((opcode = buf_getbyte(ses.payload)) != 0x00) && opcode <= 
>         159) {
> --- 439,444 ----
> 
> This seems to work OK w/out ill effects; the TRACE message implies that the 
> return that I added may have
> been intended all along.
> 
> Cheers,
> David Horwitt
> 
> 

-- 
Erik Hovland
mail: erik AT hovland DOT org
web: http://hovland.org/
PGP/GPG public key available on request
-------------- next part --------------
--- svr-chansession.c.orig	2005-01-18 14:43:11.548605000 -0800
+++ svr-chansession.c	2005-01-18 14:43:46.397009000 -0800
@@ -439,6 +439,7 @@
 
 	if (len == 0) {
 		TRACE(("leave get_termmodes: empty terminal modes string"))
+		return;
 	}
 
 	while (((opcode = buf_getbyte(ses.payload)) != 0x00) && opcode <= 159) {
From lupsyn at mojodo.it  Wed Jan 19 09:18:00 2005
From: lupsyn at mojodo.it (Enrico lupsyn Del Zotto)
Date: Wed Jan 19 09:18:29 2005
Subject: Problem with login without password
In-Reply-To: <20050118172032.GB444829@morwong.ucc.gu.uwa.edu.au>
References: <E894D39C-68E2-11D9-809A-000A95C0B12C@mojodo.it>
	<41ECBD38.2050309@freesco.info>
	<371C7D4E-6944-11D9-B606-000A95C0B12C@mojodo.it>
	<20050118172032.GB444829@morwong.ucc.gu.uwa.edu.au>
Message-ID: <F5E7CF2E-69B7-11D9-A16C-000A95C0B12C@mojodo.it>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The ssh client works i do this :

client : dropbearkey -t rsa -f identity
client : dropbearkey -f identity -y >> identity.pub
server : cat identity.pub  >>~/.ssh/authorized_keys

now if i do ssh -i identity user@server
the client log without pwd in the  server.
But the scp does't work i do this thing :

~ $ scp -i identity file_test user@server:
scp started... please wait...
Failed loading keyfile '-l'
/usr/bin/dbclient: exited: Error resolving: Name or service not known
lost connection
~ $

Il giorno 18/gen/05, alle 18:20, Matt Johnston ha scritto:

> On Tue, Jan 18, 2005 at 12:29:28PM +0100, Enrico lupsyn Del Zotto 
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> i try ti do it with ssh-keygen in my linux but  when i try to pass the
>> generate file drop bear ssh client says that the string is too long or
>> can't load the key...
>
> Could you paste the commands you're trying and the output it
> gives?
>
> Matt
>
>
>
>
Enrico "lupsyn" Del Zotto

Home page     http://hell.homelinux.com
Co-founder of http://www.mojodo.it
Icq 18119699
Msn lupsyn@mojodo.it
Aol-ichat lupsyn
irc lupsyn@irc.net #mojodo,#linux-it

Public pgp key available here
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2B2CAEAA


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB7bVMZOGtEyssrqoRAkhuAJ0fW6tVZDU+TuA+5lwpGBlUcgybwwCggV1q
FgkCnHgVsqkUjLrvSnTBS9o=
=lEKI
-----END PGP SIGNATURE-----


From matt at ucc.asn.au  Wed Jan 19 10:10:37 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed Jan 19 10:10:43 2005
Subject: bad buf_getbyte patch
In-Reply-To: <41ED6C4A.4020003@aogsquid.ucsd.edu>
References: <41ED6C4A.4020003@aogsquid.ucsd.edu>
Message-ID: <20050119021037.GC444829@morwong.ucc.gu.uwa.edu.au>

On Tue, Jan 18, 2005 at 12:06:34PM -0800, David Horwitt wrote:
> I created a workaround/fix for my bad buf_getbyte problem:
> 
> *** svr-chansession.c   2005-01-11 13:14:54.000000000 -0800
> --- svr-chansession.c.orig      2005-01-03 01:24:04.000000000 -0800
> ***************
> *** 439,445 ****
> 
>         if (len == 0) {
>                 TRACE(("leave get_termmodes: empty terminal modes string"))
> -               return;
>         }
> 
>         while (((opcode = buf_getbyte(ses.payload)) != 0x00) && opcode <= 
>         159) {
> --- 439,444 ----
> 
> This seems to work OK w/out ill effects; the TRACE message implies that the 
> return that I added may have
> been intended all along.

Yes, I think that probably was my intent, sorry. That patch
looks fine right to me.

Matt
From matt at ucc.asn.au  Wed Jan 19 10:13:19 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed Jan 19 10:13:24 2005
Subject: bad buf_getbyte patch
In-Reply-To: <20050119021037.GC444829@morwong.ucc.gu.uwa.edu.au>
References: <41ED6C4A.4020003@aogsquid.ucsd.edu>
	<20050119021037.GC444829@morwong.ucc.gu.uwa.edu.au>
Message-ID: <20050119021319.GD444829@morwong.ucc.gu.uwa.edu.au>

On Wed, Jan 19, 2005 at 10:10:37AM +0800, Matt Johnston wrote:
> On Tue, Jan 18, 2005 at 12:06:34PM -0800, David Horwitt wrote:
> > I created a workaround/fix for my bad buf_getbyte problem:
> > 
> > *** svr-chansession.c   2005-01-11 13:14:54.000000000 -0800
> > --- svr-chansession.c.orig      2005-01-03 01:24:04.000000000 -0800
> > ***************
> > *** 439,445 ****
> > 
> >         if (len == 0) {
> >                 TRACE(("leave get_termmodes: empty terminal modes string"))
> > -               return;
> >         }
> > 
> >         while (((opcode = buf_getbyte(ses.payload)) != 0x00) && opcode <= 
> >         159) {
> > --- 439,444 ----
> > 
> > This seems to work OK w/out ill effects; the TRACE message implies that the 
> > return that I added may have
> > been intended all along.
> 
> Yes, I think that probably was my intent, sorry. That patch
> looks fine right to me.

Well, re-reading it actually should be an added 'return;',
not removed - I guess the diff was done in the wrong
direction? 

Matt
From matt at ucc.asn.au  Wed Jan 19 23:48:16 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed Jan 19 23:48:27 2005
Subject: bad buf_getbyte
In-Reply-To: <26211.1106080164@brightstareng.com>
References: <26211.1106080164@brightstareng.com>
Message-ID: <20050119154816.GF444829@morwong.ucc.gu.uwa.edu.au>

On Tue, Jan 18, 2005 at 03:29:24PM -0500, Paul Fox wrote:

> this begs a question for me -- how much upheaval was there in the
> 0.44 release?  i'm planning on using dropbear in an application
> that doesn't need client functionality.  should i stick with 0.43
> for this use?

Release 0.44 did have a fair amount of change, so 0.43 might
be a bit more reliable - the majority of code in it has had
more testing from more people.

Matt
From matt at ucc.asn.au  Thu Jan 20 01:06:41 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu Jan 20 01:06:46 2005
Subject: Problem with login without password
In-Reply-To: <F5E7CF2E-69B7-11D9-A16C-000A95C0B12C@mojodo.it>
References: <E894D39C-68E2-11D9-809A-000A95C0B12C@mojodo.it>
	<41ECBD38.2050309@freesco.info>
	<371C7D4E-6944-11D9-B606-000A95C0B12C@mojodo.it>
	<20050118172032.GB444829@morwong.ucc.gu.uwa.edu.au>
	<F5E7CF2E-69B7-11D9-A16C-000A95C0B12C@mojodo.it>
Message-ID: <20050119170641.GA506566@morwong.ucc.gu.uwa.edu.au>

On Wed, Jan 19, 2005 at 02:18:00AM +0100, Enrico lupsyn Del Zotto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> The ssh client works i do this :
> 
> client : dropbearkey -t rsa -f identity
> client : dropbearkey -f identity -y >> identity.pub
> server : cat identity.pub  >>~/.ssh/authorized_keys
> 
> now if i do ssh -i identity user@server
> the client log without pwd in the  server.
> But the scp does't work i do this thing :
> 
> ~ $ scp -i identity file_test user@server:
> scp started... please wait...
> Failed loading keyfile '-l'
> /usr/bin/dbclient: exited: Error resolving: Name or service not known
> lost connection
> ~ $

This looks like something I thought was fixed in 0.44test3
(dbclient couldn't handle arguments like -l without a space
before the username). What version are you using?

Matt
From lupsyn at mojodo.it  Fri Jan 21 22:35:26 2005
From: lupsyn at mojodo.it (Enrico lupsyn Del Zotto)
Date: Sat Jan 22 00:34:45 2005
Subject: Problem with login without password
In-Reply-To: <20050119170641.GA506566@morwong.ucc.gu.uwa.edu.au>
References: <E894D39C-68E2-11D9-809A-000A95C0B12C@mojodo.it>
	<41ECBD38.2050309@freesco.info>
	<371C7D4E-6944-11D9-B606-000A95C0B12C@mojodo.it>
	<20050118172032.GB444829@morwong.ucc.gu.uwa.edu.au>
	<F5E7CF2E-69B7-11D9-A16C-000A95C0B12C@mojodo.it>
	<20050119170641.GA506566@morwong.ucc.gu.uwa.edu.au>
Message-ID: <B0DA665A-6BB9-11D9-80FF-000A95C0B12C@mojodo.it>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The version is  Dropbear client v0.44test4

Now, how can i resolve this thing ?
Thx so much

Enrico
Il giorno 19/gen/05, alle 18:06, Matt Johnston ha scritto:

> On Wed, Jan 19, 2005 at 02:18:00AM +0100, Enrico lupsyn Del Zotto 
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> The ssh client works i do this :
>>
>> client : dropbearkey -t rsa -f identity
>> client : dropbearkey -f identity -y >> identity.pub
>> server : cat identity.pub  >>~/.ssh/authorized_keys
>>
>> now if i do ssh -i identity user@server
>> the client log without pwd in the  server.
>> But the scp does't work i do this thing :
>>
>> ~ $ scp -i identity file_test user@server:
>> scp started... please wait...
>> Failed loading keyfile '-l'
>> /usr/bin/dbclient: exited: Error resolving: Name or service not known
>> lost connection
>> ~ $
>
> This looks like something I thought was fixed in 0.44test3
> (dbclient couldn't handle arguments like -l without a space
> before the username). What version are you using?
>
> Matt
>
>
>
>
Enrico "lupsyn" Del Zotto

Home page     http://hell.homelinux.com
Co-founder of http://www.mojodo.it
Icq 18119699
Msn lupsyn@mojodo.it
Aol-ichat lupsyn
irc lupsyn@irc.net #mojodo,#linux-it

Public pgp key available here
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2B2CAEAA


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB8RMwZOGtEyssrqoRAr2yAJ9HG5s/+ODzdwk9GSEiw7kwBauyFACfXhih
s83eJTY5IJQlgcc1rUUVRWo=
=YLZq
-----END PGP SIGNATURE-----


From lists at wiesinger.com  Sun Jan 23 01:18:22 2005
From: lists at wiesinger.com (Gerhard Wiesinger)
Date: Sun Jan 23 01:18:39 2005
Subject: Agent forwarding support ...
Message-ID: <Pine.LNX.4.61.0501221816420.10018@bbs.intern>

Hello Matt!

Dropbear is a real cool ssh server & client. The only thing i'm missing is 
ssh agent forwarding. I saw in some files that it is planned, but when?

Thank you for the answer.

Ciao,
Gerhard

From matt at ucc.asn.au  Mon Jan 24 19:41:09 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon Jan 24 19:41:28 2005
Subject: Agent forwarding support ...
In-Reply-To: <Pine.LNX.4.61.0501221816420.10018@bbs.intern>
References: <Pine.LNX.4.61.0501221816420.10018@bbs.intern>
Message-ID: <20050124114109.GA213071@morwong.ucc.gu.uwa.edu.au>

On Sat, Jan 22, 2005 at 06:18:22PM +0100, Gerhard Wiesinger wrote:
> Hello Matt!
> 
> Dropbear is a real cool ssh server & client. The only thing i'm missing is 
> ssh agent forwarding. I saw in some files that it is planned, but when?

Agent forwarding is reasonably high on my list of desired
additions, though I probably won't have time to add support
until late Feb at the earliest. I'm undecided how useful a
standalone ssh-agent for Dropbear would be, or whether
simply giving dbclient support for using an OpenSSH agent
connection would suffice. Does anyone have opinions either
way?

(I assume you're talking about the client, since server
support should already work). 

Matt
From lists at wiesinger.com  Mon Jan 24 20:21:52 2005
From: lists at wiesinger.com (Gerhard Wiesinger)
Date: Mon Jan 24 20:22:32 2005
Subject: Agent forwarding support ...
In-Reply-To: <20050124114109.GA213071@morwong.ucc.gu.uwa.edu.au>
References: <Pine.LNX.4.61.0501221816420.10018@bbs.intern>
	<20050124114109.GA213071@morwong.ucc.gu.uwa.edu.au>
Message-ID: <Pine.LNX.4.61.0501241311420.22691@bbs.intern>

On Mon, 24 Jan 2005, Matt Johnston wrote:

> On Sat, Jan 22, 2005 at 06:18:22PM +0100, Gerhard Wiesinger wrote:
>> Hello Matt!
>>
>> Dropbear is a real cool ssh server & client. The only thing i'm missing is
>> ssh agent forwarding. I saw in some files that it is planned, but when?
>
> Agent forwarding is reasonably high on my list of desired
> additions, though I probably won't have time to add support
> until late Feb at the earliest. I'm undecided how useful a
> standalone ssh-agent for Dropbear would be, or whether
> simply giving dbclient support for using an OpenSSH agent
> connection would suffice. Does anyone have opinions either
> way?
>
> (I assume you're talking about the client, since server
> support should already work).
>

I don't need the agent forwarding as ssh-agent, but it should forward 
requests when you do furhter ssh requests:

Example:
root@client has ssh-agent running (e.g. openssh)
1.) root@client: ssh -l root server1
2.) dropbear server & client running: root@server1: ssh -l root server2
3.) dropbear server & client running: root@server2: ssh -l root server3

In the case 2 and 3 it should do agent forwarding, so that all logons can 
be done without password authentication.

It should also be able to do the following (execute commands e.g. ssh 
sessions):
ssh -l root server1 'ssh -l root server2 "ssh -l root server3"'
(Maybe also -T is necessary).

Thank you for the answer.

Ciao,
Gerhard

From nusquam.esse at virgin.net  Tue Jan 25 08:17:54 2005
From: nusquam.esse at virgin.net (Brian Gibbins)
Date: Tue Jan 25 14:33:43 2005
Subject: need help with key generation
In-Reply-To: 200409292022.38266.linux@shadypond.com
Message-ID: <1106612274.7918.5.camel@zenith.local>

Hi Matt,

Sorry to disturb you, I know you must be a busy man. I'm trying to use
password log-on from my zaurus to my desktop using dropbear but keep
getting the message:

 exited: No auth methods could be used

I've seen your thread about key generation and can't get that to work
either, I'm not sure what I'm doing wrong. However I would still prefer
to use a password login. The strange thing is is that I can ssh from my
desktop to the zaurus no problem. Is there an Auth module I need to
install or how do I turn on debug mode (mentioned in the thread) to try
and fix the problem.

Thanks for your time.

Brian.


From matt at ucc.asn.au  Tue Jan 25 17:20:25 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue Jan 25 17:20:36 2005
Subject: need help with key generation
In-Reply-To: <1106612274.7918.5.camel@zenith.local>
References: <1106612274.7918.5.camel@zenith.local>
Message-ID: <20050125092025.GE213071@morwong.ucc.gu.uwa.edu.au>

On Tue, Jan 25, 2005 at 12:17:54AM +0000, Brian Gibbins wrote:
> Hi Matt,
> 
> Sorry to disturb you, I know you must be a busy man. I'm trying to use
> password log-on from my zaurus to my desktop using dropbear but keep
> getting the message:
> 
>  exited: No auth methods could be used
> 
> I've seen your thread about key generation and can't get that to work
> either, I'm not sure what I'm doing wrong. However I would still prefer
> to use a password login. The strange thing is is that I can ssh from my
> desktop to the zaurus no problem. Is there an Auth module I need to
> install or how do I turn on debug mode (mentioned in the thread) to try
> and fix the problem.

Could you send the output of "ssh -vvv localhost" on the
desktop (using the OpenSSH client) so that I can see what
auth methods the server is allowing? I'm wondering if the
server might only be allowing keyboard-interactive (not
plain password) auth?

Matt
From gavinux at yahoo.com  Tue Jan 25 21:55:55 2005
From: gavinux at yahoo.com (Gavinux)
Date: Tue Jan 25 21:56:16 2005
Subject: Can NOT connect to dropbear server after boot up.
Message-ID: <20050125135555.41944.qmail@web50309.mail.yahoo.com>

ssh client can NOT get connected if no any keypress on
the keyboard, which hooked on the ssh server, after
system boot up. There is no any prompt on the client
side.
Any way to let me get connected without any keypress?
My system doesn't have any user input interface.


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 

From matt at ucc.asn.au  Tue Jan 25 22:19:31 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed Jan 26 15:35:02 2005
Subject: Can NOT connect to dropbear server after boot up.
In-Reply-To: <20050125135555.41944.qmail@web50309.mail.yahoo.com>
References: <20050125135555.41944.qmail@web50309.mail.yahoo.com>
Message-ID: <20050125141931.GH213071@morwong.ucc.gu.uwa.edu.au>

On Tue, Jan 25, 2005 at 05:55:55AM -0800, Gavinux wrote:
> ssh client can NOT get connected if no any keypress on
> the keyboard, which hooked on the ssh server, after
> system boot up. There is no any prompt on the client
> side.
> Any way to let me get connected without any keypress?
> My system doesn't have any user input interface.

This sounds like the same issue with /dev/random blocking -
the comments in
http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2005q1/000151.html
apply.

Matt
From poobah at westmont.edu  Wed Jan 26 09:27:52 2005
From: poobah at westmont.edu (John Rodkey)
Date: Wed Jan 26 15:50:01 2005
Subject: ssh authentication method problem WORK-AROUND
Message-ID: <41F6F218.3050806@westmont.edu>

Reflashed 0.8.0 on an ipaq 3870, have installed the fixes mentioned
on the ReleaseNotes page (except the orinoco fix).
inserted orinoco wlan card into pcmcia sleeve, and it works, although
there are timeouts.

I want to ssh from the ipaq into my desktop, a SuSE 9.2 Professional
box, so I do
ssh rodkey@shuttle2

I get the following:

ssh: connection to rodkey@shuttle2:22 exited: No auth methods could be used.

I then ssh to an old RH 7.2 machine, and have no problems.
I note that ssh under SuSE is configured to require have tunneled
password=no.
I turn that option off in /etc/ssh/sshd_config on the desktop, restart
sshd, and it works.


(this might be helpful re the question found at 
http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2004q3/000107.html


From mroper at westcoastdhb.org.nz  Fri Jan 28 16:48:05 2005
From: mroper at westcoastdhb.org.nz (Miles Roper)
Date: Fri Jan 28 16:48:25 2005
Subject: dropbear glibc 2.1.3 compile error
Message-ID: <681F01116A860B46874E634854F4DE620E70FD@coastapps.westcoastdhb.org.nz>


Hi,

I get the below errors when compiling with gcc 2.95.3 and glibc 2.1.3.

gcc -I. -I./libtomcrypt -B//lib -Wl,-rpath-link,//lib -Os -mcpu=i586
-march=i386 -DDROPBEAR_SERVER -DDROPBEAR_CLIENT   -c -o dbutil.o dbutil.c
dbutil.c: In function `getaddrstring':
dbutil.c:362: structure has no member named `ss_family'
dbutil.c:366: structure has no member named `ss_family'
dbutil.c: In function `getaddrhostname':
dbutil.c:404: structure has no member named `ss_family'
dbutil.c:408: structure has no member named `ss_family'
gcc: file path prefix `//lib' never used
make: *** [dbutil.o] Error 1

I done a seach using google and found a similar problem.  Can we get this
fixed in dropbear?

Thanks

Miles


| ftpd.c:1093: structure has no member named `ss_family'

This message is because the Linux sockaddr_storage struct member is called
__ss_family not ss_family, if using configure add "#define HAVE__SS_FAMILY"
to the generated src/config.h (before the Socket macros), then run make.
You could also try using build, edit config.h.noac, change "#undef INET6"
to "#define INET6" followed by ./build lnx should work.

==================================================
Attention:
The information contained in this message and/or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material.  Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by person or entities other than the intended recipient
is prohibited.  If you receive this in error, please contact the sender and delete the material from your system and destroy any copies.
===================================================

From matt at ucc.asn.au  Sun Jan 30 21:21:18 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Sun Jan 30 21:21:28 2005
Subject: dropbear glibc 2.1.3 compile error
In-Reply-To: <681F01116A860B46874E634854F4DE620E70FD@coastapps.westcoastdhb.org.nz>
References: <681F01116A860B46874E634854F4DE620E70FD@coastapps.westcoastdhb.org.nz>
Message-ID: <20050130132118.GA521767@morwong.ucc.gu.uwa.edu.au>

On Fri, Jan 28, 2005 at 09:48:05PM +1300, Miles Roper wrote:
> 
> Hi,
> 
> I get the below errors when compiling with gcc 2.95.3 and glibc 2.1.3.
> 
> gcc -I. -I./libtomcrypt -B//lib -Wl,-rpath-link,//lib -Os -mcpu=i586
> -march=i386 -DDROPBEAR_SERVER -DDROPBEAR_CLIENT   -c -o dbutil.o dbutil.c
> dbutil.c: In function `getaddrstring':
> dbutil.c:362: structure has no member named `ss_family'
> dbutil.c:366: structure has no member named `ss_family'
> dbutil.c: In function `getaddrhostname':
> dbutil.c:404: structure has no member named `ss_family'
> dbutil.c:408: structure has no member named `ss_family'
> gcc: file path prefix `//lib' never used
> make: *** [dbutil.o] Error 1
> 
> I done a seach using google and found a similar problem.  Can we get this
> fixed in dropbear?

I'll take a look at getting a fix in for the next release.

I guess for the moment a "typedef __ss_family ss_family"
would be a hacky workaround in includes.h?

Alternatively, if you're just targetting ipv4 on linux,
removing the whole if/else block mentioning ss_family should
be safe AFAIK.

Matt

> 
> Thanks
> 
> Miles
> 
> 
> | ftpd.c:1093: structure has no member named `ss_family'
> 
> This message is because the Linux sockaddr_storage struct member is called
> __ss_family not ss_family, if using configure add "#define HAVE__SS_FAMILY"
> to the generated src/config.h (before the Socket macros), then run make.
> You could also try using build, edit config.h.noac, change "#undef INET6"
> to "#define INET6" followed by ./build lnx should work.
> 
> ==================================================
> Attention:
> The information contained in this message and/or attachments is intended
> only for the person or entity to which it is addressed and may contain
> confidential and/or privileged material.  Any review, retransmission,
> dissemination or other use of, or taking of any action in reliance upon,
> this information by person or entities other than the intended recipient
> is prohibited.  If you receive this in error, please contact the sender and delete the material from your system and destroy any copies.
> ===================================================
From mroper at westcoastdhb.org.nz  Mon Jan 31 12:36:12 2005
From: mroper at westcoastdhb.org.nz (Miles Roper)
Date: Mon Jan 31 12:36:46 2005
Subject: dropbear glibc 2.1.3 compile error
Message-ID: <681F01116A860B46874E634854F4DE620E7116@coastapps.westcoastdhb.org.nz>


I don't mind hacky work arounds for a short term solution :o)  used a few
myself ;o) thanks for the fix :o)

-----Original Message-----
From: Matt Johnston [mailto:matt@ucc.asn.au] 
Sent: Monday, 31 January 2005 02:21 a.m.
To: Miles Roper
Cc: 'dropbear@ucc.asn.au'; Thinstation-Developer
(thinstation-developer@lists.sourceforge.net)
Subject: Re: dropbear glibc 2.1.3 compile error

On Fri, Jan 28, 2005 at 09:48:05PM +1300, Miles Roper wrote:
> 
> Hi,
> 
> I get the below errors when compiling with gcc 2.95.3 and glibc 2.1.3.
> 
> gcc -I. -I./libtomcrypt -B//lib -Wl,-rpath-link,//lib -Os -mcpu=i586
> -march=i386 -DDROPBEAR_SERVER -DDROPBEAR_CLIENT   -c -o dbutil.o dbutil.c
> dbutil.c: In function `getaddrstring':
> dbutil.c:362: structure has no member named `ss_family'
> dbutil.c:366: structure has no member named `ss_family'
> dbutil.c: In function `getaddrhostname':
> dbutil.c:404: structure has no member named `ss_family'
> dbutil.c:408: structure has no member named `ss_family'
> gcc: file path prefix `//lib' never used
> make: *** [dbutil.o] Error 1
> 
> I done a seach using google and found a similar problem.  Can we get 
> this fixed in dropbear?

I'll take a look at getting a fix in for the next release.

I guess for the moment a "typedef __ss_family ss_family"
would be a hacky workaround in includes.h?

Alternatively, if you're just targetting ipv4 on linux, removing the whole
if/else block mentioning ss_family should be safe AFAIK.

Matt

> 
> Thanks
> 
> Miles
> 
> 
> | ftpd.c:1093: structure has no member named `ss_family'
> 
> This message is because the Linux sockaddr_storage struct member is 
> called __ss_family not ss_family, if using configure add "#define
HAVE__SS_FAMILY"
> to the generated src/config.h (before the Socket macros), then run make.
> You could also try using build, edit config.h.noac, change "#undef INET6"
> to "#define INET6" followed by ./build lnx should work.
> 
> ==================================================
> Attention:
> The information contained in this message and/or attachments is 
> intended only for the person or entity to which it is addressed and 
> may contain confidential and/or privileged material.  Any review, 
> retransmission, dissemination or other use of, or taking of any action 
> in reliance upon, this information by person or entities other than 
> the intended recipient is prohibited.  If you receive this in error,
please contact the sender and delete the material from your system and
destroy any copies.
> ===================================================

==================================================
Attention:
The information contained in this message and/or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material.  Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by person or entities other than the intended recipient
is prohibited.  If you receive this in error, please contact the sender and delete the material from your system and destroy any copies.
===================================================

From mroper at westcoastdhb.org.nz  Mon Jan 31 12:43:05 2005
From: mroper at westcoastdhb.org.nz (Miles Roper)
Date: Mon Jan 31 12:43:29 2005
Subject: dropbear glibc 2.1.3 compile error
Message-ID: <681F01116A860B46874E634854F4DE620E7117@coastapps.westcoastdhb.org.nz>


ok, didn't work,

added this down the bottom of includes.h

typedef __ss_family ss_family;

got the below errors.  probably something simple, I'm not really that
conversant with C, so please be gentle ;o)

In file included from debug.h:28,
                 from includes.h:30,
                 from dbutil.c:51:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from compat.h:28,
                 from includes.h:116,
                 from dbutil.c:51:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from fake-rfc2553.h:45,
                 from includes.h:117,
                 from dbutil.c:51:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from dbutil.c:51:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from dbutil.h:29,
                 from dbutil.c:52:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from buffer.h:29,
                 from dbutil.h:30,
                 from dbutil.c:52:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from session.h:28,
                 from dbutil.c:54:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from dss.h:28,
                 from signkey.h:29,
                 from session.h:31,
                 from dbutil.c:54:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from rsa.h:28,
                 from signkey.h:30,
                 from session.h:31,
                 from dbutil.c:54:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from kex.h:28,
                 from session.h:32,
                 from dbutil.c:54:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from algo.h:29,
                 from kex.h:29,
                 from session.h:32,
                 from dbutil.c:54:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from auth.h:28,
                 from session.h:33,
                 from dbutil.c:54:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from channel.h:28,
                 from session.h:34,
                 from dbutil.c:54:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from packet.h:29,
                 from session.h:37,
                 from dbutil.c:54:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from loginrec.h:32,
                 from chansession.h:28,
                 from session.h:39,
                 from dbutil.c:54:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
In file included from atomicio.h:31,
                 from dbutil.c:55:
includes.h:141: parse error before `ss_family'
includes.h:141: warning: data definition has no type or storage class
dbutil.c: In function `getaddrstring':
dbutil.c:362: structure has no member named `ss_family'
dbutil.c:366: structure has no member named `ss_family'
dbutil.c: In function `getaddrhostname':
dbutil.c:404: structure has no member named `ss_family'
dbutil.c:408: structure has no member named `ss_family'
gcc: file path prefix `//lib' never used
make: *** [dbutil.o] Error 1 

-----Original Message-----
From: Matt Johnston [mailto:matt@ucc.asn.au] 
Sent: Monday, 31 January 2005 02:21 a.m.
To: Miles Roper
Cc: 'dropbear@ucc.asn.au'; Thinstation-Developer
(thinstation-developer@lists.sourceforge.net)
Subject: Re: dropbear glibc 2.1.3 compile error

On Fri, Jan 28, 2005 at 09:48:05PM +1300, Miles Roper wrote:
> 
> Hi,
> 
> I get the below errors when compiling with gcc 2.95.3 and glibc 2.1.3.
> 
> gcc -I. -I./libtomcrypt -B//lib -Wl,-rpath-link,//lib -Os -mcpu=i586
> -march=i386 -DDROPBEAR_SERVER -DDROPBEAR_CLIENT   -c -o dbutil.o dbutil.c
> dbutil.c: In function `getaddrstring':
> dbutil.c:362: structure has no member named `ss_family'
> dbutil.c:366: structure has no member named `ss_family'
> dbutil.c: In function `getaddrhostname':
> dbutil.c:404: structure has no member named `ss_family'
> dbutil.c:408: structure has no member named `ss_family'
> gcc: file path prefix `//lib' never used
> make: *** [dbutil.o] Error 1
> 
> I done a seach using google and found a similar problem.  Can we get 
> this fixed in dropbear?

I'll take a look at getting a fix in for the next release.

I guess for the moment a "typedef __ss_family ss_family"
would be a hacky workaround in includes.h?

Alternatively, if you're just targetting ipv4 on linux, removing the whole
if/else block mentioning ss_family should be safe AFAIK.

Matt

> 
> Thanks
> 
> Miles
> 
> 
> | ftpd.c:1093: structure has no member named `ss_family'
> 
> This message is because the Linux sockaddr_storage struct member is 
> called __ss_family not ss_family, if using configure add "#define
HAVE__SS_FAMILY"
> to the generated src/config.h (before the Socket macros), then run make.
> You could also try using build, edit config.h.noac, change "#undef INET6"
> to "#define INET6" followed by ./build lnx should work.
> 
> ==================================================
> Attention:
> The information contained in this message and/or attachments is 
> intended only for the person or entity to which it is addressed and 
> may contain confidential and/or privileged material.  Any review, 
> retransmission, dissemination or other use of, or taking of any action 
> in reliance upon, this information by person or entities other than 
> the intended recipient is prohibited.  If you receive this in error,
please contact the sender and delete the material from your system and
destroy any copies.
> ===================================================

==================================================
Attention:
The information contained in this message and/or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material.  Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by person or entities other than the intended recipient
is prohibited.  If you receive this in error, please contact the sender and delete the material from your system and destroy any copies.
===================================================

From matt at ucc.asn.au  Mon Jan 31 13:02:44 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon Jan 31 13:02:55 2005
Subject: dropbear glibc 2.1.3 compile error
In-Reply-To: <681F01116A860B46874E634854F4DE620E7117@coastapps.westcoastdhb.org.nz>
References: <681F01116A860B46874E634854F4DE620E7117@coastapps.westcoastdhb.org.nz>
Message-ID: <20050131050244.GE521767@morwong.ucc.gu.uwa.edu.au>

On Mon, Jan 31, 2005 at 05:43:05PM +1300, Miles Roper wrote:
> 
> ok, didn't work,
> 
> added this down the bottom of includes.h
> 
> typedef __ss_family ss_family;
> 
> got the below errors.  probably something simple, I'm not really that
> conversant with C, so please be gentle ;o)

Ah blergh. I wasn't thinking straight, was thinking it was a
type that was missing, not a struct member.

For the moment, the quickest solution for Linux is probably
to just remove the two blocks in dbutil.c of:

    /* Some platforms such as Solaris 8 require that len is the length
     * of the specific structure. */
    if (addr->ss_family == AF_INET) {
        len = sizeof(struct sockaddr_in);
    }
#ifdef AF_INET6
    if (addr->ss_family == AF_INET6) {
        len = sizeof(struct sockaddr_in6);
    }
#endif

These are the only places where ss_family is used, and that code is only
required on Solaris or Irix (AFAIK).

Matt
From matt at ucc.asn.au  Tue Feb  1 01:44:56 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue Feb  1 01:45:00 2005
Subject: Out of contact for a few weeks
Message-ID: <20050131174456.GH521767@morwong.ucc.gu.uwa.edu.au>

Hi all.

I'll be somewhat busy over the next three weeks, so if
you've got any Dropbear questions, they'll have to wait :)
Or you can talk amongst yourselves....

Matt
From swenggsri at yahoo.com  Sat Feb  5 06:04:15 2005
From: swenggsri at yahoo.com (Sriram Chadalavada)
Date: Sat Feb  5 06:04:35 2005
Subject: openpty : no such file or directory error
In-Reply-To: <20041229051558.GG427825@morwong.ucc.gu.uwa.edu.au>
Message-ID: <20050204220416.87289.qmail@web21602.mail.yahoo.com>

Hi everyone,
   Its been a while since I continued work with
dropbear on my uClinux 2.4.24(Arcturus uCdimm -
Motorola M68VZ328) with uClibc compilation.

I now have it working as a daemon. And a SSH client
seems to connect to it(though Diffie Helman exchange
on the 33MHz uCdimm takes about 8-10 mins).

But the password is not authenticated. On turning on
-E option, I found:

[38] Nov 30 00:09:57 pty_allocate: openpty: No such
file or directory
(invoked in sshpty.c)

My relevant kernel options are:
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_DEVPTS_FS=y

and the config.h file is:

/* Have openpty() function */
#define HAVE_OPENPTY 1
/* Define to 1 if you have the <pty.h> header file. */
#define HAVE_PTY_H  1

/* Define to 1 if you have the `_getpty' function. */
#define HAVE__GETPTY 1
/* Use /dev/ptmx */
#undef USE_DEV_PTMX

Any suggestions to solve this problem would be most
welcome.

Thanks in advance,
Sriram

--- Matt Johnston <matt@ucc.asn.au> wrote:

> On Tue, Dec 28, 2004 at 05:14:10PM -0800, Sriram
> Chadalavada wrote:
> > I have cross-compiled dropbear as a MULTI and
> STATIC
> > program and use a symbolic link dropbear. The DSS
> host
> > key has been put into /etc/dropbear(appropriate
> > location) of the uCdimm filesystem.
> > The application has been compiled to execute under
> > inetd control. 
> > 
> > My problem is that when I try connecting to the
> board
> > using ssh, I get the message:
> > 
> > [root@dhcp001 uClinux-dist]# ssh
> root@129.237.125.90
> > ssh_exchange_identification: Connection closed by
> > remote host
> 
> Does your system have syslog available? If so, could
> you
> have a look at the logs and see what error message
> Dropbear
> is giving? 
> 
> If syslog isn't available, the best bet is probably
> to
> compile Dropbear to try and run standalone (not from
> inetd),
> and run it with '-F -E' flags so that logging
> information is
> written to your terminal. (I'm not entirely sure if
> this
> will work with uClibc - you might want to remove the
> "fork()" from svr-main.c).
> 
> If the logging information doesn't give any hints,
> you can
> enable DEBUG_TRACE in debug.h, which will spit out
> very
> verbose debugging information. (Note that this will
> probably
> cause problems if you run from inetd).
> 
> Let me know how it goes.
> 
> Matt
> 
> 



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 

From claudio_cl at rictec.com.br  Wed Feb  9 04:07:24 2005
From: claudio_cl at rictec.com.br (Claudio Roberto Cussuol)
Date: Wed Feb  9 04:10:02 2005
Subject: DO_HOST_LOOKUP option is ignored
Message-ID: <20052818724.875429@claudio>

I'm having problem with this error too and it's very annoyng.

I've tracked down the version 0.43 and found it's use inside the dbutils.c file 
but this portion of code doens't exist anymore. The only use of the function 
gethostbyaddr i've found in 0.44 is inside the file fake-rfc2553.c.






From schadala at ittc.ku.edu  Tue Feb 15 07:28:51 2005
From: schadala at ittc.ku.edu (schadala@ittc.ku.edu)
Date: Tue Feb 15 07:29:19 2005
Subject: Connected terminal(shell) not displayed by client
Message-ID: <34238.129.237.123.68.1108423731.squirrel@webmail.ittc.ku.edu>

Hi everyone,
  I am trying to connect to dropbear daemon on a MMU-less uClinux(2.4.24
kernel) uCdimm (Motorola MC68VZ328). It is a single user system (root
only) and I am not using devpts. Hence, I commented out chmod in
sshpty.c.

Going by the log messages, password based authentication seems to be
occuring and a terminal is allocated by the server. But, the shell is not
displayed on the client (dbclient).

When I try to type anything at the client prompt, the client is
disconnected and the following message is displayed by the server.

exit after auth (root): received data with bad infd

Please let me why this is occuring and what I need to change to get normal
shell prompt on the client.

I am attaching snapshots of the traces/printfs on both server and client.

Thanks in advance,
Sriram




From schadala at ittc.ku.edu  Tue Feb 15 07:28:51 2005
From: schadala at ittc.ku.edu (schadala@ittc.ku.edu)
Date: Tue Feb 15 07:29:42 2005
Subject: Connected terminal(shell) not displayed by client
Message-ID: <34237.129.237.123.68.1108423731.squirrel@webmail.ittc.ku.edu>

Hi everyone,
  I am trying to connect to dropbear daemon on a MMU-less uClinux(2.4.24
kernel) uCdimm (Motorola MC68VZ328). It is a single user system (root
only) and I am not using devpts. Hence, I commented out chmod in
sshpty.c.

Going by the log messages, password based authentication seems to be
occuring and a terminal is allocated by the server. But, the shell is not
displayed on the client (dbclient).

When I try to type anything at the client prompt, the client is
disconnected and the following message is displayed by the server.

exit after auth (root): received data with bad infd

Please let me why this is occuring and what I need to change to get normal
shell prompt on the client.

I am attaching snapshots of the traces/printfs on both server and client.

Thanks in advance,
Sriram

-------------- next part --------------
CE: received msg_userauth_success
TRACE: leave process_packet
TRACE: enter cli_sessionloop
TRACE: enter cli_send_chansess_request
TRACE: enter send_msg_channel_open_init()
TRACE: enter newchannel
TRACE: leave newchannel
TRACE: setnonblocking: 0
TRACE: leave setnonblocking
TRACE: leave send_msg_channel_open_init()
TRACE: enter encrypt_packet()
TRACE: encrypt_packet type is 90
TRACE: enter writemac
TRACE: leave writemac
TRACE: enter enqueue
TRACE: leave enqueue
TRACE: leave encrypt_packet()
TRACE: leave cli_send_chansess_request
TRACE: leave cli_sessionloop: cli_send_chansess_request
TRACE: infd = 0, outfd 0, errfd -1, bufused 0
TRACE: enter write_packet
TRACE: empty queue dequeing
TRACE: leave write_packet
TRACE: checkclose: infd 0, outfd 0, errfd -1, sentclosed 0, recvclosed 0
TRACE: writebuf 0 extrabuf @ extrabuf 0
TRACE: enter cli_sessionloop
TRACE: infd = 0, outfd 0, errfd -1, bufused 0
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 = 91
TRACE: enter recv_msg_channel_open_confirmation
TRACE: new chan remote 0 localho 0
TRACE: setnonblocking: 1
TRACE: leave setnonblocking
TRACE: setnonblocking: 0
TRACE: leave setnonblocking
TRACE: setnonblocking: 2
TRACE: leave setnonblocking
TRACE: enter send_chansess_pty_req
TRACE: enter put_termcodes
TRACE: leave put_termcodes
TRACE: enter encrypt_packet()
TRACE: encrypt_packet type is 98
TRACE: enter writemac
TRACE: leave writemac
TRACE: enter enqueue
TRACE: leave enqueue
TRACE: leave encrypt_packet()
TRACE: leave send_chansess_pty_req
TRACE: enter send_chansess_shell_req
TRACE: enter encrypt_packet()
TRACE: encrypt_packet type is 98
TRACE: enter writemac
TRACE: leave writemac
TRACE: enter enqueue
TRACE: leave enqueue
TRACE: leave encrypt_packet()
TRACE: leave send_chansess_shell_req
TRACE: enter cli_pty_setup
TRACE: leave cli_tty_setup
                          TRACE: leave recv_msg_channel_open_confirmation
                                                                         TRACE: leave process_packet
                                                                                                    TRACE: checkclose: infd 1, outfd 0, errfd 2, sentclosed 0, recvclosed 0
                                              TRACE: writebuf 0 extrabuf @ extrabuf 0
                                                                                      TRACE: enter cli_sessionloop
                                                                                                                  TRACE: infd = 1, outfd 0, errfd 2, bufused 0
                                 TRACE: enter write_packet
                                                          TRACE: leave write_packet
                                                                                   TRACE: checkclose: infd 1, outfd 0, errfd 2, sentclosed 0, recvclosed 0
                             TRACE: writebuf 0 extrabuf @ extrabuf 0
                                                                     TRACE: enter cli_sessionloop
                                                                                                 TRACE: infd = 1, outfd 0, errfd 2, bufused 0
                TRACE: enter write_packet
                                         TRACE: empty queue dequeing
                                                                    TRACE: leave write_packet
                                                                                             TRACE: checkclose: infd 1, outfd 0, errfd 2, sentclosed 0, recvclosed 0
                                       TRACE: writebuf 0 extrabuf @ extrabuf 0
                                                                               TRACE: enter cli_sessionloop
                                                                                                           TRACE: infd = 1, outfd 0, errfd 2, bufused 0
                          TRACE: maxlen 8000
                                            TRACE: buf pos 0 data 806b9d8
                                                                         TRACE: enter encrypt_packet()
                                                                                                      TRACE: encrypt_packet type is 94
         TRACE: enter writemac
                              TRACE: leave writemac
                                                   TRACE: enter enqueue
                                                                       TRACE: leave enqueue
                                                                                           TRACE: leave encrypt_packet()
                                                                                                                        TRACE: leave send_msg_channel_data
                             TRACE: checkclose: infd 1, outfd 0, errfd 2, sentclosed 0, recvclosed 0
                                                                                                    TRACE: writebuf 0 extrabuf @ extrabuf 0
               TRACE: enter cli_sessionloop
                                           TRACE: infd = 1, outfd 0, errfd 2, bufused 0
                                                                                       TRACE: enter write_packet
                                                                                                                TRACE: empty queue dequeing
              TRACE: leave write_packet
                                       TRACE: checkclose: infd 1, outfd 0, errfd 2, sentclosed 0, recvclosed 0
                                                                                                              TRACE: writebuf 0 extrabuf @ extrabuf 0
                         TRACE: enter cli_sessionloop
                                                     TRACE: infd = 1, outfd 0, errfd 2, bufused 0
                                                                                                 TRACE: maxlen 7999
                                                                                                                   TRACE: buf pos 0 data 806b9d8
                   TRACE: enter encrypt_packet()
                                                TRACE: encrypt_packet type is 94
                                                                                TRACE: enter writemac
                                                                                                     TRACE: leave writemac
                                                                                                                          TRACE: enter enqueue
                 TRACE: leave enqueue
                                     TRACE: leave encrypt_packet()
                                                                  TRACE: leave send_msg_channel_data
                                                                                                    TRACE: checkclose: infd 1, outfd 0, errfd 2, sentclosed 0, recvclosed 0
                                              TRACE: writebuf 0 extrabuf @ extrabuf 0
                                                                                      TRACE: enter cli_sessionloop
                                                                                                                  TRACE: infd = 1, outfd 0, errfd 2, bufused 0
                                 TRACE: enter write_packet
                                                          TRACE: empty queue dequeing
                                                                                     TRACE: leave write_packet
                                                                                                              TRACE: checkclose: infd 1, outfd 0, errfd 2, sentclosed 0, recvclosed 0
                                                        TRACE: writebuf 0 extrabuf @ extrabuf 0
                                                                                                TRACE: enter cli_sessionloop
                                                                                                                            TRACE: infd = 1, outfd 0, errfd 2, bufused 0
                                           TRACE: enter read_packet
                                                                   TRACE: enter cli_tty_cleanup
                                                                                               TRACE: leave cli_tty_cleanup
TRACE: enter session_cleanup
TRACE: enter chancleanup
TRACE: channel 0 closing
TRACE: enter removechannel
TRACE: channel index is 0
-------------- next part --------------
[40] Nov 30 00:30:00 Child connection from 129.237.123.68:34080
About to start session with client
Exchange identification completed
Initialized hashpool
Got seed data
Hashed in the seed data
Generated random seed
Key exchange started
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
process_packet: packet type = 20
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
Invoked packet handler
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
process_packet: packet type = 30
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
enter recv_msg_kexdh_init
Multi precision integer initCopied into payload of reply packetEnter send_msg_k
Initialize and generate server side DH key exchange values
Combine the values
Enter send_msg_kexdh_reply
Enter send_msg_kexdh_reply
Enter send_msg_kexdh_reply
calculate the signature
Encrypted packet
Sent send_msg_kexdh_replyenter send_msg_newkeys
SENTNEWKEYS=1
Leave send_msg_newkeys
Invoked packet handler
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
process_packet: packet type = 21
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
Invoked packet handler
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
process_packet: packet type = 5
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
Invoked packet handler
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
process_packet: packet type = 50
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
Invoked packet handler
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
process_packet: packet type = 50
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
[40] Nov 30 00:38:32 password auth succeeded for 'root' from 129.237.123.68:3400Invoked packet handler
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
process_packet: packet type = 90
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
Invoked packet handler
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
process_packet: packet type = 98
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
Invoked packet handler
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
process_packet: packet type = 98
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
Invoked packet handler
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
Read packet
process_packet: packet type = 94
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
[40] Nov 30 00:38:46 exit after auth (root): received data with bad infd
From schadala at ittc.ku.edu  Tue Feb 15 07:49:53 2005
From: schadala at ittc.ku.edu (schadala@ittc.ku.edu)
Date: Tue Feb 15 07:50:19 2005
Subject: Connected terminal(shell) not displayed by client
In-Reply-To: <34237.129.237.123.68.1108423731.squirrel@webmail.ittc.ku.edu>
References: <34237.129.237.123.68.1108423731.squirrel@webmail.ittc.ku.edu>
Message-ID: <34279.129.237.123.68.1108424993.squirrel@webmail.ittc.ku.edu>

Snapshot of dropbear server with the debug traces.
-------------- next part --------------
TRACE: enter buf_get_dss_pub_key
TRACE: leave buf_get_dss_pub_key: success
TRACE: leave buf_get_priv_key
Returning value for the key reading operation = 0Read dss key
TRACE: leave loadhostkeys
Load hostkeys
Setting up common parameters
[45] Nov 30 01:26:16 Running in background
Created PID file
TRACE: listensockets: 1 to try
                                                                                
TRACE: listening on '10000'
TRACE: enter dropbear_listen
TRACE: dropbear_listen: not local loopback
TRACE: bind(10000) failed
TRACE: leave dropbear_listen: success, 1 socks bound
Setting up listening sockets
[48] Nov 30 01:27:21 Child connection from 129.237.123.68:34242
About to start session with client
TRACE: enter session_init
TRACE: kexinitialise()
TRACE: leave session_init
TRACE: enter ident_readln
TRACE: leave ident_readln: return 22
TRACE: remoteident: SSH-2.0-dropbear_0.44
Exchange identification completed
Initialized hashpool
Got seed data
Hashed in the seed data
Generated random seed
TRACE: buf_put_algolist: diffie-hellman-group1-sha1
TRACE: buf_put_algolist: ssh-dss
TRACE: buf_put_algolist: 3des-cbc
TRACE: buf_put_algolist: 3des-cbc
TRACE: buf_put_algolist: hmac-sha1
TRACE: buf_put_algolist: hmac-sha1
TRACE: buf_put_algolist: none,zlib
TRACE: buf_put_algolist: none,zlib
TRACE: enter encrypt_packet()
TRACE: encrypt_packet type is 20
TRACE: enter writemac
TRACE: leave writemac
TRACE: enter enqueue
TRACE: leave enqueue
TRACE: leave encrypt_packet()
TRACE: DATAALLOWED=0
TRACE: -> KEXINIT
Key exchange started
Setting up channels which require reading/writing
'select' them
Check for timeouts
TRACE: enter write_packet
TRACE: empty queue dequeing
TRACE: leave write_packet
Wrote packet
TRACE: enter read_packet
TRACE: enter decrypt_packet
TRACE: leave decrypt_packet
TRACE: leave read_packet
Read packet
TRACE: enter process_packet
TRACE: process_packet: packet type = 20
process_packet: packet type = 20
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
TRACE: <- KEXINIT
TRACE: enter recv_msg_kexinit
TRACE: buf_match_algo: diffie-hellman-group1-sha1
TRACE: kex algo diffie-hellman-group1-sha1
TRACE: buf_match_algo: ssh-dss
TRACE: hostkey algo ssh-dss
TRACE: buf_match_algo: 3des-cbc
TRACE: c2s is  3des-cbc
TRACE: buf_match_algo: 3des-cbc
TRACE: s2c is  3des-cbc
TRACE: buf_match_algo: hmac-sha1
TRACE: buf_match_algo: hmac-sha1
TRACE: buf_match_algo: none,zlib
TRACE: buf_match_algo: none,zlib
TRACE: enc algo recv ssh-dss
TRACE: enc algo trans ssh-dss
TRACE: mac algo recv ssh-dss
TRACE: mac algo trans ssh-dss
TRACE: comp algo recv ssh-dss
TRACE: comp algo trans ssh-dss
TRACE: leave recv_msg_kexinit
Invoked packet handler
TRACE: leave process_packet
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
TRACE: enter read_packet
TRACE: enter decrypt_packet
TRACE: leave decrypt_packet
TRACE: leave read_packet
Read packet
TRACE: enter process_packet
TRACE: process_packet: packet type = 30
process_packet: packet type = 30
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
TRACE: enter recv_msg_kexdh_init
enter recv_msg_kexdh_init
TRACE: enter send_msg_kexdh_reply
Multi precision integer initCopied into payload of reply packetEnter send_msg_k
TRACE: enter send_msg_kexdh_reply
Initialize and generate server side DH key exchange values
TRACE: enter buf_put_pub_key
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
TRACE: leave buf_put_pub_key
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
Combine the values
Enter send_msg_kexdh_reply
TRACE: enter buf_put_pub_key
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
TRACE: leave buf_put_pub_key
Enter send_msg_kexdh_reply
TRACE: enter buf_putmpint
TRACE: leave buf_putmpint
Enter send_msg_kexdh_reply
TRACE: enter buf_put_dss_sign
TRACE: leave buf_put_dss_sign
calculate the signature
TRACE: enter encrypt_packet()
TRACE: encrypt_packet type is 31
TRACE: enter writemac
TRACE: leave writemac
TRACE: enter enqueue
TRACE: leave enqueue
TRACE: leave encrypt_packet()
Encrypted packet
TRACE: leave send_msg_kexdh_reply
TRACE: enter send_msg_newkeys
Sent send_msg_kexdh_replyenter send_msg_newkeys
TRACE: enter encrypt_packet()
TRACE: encrypt_packet type is 21
TRACE: enter writemac
TRACE: leave writemac
TRACE: enter enqueue
TRACE: leave enqueue
TRACE: leave encrypt_packet()
TRACE: SENTNEWKEYS=1
SENTNEWKEYS=1
TRACE: -> MSG_NEWKEYS
TRACE: leave send_msg_newkeys
Leave send_msg_newkeys
TRACE: leave recv_msg_kexdh_init
Invoked packet handler
TRACE: leave process_packet
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
TRACE: enter write_packet
TRACE: leave write_packet
Wrote packet
Read packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
TRACE: enter write_packet
TRACE: empty queue dequeing
TRACE: leave write_packet
Wrote packet
Read packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
TRACE: enter read_packet
TRACE: enter decrypt_packet
TRACE: leave decrypt_packet
TRACE: leave read_packet
Read packet
TRACE: enter process_packet
TRACE: process_packet: packet type = 21
process_packet: packet type = 21
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
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
TRACE: leave gen_new_keys
TRACE: kexinitialise()
TRACE:  -> DATAALLOWED=1
TRACE: leave recv_msg_newkeys
Invoked packet handler
TRACE: leave process_packet
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
TRACE: enter read_packet
TRACE: enter decrypt_packet
TRACE: leave decrypt_packet
TRACE: leave read_packet
Read packet
TRACE: enter process_packet
TRACE: process_packet: packet type = 5
process_packet: packet type = 5
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
TRACE: enter recv_msg_service_request
TRACE: accepting service ssh-userauth
TRACE: enter encrypt_packet()
TRACE: encrypt_packet type is 6
TRACE: enter writemac
TRACE: leave writemac
TRACE: enter enqueue
TRACE: leave enqueue
TRACE: leave encrypt_packet()
TRACE: leave recv_msg_service_request: done ssh-userauth
Invoked packet handler
TRACE: leave process_packet
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
TRACE: enter write_packet
TRACE: empty queue dequeing
TRACE: leave write_packet
Wrote packet
Read packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
TRACE: enter read_packet
TRACE: enter decrypt_packet
TRACE: leave decrypt_packet
TRACE: leave read_packet
Read packet
TRACE: enter process_packet
TRACE: process_packet: packet type = 50
process_packet: packet type = 50
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
TRACE: enter recv_msg_userauth_request
TRACE: recv_msg_userauth_request: 'none' request
TRACE: enter send_msg_userauth_failure
TRACE: enter encrypt_packet()
TRACE: encrypt_packet type is 51
TRACE: enter writemac
TRACE: leave writemac
TRACE: enter enqueue
TRACE: leave enqueue
TRACE: leave encrypt_packet()
TRACE: auth fail: methods 3, ''
TRACE: leave send_msg_userauth_failure
Invoked packet handler
TRACE: leave process_packet
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
TRACE: enter write_packet
TRACE: empty queue dequeing
TRACE: leave write_packet
Wrote packet
Read packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
TRACE: enter read_packet
TRACE: enter decrypt_packet
TRACE: leave decrypt_packet
TRACE: leave read_packet
Read packet
TRACE: enter process_packet
TRACE: process_packet: packet type = 50
process_packet: packet type = 50
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
TRACE: enter recv_msg_userauth_request
TRACE: enter checkusername
TRACE: shell is /bin/sh
TRACE: test shell is '/bin/sh'
TRACE: matching shell
TRACE: uid = 0
TRACE: leave checkusername
[48] Nov 30 01:35:59 password auth succeeded for 'root' from 129.237.123.68:3422TRACE: enter send_msg_userauth_success
TRACE: enter encrypt_packet()
TRACE: encrypt_packet type is 52
TRACE: enter writemac
TRACE: leave writemac
TRACE: enter enqueue
TRACE: leave enqueue
TRACE: leave encrypt_packet()
TRACE: leave send_msg_userauth_success
Invoked packet handler
TRACE: leave process_packet
Leave process_packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
TRACE: enter write_packet
TRACE: empty queue dequeing
TRACE: leave write_packet
Wrote packet
Read packet
Processed read data
Processing in/out data
Process pipes
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
TRACE: enter read_packet
TRACE: enter decrypt_packet
TRACE: leave decrypt_packet
TRACE: leave read_packet
Read packet
TRACE: enter process_packet
TRACE: process_packet: packet type = 90
process_packet: packet type = 90
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
TRACE: enter recv_msg_channel_open
TRACE: matched type 'session'
TRACE: enter newchannel
TRACE: leave newchannel
TRACE: enter send_msg_channel_open_confirmation
TRACE: enter encrypt_packet()
TRACE: encrypt_packet type is 91
TRACE: enter writemac
TRACE: leave writemac
TRACE: enter enqueue
TRACE: leave enqueue
TRACE: leave encrypt_packet()
TRACE: leave send_msg_channel_open_confirmation
TRACE: leave recv_msg_channel_open
Invoked packet handler
TRACE: leave process_packet
Leave process_packet
Processed read data
Processing in/out data
TRACE: checkclose: infd -2, outfd -2, errfd -1, sentclosed 0, recvclosed 0
TRACE: writebuf 0 extrabuf  extrabuf 0
Process pipes
TRACE: infd = -2, outfd -2, errfd -1, bufused 0
Setting up channels which require reading/writing
'select' them
Check for timeouts
TRACE: enter write_packet
TRACE: empty queue dequeing
TRACE: leave write_packet
Wrote packet
Read packet
Processed read data
Processing in/out data
TRACE: checkclose: infd -2, outfd -2, errfd -1, sentclosed 0, recvclosed 0
TRACE: writebuf 0 extrabuf  extrabuf 0
Process pipes
TRACE: infd = -2, outfd -2, errfd -1, bufused 0
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
TRACE: enter read_packet
TRACE: enter decrypt_packet
TRACE: leave decrypt_packet
TRACE: leave read_packet
Read packet
TRACE: enter process_packet
TRACE: process_packet: packet type = 98
process_packet: packet type = 98
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
TRACE: enter recv_msg_channel_request
TRACE: enter chansessionrequest
TRACE: type is pty-req
TRACE: enter sessionpty
TRACE: enter get_termmodes
TRACE: term mode str 241 p->l 287 p->p 46
TRACE: leave get_termmodes
TRACE: leave sessionpty
TRACE: leave chansessionrequest
TRACE: leave recv_msg_channel_request
Invoked packet handler
TRACE: leave process_packet
Leave process_packet
Processed read data
Processing in/out data
TRACE: checkclose: infd -2, outfd -2, errfd -1, sentclosed 0, recvclosed 0
TRACE: writebuf 0 extrabuf  extrabuf 0
Process pipes
TRACE: infd = -2, outfd -2, errfd -1, bufused 0
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
TRACE: enter read_packet
TRACE: enter decrypt_packet
TRACE: leave decrypt_packet
TRACE: leave read_packet
Read packet
TRACE: enter process_packet
TRACE: process_packet: packet type = 98
process_packet: packet type = 98
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
TRACE: enter recv_msg_channel_request
TRACE: enter chansessionrequest
TRACE: type is shell
TRACE: enter sessioncommand
TRACE: enter ptycommand
TRACE: leave chansessionrequest
TRACE: leave recv_msg_channel_request
Invoked packet handler
TRACE: leave process_packet
Leave process_packet
Processed read data
Processing in/out data
TRACE: checkclose: infd -2, outfd -2, errfd -1, sentclosed 0, recvclosed 0
TRACE: writebuf 0 extrabuf  extrabuf 0
Process pipes
TRACE: infd = -2, outfd -2, errfd -1, bufused 0
Setting up channels which require reading/writing
'select' them
Check for timeouts
Wrote packet
TRACE: enter read_packet
TRACE: enter decrypt_packet
TRACE: leave decrypt_packet
TRACE: leave read_packet
Read packet
TRACE: enter process_packet
TRACE: process_packet: packet type = 94
process_packet: packet type = 94
received SSH_MSG_UNIMPLEMENTED
Check if we should ignore the packet
TRACE: enter recv_msg_channel_data
[48] Nov 30 01:36:19 exit after auth (root): received data with bad infd
TRACE: enter session_cleanup
TRACE: enter chancleanup
TRACE: channel 0 closing
TRACE: enter removechannel
TRACE: channel index is 0
TRACE: leave removechannel
TRACE: leave chancleanup
TRACE: leave session_cleanup
From rich.ireland at idahotech.com  Thu Feb 17 07:18:57 2005
From: rich.ireland at idahotech.com (Rich Ireland)
Date: Thu Feb 17 07:19:15 2005
Subject: dropbear config question
Message-ID: <4213D4E1.5070600@idahotech.com>

Is there anything special to do for a uclibc built dropbear install?

Why can't I get a login prompt?

-------- Original Message --------
Subject: [uClibc] dropbear config (was: openssh - newbie configuration 
question)
Date: Wed, 16 Feb 2005 15:47:01 -0700
From: Rich Ireland <rich.ireland@idahotech.com>
Organization: Idaho Technology, Inc.
To: uclibc@uclibc.org
References: <4210E0F1.4080402@idahotech.com> 
<200502142306.55750.rob@landley.net>

Rob Landley wrote:
> 
> I'd try "dropbear".  It's a tiny ssh clone (both client and server) without 
> the dependencies of openssh (doesn't use openssl, etc) that's pretty much 
> self configuring.

Thanks for the pointer Rob.  I've made a new build with dropbear, but I
can't seem to get a good connection.  From the client side:

> $ ssh -v 10.1.1.77
> OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
> debug1: Reading configuration data /etc/ssh_config
> debug1: Connecting to 10.1.1.77 [10.1.1.77] port 22.
> debug1: Connection established.
> debug1: identity file /home/rich_ireland/.ssh/identity type -1
> debug1: identity file /home/rich_ireland/.ssh/id_rsa type -1
> debug1: identity file /home/rich_ireland/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version dropbear_0.44
> debug1: no match: dropbear_0.44
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.9p1
> debug1: SSH2_MSG_KEXINIT sent

and from the host side in /var/log/messages:
> Dec 31 17:28:06 uclibc kern.info dropbear[772]: Child connection from 10.1.3.30: 3010

but the client never times out and never gives me a login prompt.

The dropbear docs don't give any configuration options, so all I have is
the default /etc/init.d/S50dropbear script that the ucLibc creates.

Does dropbear require tinylogin like OpenSSH?
It seems like just busybox isn't enough.

-- 
Rich Ireland
Firmware Engineer - Perforce Advocate
Idaho Technology, Inc.
http://www.idahotech.com/
mailto:rich.ireland@idahotech.com



-- 
Rich Ireland
Firmware Engineer - Perforce Advocate
Idaho Technology, Inc.
http://www.idahotech.com/
mailto:rich.ireland@idahotech.com


From rich.ireland at idahotech.com  Sat Feb 19 05:09:38 2005
From: rich.ireland at idahotech.com (Rich Ireland)
Date: Sat Feb 19 05:12:12 2005
Subject: dropbear config question
In-Reply-To: <4213D4E1.5070600@idahotech.com>
References: <4213D4E1.5070600@idahotech.com>
Message-ID: <42165992.3060601@idahotech.com>

Problem solved, I needed to use /dev/urandom.

Rich Ireland wrote:
> Is there anything special to do for a uclibc built dropbear install?
> 
> Why can't I get a login prompt?


-- 
Rich Ireland
Firmware Engineer - Perforce Advocate
Idaho Technology, Inc.
http://www.idahotech.com/
mailto:rich.ireland@idahotech.com

-------------- next part --------------
An embedded message was scrubbed...
From: Rich Ireland <rich.ireland@idahotech.com>
Subject: Re: [uClibc] dropbear config
Date: Fri, 18 Feb 2005 13:48:44 -0700
Size: 2145
Url: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20050218/af4334d8/AttachedMessage.mht
From brent at mbari.org  Sun Feb 20 16:07:20 2005
From: brent at mbari.org (Brent Roman)
Date: Tue Feb 22 21:29:53 2005
Subject: scp log out session after successful completion
Message-ID: <42184538.4030108@mbari.org>

Hi,

I'm running dropbear on an embedded ARM from Technologics.
It's your v0.44 with the 2.4x linux kernel and busybox v1.0

There are only 16MB of RAM in this configuration, so small _is_ beautiful!

After a day or so of fiddling, the only remaining problem is
that when I invoke dropbear's scp interactively, it appears
to close stdin (or redirect it ot /dev/null somehow)
for the shell after completing successfully.
This causes the shell to logout.

Any ideas on what might be causing this?
Thanks in advance,

Brent


Here's a typically scp invokation for reference:

brent@ESPhost$ scp -v -i .ssh/id_rsa .irbrc bufflehead:irbrc
Executing: program /usr/bin/dbclient host bufflehead, user 
(unspecified), command scp -v -t irbrc
WARNING: Ignoring unknown argument '-x'
WARNING: Ignoring unknown argument '-oForwardAgent no'
WARNING: Ignoring unknown argument '-oClearAllForwardings yes'
WARNING: Ignoring unknown argument '-v'
Sending file modes: C0644 825 .irbrc
Sink: C0644 825 .irbrc
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$
Use "exit" to leave shell.
brent@ESPhost$ Connection to esphost closed.
brent@bufflehead:~$



-- 
  Brent Roman
  Software Engineer
  425 Clinton St., Santa Cruz,      California, 95062
  mailto:brent@mbari.org  http://www.mbari.org/~brent


From swenggsri at yahoo.com  Wed Feb 23 01:38:28 2005
From: swenggsri at yahoo.com (Sriram Chadalavada)
Date: Wed Feb 23 01:38:41 2005
Subject: Connected terminal(shell) not displayed by client
In-Reply-To: <20041229051558.GG427825@morwong.ucc.gu.uwa.edu.au>
Message-ID: <20050222173828.44850.qmail@web21601.mail.yahoo.com>

Hi all,
  Problem solved. I had to replace fork() with vfork()
in the svr-chansession.c.

Cheers,
Sriram


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 

From brentd at tlab.net  Sun Feb 27 08:38:28 2005
From: brentd at tlab.net (Brent Davidson)
Date: Sun Feb 27 08:39:24 2005
Subject: Problem with dropbear and uClibc / busybox
Message-ID: <42211684.8000508@tlab.net>

I have been working on a custom embedded system with uClibc and busybox 
and want to add dropbear for sshd functions, but I have run into a problem.

dropbear runs fine, but when I try to connect remotely or with dbclient 
admin@localhost the server proccess logs "Child connection from 
127.0.0.1" and then the whole process freezes.  I am never presented a 
login prompt.

I am compiling dropbear 0.44 with the MULTI=1 option under the pre-built 
uClibc development environment.

Thanks,
Brent Davidson


From rich.ireland at idahotech.com  Sun Feb 27 09:19:26 2005
From: rich.ireland at idahotech.com (Rich Ireland)
Date: Sun Feb 27 09:23:36 2005
Subject: Problem with dropbear and uClibc / busybox
In-Reply-To: <42211684.8000508@tlab.net>
References: <42211684.8000508@tlab.net>
Message-ID: <4221201E.7070709@idahotech.com>

Brett,

I had the same trouble not long ago.  Your system doesn't have enough 
randomness in it.  Try changing the dropbear config to use /dev/urandom 
instead of dev/random.

See this thread:
http://codepoet.org/lists/uclibc/2005-February/011151.html

Brent Davidson wrote:
> I have been working on a custom embedded system with uClibc and busybox 
> and want to add dropbear for sshd functions, but I have run into a problem.
> 
> dropbear runs fine, but when I try to connect remotely or with dbclient 
> admin@localhost the server proccess logs "Child connection from 
> 127.0.0.1" and then the whole process freezes.  I am never presented a 
> login prompt.
> 
> I am compiling dropbear 0.44 with the MULTI=1 option under the pre-built 
> uClibc development environment.

-- 
Rich Ireland
Firmware Engineer
Idaho Technology, Inc.
http://www.idahotech.com/
mailto:rich.ireland@idahotech.com


From brentd at tlab.net  Mon Feb 28 04:54:34 2005
From: brentd at tlab.net (Brent Davidson)
Date: Mon Feb 28 04:55:18 2005
Subject: Problem with dropbear and uClibc / busybox
In-Reply-To: <4221201E.7070709@idahotech.com>
References: <42211684.8000508@tlab.net> <4221201E.7070709@idahotech.com>
Message-ID: <4222338A.7040504@tlab.net>

Well, I mamanged to get the hang up problem fixed, but now I'm having 
another issue...  Once I log in, I get the following in the log:

[326] Jan 03 20:39:46 pty_allocate: openpty: No such file or directory
[326] Jan 03 20:39:46 no pty was allocated, couldn't execute

(Yes, I know the date is wrong, I haven't set that yet.)

What am I missing now?

Thanks,
-Brent

Rich Ireland wrote:

> Brett,
>
> I had the same trouble not long ago.  Your system doesn't have enough 
> randomness in it.  Try changing the dropbear config to use 
> /dev/urandom instead of dev/random.
>
> See this thread:
> http://codepoet.org/lists/uclibc/2005-February/011151.html
>
> Brent Davidson wrote:
>
>> I have been working on a custom embedded system with uClibc and 
>> busybox and want to add dropbear for sshd functions, but I have run 
>> into a problem.
>>
>> dropbear runs fine, but when I try to connect remotely or with 
>> dbclient admin@localhost the server proccess logs "Child connection 
>> from 127.0.0.1" and then the whole process freezes.  I am never 
>> presented a login prompt.
>>
>> I am compiling dropbear 0.44 with the MULTI=1 option under the 
>> pre-built uClibc development environment.
>
>



From matt at ucc.asn.au  Mon Feb 28 08:14:40 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon Feb 28 08:15:01 2005
Subject: Problem with dropbear and uClibc / busybox
In-Reply-To: <4222338A.7040504@tlab.net>
References: <42211684.8000508@tlab.net> <4221201E.7070709@idahotech.com>
	<4222338A.7040504@tlab.net>
Message-ID: <20050228001440.GG354083@morwong.ucc.gu.uwa.edu.au>

On Sun, Feb 27, 2005 at 02:54:34PM -0600, Brent Davidson wrote:
> Well, I mamanged to get the hang up problem fixed, but now I'm having 
> another issue...  Once I log in, I get the following in the log:
> 
> [326] Jan 03 20:39:46 pty_allocate: openpty: No such file or directory
> [326] Jan 03 20:39:46 no pty was allocated, couldn't execute
> 
> (Yes, I know the date is wrong, I haven't set that yet.)
> 
> What am I missing now?

Perhaps devpts needs to be mounted on /dev/pts ? It might
depend on what options you have set in your uClibc config.

If you can run strace on Dropbear, that'll be a quick way to
see what's missing.

Matt
From brentd at tlab.net  Mon Feb 28 09:12:53 2005
From: brentd at tlab.net (Brent Davidson)
Date: Mon Feb 28 09:13:25 2005
Subject: Problem with dropbear and uClibc / busybox
In-Reply-To: <20050228001440.GG354083@morwong.ucc.gu.uwa.edu.au>
References: <42211684.8000508@tlab.net> <4221201E.7070709@idahotech.com>
	<4222338A.7040504@tlab.net>
	<20050228001440.GG354083@morwong.ucc.gu.uwa.edu.au>
Message-ID: <42227015.4010006@tlab.net>

Well, I'm not exactly sure how I fixed the problem, as I did the classic 
"try two things at once", but I turned on support for legacy pty's in my 
kernel and also recompiled dropobear as a static binary and it is now 
working.

Thanks for the help.

-Brent

Matt Johnston wrote:

>On Sun, Feb 27, 2005 at 02:54:34PM -0600, Brent Davidson wrote:
>  
>
>>Well, I mamanged to get the hang up problem fixed, but now I'm having 
>>another issue...  Once I log in, I get the following in the log:
>>
>>[326] Jan 03 20:39:46 pty_allocate: openpty: No such file or directory
>>[326] Jan 03 20:39:46 no pty was allocated, couldn't execute
>>
>>(Yes, I know the date is wrong, I haven't set that yet.)
>>
>>What am I missing now?
>>    
>>
>
>Perhaps devpts needs to be mounted on /dev/pts ? It might
>depend on what options you have set in your uClibc config.
>
>If you can run strace on Dropbear, that'll be a quick way to
>see what's missing.
>
>Matt
>
>
>
>  
>



From matt at ucc.asn.au  Mon Feb 28 09:31:07 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon Feb 28 09:31:18 2005
Subject: Problem with dropbear and uClibc / busybox
In-Reply-To: <42227015.4010006@tlab.net>
References: <42211684.8000508@tlab.net> <4221201E.7070709@idahotech.com>
	<4222338A.7040504@tlab.net>
	<20050228001440.GG354083@morwong.ucc.gu.uwa.edu.au>
	<42227015.4010006@tlab.net>
Message-ID: <20050228013107.GH354083@morwong.ucc.gu.uwa.edu.au>

On Sun, Feb 27, 2005 at 07:12:53PM -0600, Brent Davidson wrote:
> Well, I'm not exactly sure how I fixed the problem, as I did the classic 
> "try two things at once", but I turned on support for legacy pty's in my 
> kernel and also recompiled dropobear as a static binary and it is now 
> working.

I'm fairly sure it'd be the former, unless something
severely strange is going on :)

Matt
From matt at ucc.asn.au  Tue Mar  1 01:02:32 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue Mar  1 01:02:41 2005
Subject: scp log out session after successful completion
In-Reply-To: <42184538.4030108@mbari.org>
References: <42184538.4030108@mbari.org>
Message-ID: <20050228170232.GP354083@morwong.ucc.gu.uwa.edu.au>

On Sun, Feb 20, 2005 at 12:07:20AM -0800, Brent Roman wrote:
> Hi,
> 
> I'm running dropbear on an embedded ARM from Technologics.
> It's your v0.44 with the 2.4x linux kernel and busybox v1.0
> 
> ... when I invoke dropbear's scp interactively, it appears
> to close stdin (or redirect it ot /dev/null somehow)
> for the shell after completing successfully.
> This causes the shell to logout.

This looks similar to a bug which I thought I'd fixed,
related to setting stdin to be non-blocking. 

Could you try the attached patch, which does the same thing
with stdout and stderr?

Cheers,
Matt

> brent@ESPhost$ scp -v -i .ssh/id_rsa .irbrc bufflehead:irbrc
> Executing: program /usr/bin/dbclient host bufflehead, user 
> (unspecified), command scp -v -t irbrc
> WARNING: Ignoring unknown argument '-x'
> WARNING: Ignoring unknown argument '-oForwardAgent no'
> WARNING: Ignoring unknown argument '-oClearAllForwardings yes'
> WARNING: Ignoring unknown argument '-v'
> Sending file modes: C0644 825 .irbrc
> Sink: C0644 825 .irbrc
> brent@ESPhost$
> Use "exit" to leave shell.
> brent@ESPhost$
> Use "exit" to leave shell.
> brent@ESPhost$
-------------- next part --------------
# 
# patch "cli-session.c"
#  from [044e633a29f6fea152646a63193851598f5d0b4d]
#    to [456ed9269b52604e2d0c8aa700ba987974d0fd7b]
# 
# patch "session.h"
#  from [cc4c1b731836950406593afc60fedd35a59f9adb]
#    to [8b1677ad8f52c19aa94571211683d6ef04de2d6a]
# 
--- cli-session.c
+++ cli-session.c
@@ -113,10 +113,14 @@
 	cli_ses.tty_raw_mode = 0;
 	cli_ses.winchange = 0;
 
-	/* We store stdin's flags, so we can set them back on exit (otherwise
-	 * busybox's ash isn't happy */
+	/* We store std{in,out,err}'s flags, so we can set them back on exit
+	 * (otherwise busybox's ash isn't happy */
 	cli_ses.stdincopy = dup(STDIN_FILENO);
 	cli_ses.stdinflags = fcntl(STDIN_FILENO, F_GETFL, 0);
+	cli_ses.stdoutcopy = dup(STDOUT_FILENO);
+	cli_ses.stdoutflags = fcntl(STDOUT_FILENO, F_GETFL, 0);
+	cli_ses.stderrcopy = dup(STDERR_FILENO);
+	cli_ses.stderrflags = fcntl(STDERR_FILENO, F_GETFL, 0);
 
 	cli_ses.retval = EXIT_SUCCESS; /* Assume it's clean if we don't get a
 									  specific exit status */
@@ -250,9 +254,11 @@
 		return;
 	}
 
-	/* Set stdin back to non-blocking - busybox ash dies nastily
-	 * if we don't revert the flags */
+	/* Set std{in,out,err} back to non-blocking - busybox ash dies nastily if
+	 * we don't revert the flags */
 	fcntl(cli_ses.stdincopy, F_SETFL, cli_ses.stdinflags);
+	fcntl(cli_ses.stdoutcopy, F_SETFL, cli_ses.stdoutflags);
+	fcntl(cli_ses.stderrcopy, F_SETFL, cli_ses.stderrflags);
 
 	cli_tty_cleanup();
 
--- session.h
+++ session.h
@@ -218,6 +218,10 @@
 	struct termios saved_tio;
 	int stdincopy;
 	int stdinflags;
+	int stdoutcopy;
+	int stdoutflags;
+	int stderrcopy;
+	int stderrflags;
 
 	int winchange; /* Set to 1 when a windowchange signal happens */
 
From claudio at rictec.com.br  Tue Mar  1 01:58:03 2005
From: claudio at rictec.com.br (Claudio Roberto Cussuol)
Date: Tue Mar  1 01:58:36 2005
Subject: DO_HOST_LOOKUP option is ignored
Message-ID: <200522814583.158915@claudio>

> I've tracked down the version 0.43 and found it's use inside the dbutils.c 
file 
> but this portion of code doesn't exist anymore. The only use of the function 
> gethostbyaddr i've found in 0.44 is inside the file fake-rfc2553.c.

Matt

Now you're back, can you do something about this problem.
I've tried to fix it myself but have no success.

Thank You

Claudio.


From matt at ucc.asn.au  Tue Mar  1 02:07:30 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue Mar  1 02:07:36 2005
Subject: DO_HOST_LOOKUP option is ignored
In-Reply-To: <200522814583.158915@claudio>
References: <200522814583.158915@claudio>
Message-ID: <20050228180730.GB421162@morwong.ucc.gu.uwa.edu.au>

And cc to the list...

On Mon, Feb 28, 2005 at 02:58:03PM -0300, Claudio Roberto Cussuol wrote:
> > I've tracked down the version 0.43 and found it's use inside the dbutils.c
> file
> > but this portion of code doesn't exist anymore. The only use of the function
> > gethostbyaddr i've found in 0.44 is inside the file fake-rfc2553.c.
> 
> Matt
> 
> Now you're back, can you do something about this problem.
> I've tried to fix it myself but have no success.

Ah sorry, I thought I'd sent the patch to the list, but
obviously hadn't. Attached should be a fix.

I'll put out 0.45 soon, once I've sorted out a few remaining
issues.

Matt
-------------- next part --------------
# 
# patch "dbutil.c"
#  from [8b3d574e5857f596259ae610db1507c11c150b6d]
#    to [77ff997b12541085494a855acbcef332497c8e3a]
# 
# patch "options.h"
#  from [4f331e42fbe00636bb01fb871ce8cbdf673852c8]
#    to [ac14d24a7eadb33fbb4c36865f48cca9d4ccae15]
# 
--- dbutil.c
+++ dbutil.c
@@ -397,6 +397,11 @@
 	char sbuf[NI_MAXSERV];
 	int ret;
 	unsigned int len;
+#ifdef DO_HOST_LOOKUP
+	const int flags = NI_NUMERICSERV;
+#else
+	const int flags = NI_NUMERICHOST | NI_NUMERICSERV;
+#endif
 
 	len = sizeof(struct sockaddr_storage);
 	/* Some platforms such as Solaris 8 require that len is the length
@@ -410,8 +415,9 @@
 	}
 #endif
 
+
 	ret = getnameinfo((struct sockaddr*)addr, len, hbuf, sizeof(hbuf),
-			sbuf, sizeof(sbuf), NI_NUMERICSERV);
+			sbuf, sizeof(sbuf), flags);
 
 	if (ret != 0) {
 		/* On some systems (Darwin does it) we get EINTR from getnameinfo
--- options.h
+++ options.h
@@ -96,9 +96,7 @@
  * if the random number source isn't good. In general this isn't required */
 /* #define DSS_PROTOK */
 
-/* Whether to do reverse DNS lookups. This is advisable, though will add
- * code size with gethostbyname() etc, so for very small environments where
- * you are statically linking, you might want to undefine this */
+/* Whether to do reverse DNS lookups. */
 #define DO_HOST_LOOKUP
 
 /* Whether to print the message of the day (MOTD). This doesn't add much code
From matt at ucc.asn.au  Mon Mar  7 12:46:21 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon Mar  7 12:46:25 2005
Subject: Dropbear 0.45 released
Message-ID: <20050307044621.GD116966@morwong.ucc.gu.uwa.edu.au>

Hi all.

I've tarred up a Dropbear 0.45 release, it doesn't contain
many major fixes, just a few bug fixes which have been
mentioned on the list. Changelog follows:

- Makefile no longer appends 'static' to statically linked binaries

- Add optional SSH_ASKPASS support to the client

- Respect HOST_LOOKUP option

- Fix accidentally removed "return;" statement which was removed in 0.44
  (causing clients which sent an empty terminal-modes string to fail to
  connect - including pssh, ssh.com, danger hiptop). (patches
  independently from Paul Fox, David Horwitt and Sven-Ola Tuecke)

- Read "y/n" response for fingerprints from /dev/tty directly so that dbclient
  will work with scp.

Particular thanks to Paul Whittaker for the askpass support.

Matt
From claas+maillinglists.dropbear at jucs-kramkiste.de  Mon Mar  7 18:25:38 2005
From: claas+maillinglists.dropbear at jucs-kramkiste.de (Claas Hilbrecht)
Date: Mon Mar  7 18:26:06 2005
Subject: Dropbear 0.45 released
In-Reply-To: <20050307044621.GD116966@morwong.ucc.gu.uwa.edu.au>
References: <20050307044621.GD116966@morwong.ucc.gu.uwa.edu.au>
Message-ID: <3A47986C4C32AB536FD34EF8@[192.168.1.22]>

--Am Montag, 7. M?rz 2005 12:46 +0800 Matt Johnston <matt@ucc.asn.au> 
schrieb:

> I've tarred up a Dropbear 0.45 release, it doesn't contain
> many major fixes, just a few bug fixes which have been
> mentioned on the list. Changelog follows:

Thanks, compiles fine. I wonder if you have an estimated date for encrypted 
keys support in dblient?

-- 
 Claas Hilbrecht
 http://www.jucs-kramkiste.de


From brent at mbari.org  Thu Mar 10 07:45:03 2005
From: brent at mbari.org (Brent Roman)
Date: Thu Mar 10 07:45:54 2005
Subject: scp log out session after successful completion
Message-ID: <422F8A7F.2060404@mbari.org>

Hi Matt,

Sorry about the long delay getting back to you.

The patch you supplied appears to work.
Busybox 1.00 _release_ (as opposed to rc3)
adds code to explicitly turn off non-blocking behavior
if an application hands stdout/stdin back in this state.

It outputs some warning about NDELAY cancelled in this case.
However, with your patch, this warning is suppressed.

I applied it against 0.45.  No problems.

Thanks!

- brent


On Sun, Feb 20, 2005 at 12:07:20AM -0800, Brent Roman wrote:
>/ Hi,
/>/ 
/>/ I'm running dropbear on an embedded ARM from Technologics.
/>/ It's your v0.44 with the 2.4x linux kernel and busybox v1.0
/>/ 
/>/ ... when I invoke dropbear's scp interactively, it appears
/>/ to close stdin (or redirect it ot /dev/null somehow)
/>/ for the shell after completing successfully.
/>/ This causes the shell to logout.
/
This looks similar to a bug which I thought I'd fixed,
related to setting stdin to be non-blocking. 

Could you try the attached patch, which does the same thing
with stdout and stderr?

Cheers,
Matt


-- 
 Brent Roman                                   MBARI
 Software Engineer               Tel: (831) 775-1808
 7700 Sandholdt Road,         Moss Landing, CA 95039
 mailto:brent@mbari.org  http://www.mbari.org/~brent


From gavinux at yahoo.com  Fri Mar 18 21:46:56 2005
From: gavinux at yahoo.com (Gavinux)
Date: Fri Mar 18 21:47:16 2005
Subject: ssh connection wait forever 
Message-ID: <20050318134657.83834.qmail@web50308.mail.yahoo.com>

I compiled dropbear for my embedded system
(linux-2.4.27, glibc-2.2.5, busybox-1.00). I boot my
system from NFS server, then, I use ssh from Redhat
7.3 or putty from Win2k to connect to my embedded
system, and the ssh client (or putty) wait forever,
nothing displayed, until I press some keys on my
embedded system's keyboard. and then the cilent
prompts username and password.
But if I boot my embedded system from local disk,
everything is fine.
Anything I didn't setup correctly?
P.S. The file system and kernel are the same in local
disk and NFS server.


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250

From matt at ucc.asn.au  Fri Mar 18 22:16:27 2005
From: matt at ucc.asn.au (Matt Johnston)
Date: Fri Mar 18 22:16:33 2005
Subject: ssh connection wait forever
In-Reply-To: <20050318134657.83834.qmail@web50308.mail.yahoo.com>
References: <20050318134657.83834.qmail@web50308.mail.yahoo.com>
Message-ID: <20050318141627.GC2897@morwong.ucc.gu.uwa.edu.au>

On Fri, Mar 18, 2005 at 05:46:56AM -0800, Gavinux wrote:
> I compiled dropbear for my embedded system
> (linux-2.4.27, glibc-2.2.5, busybox-1.00). I boot my
> system from NFS server, then, I use ssh from Redhat
> 7.3 or putty from Win2k to connect to my embedded
> system, and the ssh client (or putty) wait forever,
> nothing displayed, until I press some keys on my
> embedded system's keyboard. and then the cilent
> prompts username and password.
> But if I boot my embedded system from local disk,
> everything is fine.
> Anything I didn't setup correctly?
> P.S. The file system and kernel are the same in local
> disk and NFS server.

It's probably still the same problem about lack of random
data (see
http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2005q1/000151.html
).

The solutions are to make sure that there's enough entropy
and use urandom (if you don't make sure, you'll end up with
an insecure system), or perhaps look at patches for the
kernel to get random input from network card timings etc.

Since you're trusting the NFS link anyway, you could
probably arrange something with getting entropy from the
Redhat box - though _only_ if you know that you can trust
that path.

Matt
From rich.ireland at idahotech.com  Fri Mar 18 23:44:34 2005
From: rich.ireland at idahotech.com (Rich Ireland)
Date: Fri Mar 18 23:45:00 2005
Subject: ssh connection wait forever
In-Reply-To: <20050318141627.GC2897@morwong.ucc.gu.uwa.edu.au>
References: <20050318134657.83834.qmail@web50308.mail.yahoo.com>
	<20050318141627.GC2897@morwong.ucc.gu.uwa.edu.au>
Message-ID: <423AF762.6050607@idahotech.com>

Matt Johnston wrote:
> On Fri, Mar 18, 2005 at 05:46:56AM -0800, Gavinux wrote:
> 
>>I compiled dropbear for my embedded system
>>(linux-2.4.27, glibc-2.2.5, busybox-1.00). I boot my
>>system from NFS server, then, I use ssh from Redhat
>>7.3 or putty from Win2k to connect to my embedded
>>system, and the ssh client (or putty) wait forever,
>>nothing displayed, until I press some keys on my
>>embedded system's keyboard. and then the cilent
>>prompts username and password.
>>But if I boot my embedded system from local disk,
>>everything is fine.
>>Anything I didn't setup correctly?
>>P.S. The file system and kernel are the same in local
>>disk and NFS server.
> 
> 
> It's probably still the same problem about lack of random
> data (see
> http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2005q1/000151.html
> ).
> 
> The solutions are to make sure that there's enough entropy
> and use urandom (if you don't make sure, you'll end up with
> an insecure system), or perhaps look at patches for the
> kernel to get random input from network card timings etc.
> 
> Since you're trusting the NFS link anyway, you could
> probably arrange something with getting entropy from the
> Redhat box - though _only_ if you know that you can trust
> that path.

I concur with Matt's assessment.  These are identical symptoms that I 
encountered on a Cogent CSB337 last month.

If you are using uClibc/buildroot, you can use the patch I recently 
submitted to add a 'low entropy' build option for dropbear.

http://bugs.uclibc.org/view.php?id=138

-- 
Rich Ireland
Firmware Engineer - Perforce Advocate
Idaho Technology, Inc.
http://www.idahotech.com/
mailto:rich.ireland@idahotech.com