From csegura at HPTI.com Thu Oct 6 04:41:52 2005 From: csegura at HPTI.com (Segura, Cynthia) Date: Wed, 5 Oct 2005 16:41:52 -0400 Subject: dropbear and ssh keys Message-ID: <5045A4D718CAB644BA24979206486B600EA8CB@hptimail03.HPTI.COM> Hello, I am having trouble getting ssh keys to work with dropbear. I have downloaded and compiled buildroot, with BusyBox v1.1.0-pre1 and Dropbear sshd v0.46. I have compiled dropbear with: Use /dev/urandom (low entropy systems only). I am working on a small cluster. The admin node has a full Linux distribution (Red Hat Enterprise Linux WS release 4) and the compute nodes are running the minimal linux. The admin node is using ssh: F-Secure SSH 3.2.3 (build 14) on i686-pc-linux-gnu. I have created the public and private keys on the admin node using the following command: ssh-keygen -b 1024 -t rsa and copied the public key into the compute node's /root/.ssh/authorized_keys (I have also tried to this for dss keys). However, when I try to ssh to a compute node, I receive the following messages, and am prompted for a password. Password authentication works fine, but to do mpi runs, I need to be able to login without a password. Am I missing something obvious? Does dropbear understand the ssh-key format or do I have to convert them using dropbearconvert? root at chicken root]# ssh -vvv n1 debug: Connecting to n1, port 22... (SOCKS not used) debug: Ssh2Transport/trcommon.c:3748/ssh_tr_create: My version: SSH-1.99-3.2.9 0 debug: client supports 4 auth methods: 'gssapi,kerberos-tgt-2 at ssh.com,kerberos-' debug: Ssh2Common/sshcommon.c:587/ssh_common_wrap: local ip = 192.168.1.100, lo4 debug: Ssh2Common/sshcommon.c:589/ssh_common_wrap: remote ip = 192.168.1.20, re2 debug: SshConnection/sshconn.c:1945/ssh_conn_wrap: Wrapping... debug: SshReadLine/sshreadline.c:2432/ssh_readline_eloop_initialize: Initializi. debug: Remote version: SSH-2.0-dropbear_0.46 debug: Ssh2Transport/trcommon.c:1376/ssh_tr_negotiate: lang s to c: `', lang c ' debug: Ssh2Transport/trcommon.c:1441/ssh_tr_negotiate: c_to_s: cipher 3des-cbc,e debug: Ssh2Transport/trcommon.c:1444/ssh_tr_negotiate: s_to_c: cipher 3des-cbc,e debug: Remote host key found from database. debug: Ssh2Common/sshcommon.c:379/ssh_common_special: Received SSH_CROSS_STARTU. debug: Ssh2Common/sshcommon.c:429/ssh_common_special: Received SSH_CROSS_ALGORI. debug: server offers auth methods 'publickey,password'. debug: Ssh2AuthPasswdClient/authc-passwd.c:105/ssh_client_auth_passwd: Starting. root's password: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20051005/92d6c88f/attachment.html From matt at ucc.asn.au Fri Oct 7 00:02:48 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 7 Oct 2005 00:02:48 +0800 Subject: dropbear and ssh keys In-Reply-To: <5045A4D718CAB644BA24979206486B600EA8CB@hptimail03.HPTI.COM> References: <5045A4D718CAB644BA24979206486B600EA8CB@hptimail03.HPTI.COM> Message-ID: <20051006160248.GN30641@ucc.gu.uwa.edu.au> On Wed, Oct 05, 2005 at 04:41:52PM -0400, Segura, Cynthia wrote: > Hello, I am having trouble getting ssh keys to work with dropbear. I have downloaded and compiled buildroot, with BusyBox v1.1.0-pre1 and Dropbear sshd v0.46. I have compiled dropbear with: > Use /dev/urandom (low entropy systems only). I am working on a small cluster. The admin node has a full Linux distribution (Red Hat Enterprise Linux WS release 4) and the compute nodes are running the minimal linux. The admin node is using ssh: F-Secure SSH 3.2.3 (build 14) on i686-pc-linux-gnu. I have created the public and private keys on the admin node using the following command: > > ssh-keygen -b 1024 -t rsa > > and copied the public key into the compute node's /root/.ssh/authorized_keys > > (I have also tried to this for dss keys). > > However, when I try to ssh to a compute node, I receive the following messages, and am prompted for a password. Password authentication works fine, but to do mpi runs, I need to be able to login without a password. Am I missing something obvious? Does dropbear understand the ssh-key format or do I have to convert them using dropbearconvert? Dropbear has the same format public keys (ie what you put in authorized_keys) as OpenSSH, something like: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAtiF7WDzehGhXZOPrm2bHcl464k9VYekP8Tuf7K+smThzwQHDPExlChX537sDIJuTEoUiYVGEqnqpwn5XDkoUR8XK0iY3NZQH2CixS3nB7PMkIWEJxE9Gb/9P+yXZKcVC/KIapabBKGcYSyGLOy7lZ5CqR/HjfL4hNwFK1EdfFFc= matt at rez One common problem is permissions on ~, ~/.ssh and ~/.ssh/authorized_keys. These all need to be writable only by the user (or root), otherwise Dropbear will just ignore the file. There's code in my development tree to log a warning since it's common, so it'll be on 0.47. If that doesn't help, let me know and I'll investigate further. Another thing to look out is accidental line breaks in the key line. Cheers, Matt From jamie at shareable.org Tue Oct 4 20:34:36 2005 From: jamie at shareable.org (Jamie Lokier) Date: Tue, 4 Oct 2005 13:34:36 +0100 Subject: dbclient using 100% CPU Message-ID: <20051004123436.GB15956@mail.shareable.org> I'm using dbclient on an ARM + uClinux device, and I see that it's using 100% CPU although it has nothing to do. The command looks like this: dbclient -T -i /root/.ssh/id_rsa.db 192.168.0.100 -R 10136:127.0.0.1:23 'while :; do echo keepalive; sleep 20; done' The standard input and standard output are both /dev/null. ( If standard output is not /dev/null, I don't see 100% CPU, but the same "select for read on standard output" behaviour described below occurs. ) The output of strace explains the 100% CPU: select(4, [1 3], [], NULL, {20, 0}) = 1 (in [1], left {20, 0}) gettimeofday({1105499730, 917033}, NULL) = 0 write(1, NULL, 0) = 0 select(4, [1 3], [], NULL, {20, 0}) = 1 (in [1], left {20, 0}) gettimeofday({1105499731, 117149}, NULL) = 0 write(1, NULL, 0) = 0 ... repeating ... Why is it selecting for _read_ on the standard _output_ file descriptor? That looks like a bug to me. The function setchannelfds() in common-channel.c may be the culprit. The code and comments in setchannelfds() contradict the comments in channel.h, concerning roles of channel->infd and channel->outfd: /* Stuff to put over the wire */ if (channel->transwindow > 0) { if (channel->outfd >= 0) { FD_SET(channel->outfd, readfd); /* Stuff from the wire, to local program/shell/user etc */ if ((channel->infd >= 0 && cbuf_getused(channel->writebuf) > 0 ) || channel->initconn) { FD_SET(channel->infd, writefd); but: int infd; /* data to send over the wire */ int outfd; /* data for consumption, what was in writebuf */ Thanks, -- Jamie From iamphr at gmail.com Fri Oct 7 18:29:05 2005 From: iamphr at gmail.com (phr phr) Date: Fri, 7 Oct 2005 18:29:05 +0800 Subject: dropbear on uClibc-0.9.15 Message-ID: <3cf26ab60510070329r1a54aeev@mail.gmail.com> Hi all, I would like to use dropbear on uClibc-0.9.15 is it possible ? As i know all version can only run above uClibc-0.9.17. Best regards, Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20051007/26151f16/attachment.html From matt at ucc.asn.au Fri Oct 7 20:19:07 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 7 Oct 2005 20:19:07 +0800 Subject: dropbear on uClibc-0.9.15 In-Reply-To: <3cf26ab60510070329r1a54aeev@mail.gmail.com> References: <3cf26ab60510070329r1a54aeev@mail.gmail.com> Message-ID: <20051007121907.GG30641@ucc.gu.uwa.edu.au> On Fri, Oct 07, 2005 at 06:29:05PM +0800, phr phr wrote: > Hi all, > I would like to use dropbear on uClibc-0.9.15 is it possible ? > As i know all version can only run above uClibc-0.9.17. As far as I recall, when I tried Dropbear using versions of uClibc before 0.9.17 getusershell() I had problems with it returning bogus values. Other than that, I don't know of any particular reasons why it wouldn't work. It's possible that it might work OK in some situations, or if you're using it for a well-controlled embedded type environment, removing the whole check (from lines 257 to 274 in svr-auth.c) is probably safe. Note that removing those lines will let users log in even if their shell has been set to something invalid (common practice for locking accounts), and code which runs when they actually log in may fail. Matt From matt at ucc.asn.au Mon Oct 10 01:30:33 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 10 Oct 2005 01:30:33 +0800 Subject: dbclient using 100% CPU In-Reply-To: <20051004123436.GB15956@mail.shareable.org> References: <20051004123436.GB15956@mail.shareable.org> Message-ID: <20051009173033.GW30641@ucc.gu.uwa.edu.au> On Tue, Oct 04, 2005 at 01:34:36PM +0100, Jamie Lokier wrote: > I'm using dbclient on an ARM + uClinux device, and I see that it's > using 100% CPU although it has nothing to do. > > The command looks like this: > > dbclient -T -i /root/.ssh/id_rsa.db 192.168.0.100 -R 10136:127.0.0.1:23 'while :; do echo keepalive; sleep 20; done' > > The standard input and standard output are both /dev/null. ( If > standard output is not /dev/null, I don't see 100% CPU, but the same > "select for read on standard output" behaviour described below occurs. ) > > The output of strace explains the 100% CPU: > > select(4, [1 3], [], NULL, {20, 0}) = 1 (in [1], left {20, 0}) > gettimeofday({1105499730, 917033}, NULL) = 0 > write(1, NULL, 0) = 0 > select(4, [1 3], [], NULL, {20, 0}) = 1 (in [1], left {20, 0}) > gettimeofday({1105499731, 117149}, NULL) = 0 > write(1, NULL, 0) = 0 > ... repeating ... > > Why is it selecting for _read_ on the standard _output_ file > descriptor? That looks like a bug to me. The file descriptors are being treated correctly (or rather as intended), they're just badly named (when I initially wrote the code and Dropbear was server-only, I was thinking in terms of infd being the shell program's stdin etc). I've been meaning to clean them up to avoid confusion. The actual problem seems to be in the section of code trying to detect the pipe being closed, by reading 0 bytes from the writefd. I don't think that code is required any more, removing it fixes the CPU spinning. I've attached a patch, could you try that and see how it goes (and also if you see any side-effects)? I'll have a closer look at what's going on and test a few more platforms before committing that change. Thanks, Matt -------------- next part -------------- # # old_revision [8b52f8af5e976e88a542827b554b489a557464da] # # patch "common-channel.c" # from [42c4b46eac09d7abf45f066a008e5d2cafbb0127] # to [ed7183d857c5dbb3ace56a2cf3b7a6cbf7a9bdd0] # ============================================================ --- common-channel.c 42c4b46eac09d7abf45f066a008e5d2cafbb0127 +++ common-channel.c ed7183d857c5dbb3ace56a2cf3b7a6cbf7a9bdd0 @@ -203,24 +203,6 @@ send_msg_channel_data(channel, 1, SSH_EXTENDED_DATA_STDERR); } - /* if we can read from the infd, it might be closed, so we try to - * see if it has errors */ - if (channel->infd >= 0 && channel->infd != channel->outfd - && FD_ISSET(channel->infd, readfd)) { - if (channel->initconn) { - /* Handling for "in progress" connection - this is needed - * to avoid spinning 100% CPU when we connect to a server - * which doesn't send anything (tcpfwding) */ - checkinitdone(channel); - continue; /* Important not to use the channel after - checkinitdone(), as it may be NULL */ - } - ret = write(channel->infd, NULL, 0); /* Fake write */ - if (ret < 0 && errno != EINTR && errno != EAGAIN) { - closeinfd(channel); - } - } - /* write to program/pipe stdin */ if (channel->infd >= 0 && FD_ISSET(channel->infd, writefd)) { if (channel->initconn) { @@ -445,16 +427,6 @@ } } - /* For checking FD status (ie closure etc) - we don't actually - * read data from infd */ - TRACE(("infd = %d, outfd %d, errfd %d, bufused %d", - channel->infd, channel->outfd, - channel->errfd, - cbuf_getused(channel->writebuf) )) - if (channel->infd >= 0 && channel->infd != channel->outfd) { - FD_SET(channel->infd, readfd); - } - /* Stuff from the wire, to local program/shell/user etc */ if ((channel->infd >= 0 && cbuf_getused(channel->writebuf) > 0 ) || channel->initconn) { From yan at seiner.com Mon Oct 10 02:22:50 2005 From: yan at seiner.com (Yan Seiner) Date: Sun, 09 Oct 2005 11:22:50 -0700 Subject: login attempt to nonexistent user Message-ID: <43495FFA.9070504@seiner.com> I am trying to build a minimal system. Basically, this system is a semi-embedded sort of thing; an old Mac that will sit in a remote location running a vpn tunnel and rsync. As such, I am building the rootfs by hand; adding only those libraries and files that are abosolutely necessary. The system is based on Debian Sarge. It successfully boots using busybox, and I have rsync and vtun running. ssh logins are the last piece of the puzzle. I have successfully compiled dropbear, and it runs fine, but when I try to login via ssh, I get (on the client): yan at poseidon:~/.ssh$ ssh pizza -l root root at pizza's password: Permission denied, please try again. root at pizza's password: Permission denied, please try again. root at pizza's password: Permission denied (publickey,password). and on the dropbear server I get the message 'Login attempt for non-existent user from 192.168.128.222:nnnn What's going on? I have /etc/passwd set up.... I'm not getting any errors or anything from dropbear. --Yan From cristian.ionescu-idbohrn at axis.com Mon Oct 10 02:48:55 2005 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 9 Oct 2005 20:48:55 +0200 (CEST) Subject: login attempt to nonexistent user In-Reply-To: <43495FFA.9070504@seiner.com> References: <43495FFA.9070504@seiner.com> Message-ID: <0510092043010.594@somehost> On Sun, 9 Oct 2005, Yan Seiner wrote: > yan at poseidon:~/.ssh$ ssh pizza -l root > root at pizza's password: > Permission denied, please try again. [snip] > and on the dropbear server I get the message 'Login attempt for > non-existent user from 192.168.128.222:nnnn That would indicate there's no 'root' user in /etc/passwd and/or some /etc/shadow cludge. > What's going on? I have /etc/passwd set up.... Permissions on various files may need checking too. > I'm not getting any errors or anything from dropbear. Do you see anything useful if you run: $ ssh -vvv pizza -l root Cheers, Cristian -- Debian GNU/Linux: satisfaction guaranteed, or double your money back. From yan at seiner.com Mon Oct 24 22:08:55 2005 From: yan at seiner.com (Yan Seiner) Date: Mon, 24 Oct 2005 07:08:55 -0700 Subject: Nonexistent user, continued Message-ID: <435CEAF7.9030809@seiner.com> When I try to log in via dropbear, I get login attempt for non-existent user from 111.222.333.444:nnnn This is the result of running ssh -vvv on the client. There doesn't appear to be anything useful on the dropbear end other than that message. I am not using shadow files, and I've checked that shells and home dirs exist as shown in the /etc/passwd file.... debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/identity debug3: no such identity: /root/.ssh/identity debug1: Offering public key: /root/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug1: Offering public key: /root/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password root at pizza's password: From cristian.ionescu-idbohrn at axis.com Mon Oct 24 22:39:01 2005 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Mon, 24 Oct 2005 16:39:01 +0200 (CEST) Subject: Nonexistent user, continued In-Reply-To: <435CEAF7.9030809@seiner.com> References: <435CEAF7.9030809@seiner.com> Message-ID: <0510241636440.20461@somehost> On Mon, 24 Oct 2005, Yan Seiner wrote: > When I try to log in via dropbear, I get login attempt for > non-existent user from 111.222.333.444:nnnn > > This is the result of running ssh -vvv on the client. There doesn't > appear to be anything useful on the dropbear end other than that > message. What would _you_ like the daemon to do? Cheers, Cristian From matt at ucc.asn.au Tue Oct 25 00:16:49 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 25 Oct 2005 00:16:49 +0800 Subject: Nonexistent user, continued In-Reply-To: <435CEAF7.9030809@seiner.com> References: <435CEAF7.9030809@seiner.com> Message-ID: <20051024161649.GU30641@ucc.gu.uwa.edu.au> On Mon, Oct 24, 2005 at 07:08:55AM -0700, Yan Seiner wrote: > When I try to log in via dropbear, I get login attempt for non-existent > user from 111.222.333.444:nnnn > > This is the result of running ssh -vvv on the client. There doesn't > appear to be anything useful on the dropbear end other than that message. > > I am not using shadow files, and I've checked that shells and home dirs > exist as shown in the /etc/passwd file.... The "login attempt for nonexistent user" warning gets printed if the call to the standard library getpwnam() function fails. The username isn't printed in the logs because quite often it might actually be someone mistakenly typing a password rather than a username, which shouldn't be logged. The standard library doesn't provide any reasons for getpwnam failure - running "strace -f" on the Dropbear process (if available) is often insightful for problems like this though. If you are compiling Dropbear yourself, you could try compiling with DEBUG_TRACE enabled in debug.h and running with -v -F -E, though it seems unlikely that a username other than "root" is actually getting passed to the server. Perhaps double check that /etc/passwd and maybe /etc/group are well formed. What sort of platform are you running on (OS and libc)? Let me know how you go. Cheers, Matt From fj40rockcrawler at yahoo.com Tue Oct 25 01:05:49 2005 From: fj40rockcrawler at yahoo.com (Mark Brodis) Date: Mon, 24 Oct 2005 10:05:49 -0700 (PDT) Subject: Nonexistent user, continued In-Reply-To: <20051024161649.GU30641@ucc.gu.uwa.edu.au> Message-ID: <20051024170549.5300.qmail@web52804.mail.yahoo.com> I am a complete noobie with any of this, but I had an instance where I got the "login attempt for nonexistent user", and the problem (not found by me, refer to me being the noob) was /dev/pts/ was not mounted in /etc/fstab. I realize this is probably totally out in left-field from what you guys are dealing with but we got that exact same error, user was valid, but the device for the login had not been created/mounted and that same error came up. This was a few months ago and thus on a older version of dropbear. Just my $0.00 worth... Good Luck, Mark Brodis --- Matt Johnston wrote: > On Mon, Oct 24, 2005 at 07:08:55AM -0700, Yan Seiner wrote: > > When I try to log in via dropbear, I get login attempt for > non-existent > > user from 111.222.333.444:nnnn > > > > This is the result of running ssh -vvv on the client. There > doesn't > > appear to be anything useful on the dropbear end other than that > message. > > > > I am not using shadow files, and I've checked that shells and home > dirs > > exist as shown in the /etc/passwd file.... > > The "login attempt for nonexistent user" warning gets > printed if the call to the standard library getpwnam() > function fails. The username isn't printed in the logs > because quite often it might actually be someone mistakenly > typing a password rather than a username, which shouldn't be > logged. > > The standard library doesn't provide any reasons for > getpwnam failure - running "strace -f" on the Dropbear > process (if available) is often insightful for problems like > this though. If you are compiling Dropbear yourself, you > could try compiling with DEBUG_TRACE enabled in debug.h and > running with -v -F -E, though it seems unlikely that a > username other than "root" is actually getting passed to the > server. > > Perhaps double check that /etc/passwd and maybe /etc/group > are well formed. What sort of platform are you running on > (OS and libc)? > > Let me know how you go. > > Cheers, > Matt > > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From yan at seiner.com Tue Oct 25 22:07:25 2005 From: yan at seiner.com (Yan Seiner) Date: Tue, 25 Oct 2005 07:07:25 -0700 Subject: Nonexistent user, continued In-Reply-To: <20051024170549.5300.qmail@web52804.mail.yahoo.com> References: <20051024170549.5300.qmail@web52804.mail.yahoo.com> Message-ID: <435E3C1D.6000501@seiner.com> OK, I've checked everything I can think of; no joy. I have /dev/pts... I recompiled dropbear with debug, and it's failing in checkusername. Looking at the source, ses.authstate.pw == NULL so the check fails. Where is ses.authstate.pw loaded? scanning the source code didn't make anything jump out at me.... dropbear works fine on the same machine using full-blown debian install. It fails on my hand-built system, so most likely it's a missing lib.... But dropbear doesn't complain at all about any missing libs. I am trying to build a minimal system, using only those things that are needed. The machine is a Mac LC475 (1993 vintage), running a 2.2.25 kernel, the latest available for a m68k, with debian testing/unstable. (And yes, I did get rid of the problematic CPU and replaced it with a full-blown 68040.) I tried running strace, but when dropbear forks to handle the connection, the trace stops. How do I get strace to trace the child? strace -f -F dropbear -F -E -v didn't help. Any suggestions at this point? --Yan From matt at ucc.asn.au Tue Oct 25 23:27:29 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 25 Oct 2005 23:27:29 +0800 Subject: Nonexistent user, continued In-Reply-To: <435E3C1D.6000501@seiner.com> References: <20051024170549.5300.qmail@web52804.mail.yahoo.com> <435E3C1D.6000501@seiner.com> Message-ID: <20051025152729.GU30641@ucc.gu.uwa.edu.au> On Tue, Oct 25, 2005 at 07:07:25AM -0700, Yan Seiner wrote: > OK, I've checked everything I can think of; no joy. I have /dev/pts... > > I recompiled dropbear with debug, and it's failing in checkusername. > > Looking at the source, ses.authstate.pw == NULL so the check fails. > > Where is ses.authstate.pw loaded? scanning the source code didn't make > anything jump out at me.... ses.authstate.pw gets loaded a few lines before at svr-auth.c:213, from the call to getpwnam(). > I tried running strace, but when dropbear forks to handle the > connection, the trace stops. How do I get strace to trace the child? > strace -f -F dropbear -F -E -v didn't help. That's strange - tracing here I see the child process fine. To simplify things, try compiling and running (and straceing) the attached program with gcc -o getpwnamroot getpwnamroot.c Running it here (Debian testing iirc), I see it looking at /etc/nsswitch.conf - is that all that stuff set up right? Send me the strace output if you want and I'll have a look. Matt From matt at ucc.asn.au Wed Oct 26 13:17:04 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 26 Oct 2005 13:17:04 +0800 Subject: Nonexistent user, continued In-Reply-To: <435EF715.7020801@seiner.com> References: <20051024170549.5300.qmail@web52804.mail.yahoo.com> <435E3C1D.6000501@seiner.com> <20051025152729.GU30641@ucc.gu.uwa.edu.au> <435EF715.7020801@seiner.com> Message-ID: <20051026051704.GB30641@ucc.gu.uwa.edu.au> On Tue, Oct 25, 2005 at 08:25:09PM -0700, Yan Seiner wrote: > Matt Johnston wrote: > > >To simplify things, try compiling and running (and > >straceing) the attached program with > >gcc -o getpwnamroot getpwnamroot.c > > > > > Hi Matt: > > the attachment must have gotten stripped; in any case there was none.... *sigh* here it is now. Really should set up that mutt hook to warn about forgetting attachments... Matt > > >Running it here (Debian testing iirc), I see it looking at > >/etc/nsswitch.conf - is that all that stuff set up right? > > > > > > Nope. I don't have one.... I'll set one up and test tomorrow. This is > a learning exercise for me; I am trying to build a system by hand, one > file at a time. Interesting, if you like sorting sand. :-) > > Thanks for all your help. > > --Yan -------------- next part -------------- A non-text attachment was scrubbed... Name: getpwnamroot.c Type: text/x-csrc Size: 475 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20051026/5c0a2d7c/getpwnamroot.c From iamphr at gmail.com Wed Oct 26 17:40:30 2005 From: iamphr at gmail.com (phr phr) Date: Wed, 26 Oct 2005 17:40:30 +0800 Subject: Problem happen when putty trying to connect dropbear Message-ID: <3cf26ab60510260240w416943e2x@mail.gmail.com> Hi all, When i trying to connect dropbear server, putty got this message. "Server's host key did not match the signature supplied" Does that mean, my dropbear host key is not correct??? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20051026/b5bc4de4/attachment.htm From yan at seiner.com Sat Oct 29 23:17:39 2005 From: yan at seiner.com (Yan Seiner) Date: Sat, 29 Oct 2005 08:17:39 -0700 Subject: Nonexistent user, SOLVED In-Reply-To: <20051026051704.GB30641@ucc.gu.uwa.edu.au> References: <20051024170549.5300.qmail@web52804.mail.yahoo.com> <435E3C1D.6000501@seiner.com> <20051025152729.GU30641@ucc.gu.uwa.edu.au> <435EF715.7020801@seiner.com> <20051026051704.GB30641@ucc.gu.uwa.edu.au> Message-ID: <43639293.9060405@seiner.com> Matt Johnston wrote: >On Tue, Oct 25, 2005 at 08:25:09PM -0700, Yan Seiner wrote: > > >>Matt Johnston wrote: >> >> >> >>>To simplify things, try compiling and running (and >>>straceing) the attached program with >>>gcc -o getpwnamroot getpwnamroot.c >>> >>> >>> OK, here's the solution.... Keep in mind that I am building a file system by hand, basically adding libs and other things as I go, so that I only have a small handful of libs in /lib. The idea is to have the entire system functioning in under about 4 MB of data storage. I use ldd to show the libs that a particular app needs to run; apparently ldd is not 100% accurate. Anyway, I ran getpwnamroot on my target system; it failed. Unfortunately strace doesn't work on that system..... But I compiled it on my x86 box, and ran strace on it. It showed the following libs as required: open("/lib/tls/libc.so.6", O_RDONLY) = 3 open("/lib/tls/libnss_compat.so.2", O_RDONLY) = 3 open("/lib/tls/libnsl.so.1", O_RDONLY) = 3 open("/lib/tls/libnss_nis.so.2", O_RDONLY) = 3 open("/lib/tls/libnss_files.so.2", O_RDONLY) = 3 So I copied those libs to my /lib dir, and lo and behold, I can now log in via dropbear.... YAAAY! Thanks for all your help. --Yan From matt at ucc.asn.au Mon Oct 31 15:35:27 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 31 Oct 2005 15:35:27 +0800 Subject: Problem happen when putty trying to connect dropbear In-Reply-To: <3cf26ab60510260240w416943e2x@mail.gmail.com> References: <3cf26ab60510260240w416943e2x@mail.gmail.com> Message-ID: <20051031073527.GS6650@ucc.gu.uwa.edu.au> On Wed, Oct 26, 2005 at 05:40:30PM +0800, phr phr wrote: > Hi all, > When i trying to connect dropbear server, putty got this message. > "Server's host key did not match the signature supplied" > Does that mean, my dropbear host key is not correct??? That error tends to indicate that something has gone wrong with calculation of the signature by the server. Did the Dropbear server print anything interesting in the logs? Most likely if the key itself has problems, Dropbear won't even start. What sort of platform are you compiling on? It's plausible you could get that error if the crypto libraries are somehow producing incorrect output, though it's hard to guess what might be wrong without some more details (what sort of compiler, platform, libc, etc). Cheers, Matt From iamphr at gmail.com Mon Oct 31 20:00:03 2005 From: iamphr at gmail.com (phr phr) Date: Mon, 31 Oct 2005 20:00:03 +0800 Subject: Problem happen when putty trying to connect dropbear In-Reply-To: <20051031073527.GS6650@ucc.gu.uwa.edu.au> References: <3cf26ab60510260240w416943e2x@mail.gmail.com> <20051031073527.GS6650@ucc.gu.uwa.edu.au> Message-ID: <3cf26ab60510310400i46e70c01y@mail.gmail.com> I'm sorry i didn't say it in detail. dropbear version: 0.36 (it's really funny right ^^ ) uclinux-0.9.15 linux-2.4.x nonMMU putty 0.53b i don't have enough space to put dropbear server and key generator on my embeded system, so i put key generator first and generate a rsa key file, then rebuild another image just only have dropbear server and rsa key file. Here are the messages during login into dropbear server. ======================================== TRACE: enter loadhostkeys TRACE: enter buf_get_priv_key TRACE: enter rsa_key_free TRACE: leave rsa_key_free: key == NULL TRACE: enter buf_get_rsa_priv_key TRACE: enter buf_get_rsa_pub_key TRACE: leave buf_get_rsa_pub_key: success TRACE: leave buf_get_rsa_priv_key TRACE: leave buf_get_priv_key: done get rsa TRACE: leave loadhostkeys Jan 01 00:00:20 Not forking TRACE: Listen sockets TRACE: Accept TRACE: enter session_init TRACE: In kexinitialise TRACE: leave kexinitialise TRACE: enter chaninitialise TRACE: chaninitialise malloc done TRACE: chansessinitialise malloc TRACE: leave session_init TRACE: enter ident_readln TRACE: leave ident_readln: return 28 TRACE: remoteident: SSH-2.0-PuTTY-Release-0.53b TRACE: readrand TRACE: readrand end 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: top of select loop TRACE: select val = 1 TRACE: enter write_packet TRACE: empty queue dequeing TRACE: leave write_packet TRACE: top of select loop TRACE: select val = 1 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 = 20 TRACE: enter recv_msg_kexinit TRACE: leave recv_msg_kexinit TRACE: leave process_packet TRACE: top of select loop TRACE: select val = 1 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 = 3 TRACE: enter recv_msg_kexdh_init TRACE: enter send_msg_kexdh_reply TRACE: enter buf_put_pub_key TRACE: enter buf_put_rsa_pub_key TRACE: enter buf_putmpint TRACE: leave buf_putmpint TRACE: enter buf_putmpint TRACE: leave buf_putmpint TRACE: leave buf_put_rsa_pub_key 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 TRACE: enter buf_put_pub_key TRACE: enter buf_put_rsa_pub_key TRACE: enter buf_putmpint TRACE: leave buf_putmpint TRACE: enter buf_putmpint TRACE: leave buf_putmpint TRACE: leave buf_put_rsa_pub_key TRACE: leave buf_put_pub_key TRACE: enter buf_putmpint TRACE: leave buf_putmpint TRACE: enter buf_put_rsa_sign TRACE: leave buf_put_rsa_sign 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() TRACE: leave send_msg_kexdh_reply TRACE: enter 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: leave send_msg_newkeys TRACE: leave recv_msg_kexdh_init TRACE: leave process_packet TRACE: top of select loop TRACE: select val = 1 TRACE: enter write_packet TRACE: leave write_packet TRACE: top of select loop TRACE: select val = 1 TRACE: enter write_packet TRACE: empty queue dequeing TRACE: leave write_packet TRACE: top of select loop TRACE: select val = 1 TRACE: enter read_packet TRACE: enter session_cleanup TRACE: enter sign_key_free TRACE: enter rsa_key_free TRACE: leave rsa_key_free TRACE: leave sign_key_free TRACE: enter chancleanup TRACE: leave chancleanup TRACE: leave session_cleanup ======================================== Best Regards, 2005/10/31, Matt Johnston : > > On Wed, Oct 26, 2005 at 05:40:30PM +0800, phr phr wrote: > > Hi all, > > When i trying to connect dropbear server, putty got this message. > > "Server's host key did not match the signature supplied" > > Does that mean, my dropbear host key is not correct??? > > That error tends to indicate that something has gone wrong > with calculation of the signature by the server. Did the > Dropbear server print anything interesting in the logs? > Most likely if the key itself has problems, Dropbear won't > even start. > > What sort of platform are you compiling on? It's plausible > you could get that error if the crypto libraries are somehow > producing incorrect output, though it's hard to guess what > might be wrong without some more details (what sort of > compiler, platform, libc, etc). > > Cheers, > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20051031/11faa8e9/attachment.html From devin at freeshell.org Wed Nov 2 02:34:31 2005 From: devin at freeshell.org (Devin Bayer) Date: Tue, 01 Nov 2005 10:34:31 -0800 Subject: [PATCH] disable hostkey verification Message-ID: <4367B537.6020100@freeshell.org> Hello. This patch allows dbclient to be used non-interactivly without having to pipe a "y" character to it. It's very simple and also saves a few bytes for people interested in that sort of thing. This is against version 0.46. Thanks - Devin Bayer --- cli-kex-old.c 2005-11-01 09:13:43.000000000 -0800 +++ cli-kex.c 2005-11-01 10:25:57.000000000 -0800 @@ -38,8 +38,10 @@ #include "signkey.h" +#ifdef ENABLE_HOST_KEY_CHECKING static void checkhostkey(unsigned char* keyblob, unsigned int keybloblen); #define MAX_KNOWNHOSTS_LINE 4500 +#endif void send_msg_kexdh_init() { @@ -78,10 +80,12 @@ void recv_msg_kexdh_reply() { keybloblen = buf_getint(ses.payload); keyblob = buf_getptr(ses.payload, keybloblen); +#ifdef ENABLE_HOST_KEY_CHECKING if (!ses.kexstate.donefirstkex) { /* Only makes sense the first time */ checkhostkey(keyblob, keybloblen); } +#endif if (buf_get_pub_key(ses.payload, hostkey, &type) != DROPBEAR_SUCCESS) { TRACE(("failed getting pubkey")) @@ -112,6 +116,7 @@ void recv_msg_kexdh_reply() { TRACE(("leave recv_msg_kexdh_init")) } +#ifdef ENABLE_HOST_KEY_CHECKING static void ask_to_confirm(unsigned char* keyblob, unsigned int keybloblen) { char* fp = NULL; @@ -286,3 +291,4 @@ out: buf_free(line); } } +#endif --- options-old.h 2005-11-01 09:41:45.000000000 -0800 +++ options.h 2005-11-01 09:50:57.000000000 -0800 @@ -136,6 +136,9 @@ etc) slower (perhaps by 50%). Recommende * return the password on standard output */ /*#define ENABLE_CLI_ASKPASS_HELPER*/ +/* Are remote host keys checked? */ +#define ENABLE_HOST_KEY_CHECKING + /* Random device to use - define either DROPBEAR_RANDOM_DEV or * DROPBEAR_PRNGD_SOCKET. * DROPBEAR_RANDOM_DEV is recommended on hosts with a good /dev/(u)random, From devin at freeshell.org Sat Nov 5 08:05:32 2005 From: devin at freeshell.org (Devin Bayer) Date: Fri, 04 Nov 2005 16:05:32 -0800 Subject: [PATCH] new scp option: specify remote command Message-ID: <436BF74C.7020905@freeshell.org> This option allows me to use a remote command besides scp. Against version 0.46. Thanks, Devin Bayer --- scp.c.orig 2005-11-04 15:57:24.000000000 -0800 +++ scp.c 2005-11-04 15:55:52.000000000 -0800 @@ -120,6 +120,9 @@ int showprogress = 1; /* This is the program to execute for the secured connection. ("ssh" or -S) */ char *ssh_program = _PATH_SSH_PROGRAM; +/* This is the program to execute on the remote end. ("scp" or -w) */ +char *scp_program = "scp"; + /* This is used to store the pid of ssh_program */ pid_t do_cmd_pid = -1; @@ -288,6 +291,9 @@ main(int argc, char **argv) case 'S': ssh_program = xstrdup(optarg); break; + case 'w': + scp_program = xstrdup(optarg); + break; case 'v': addargs(&args, "-v"); verbose_mode = 1; @@ -350,7 +356,8 @@ main(int argc, char **argv) remin = remout = -1; do_cmd_pid = -1; /* Command to be executed on remote system using "ssh". */ - (void) snprintf(cmd, sizeof cmd, "scp%s%s%s%s", + (void) snprintf(cmd, sizeof cmd, "%s%s%s%s%s", + scp_program, verbose_mode ? " -v" : "", iamrecursive ? " -r" : "", pflag ? " -p" : "", targetshouldbedirectory ? " -d" : ""); @@ -1053,8 +1060,8 @@ usage(void) { (void) fprintf(stderr, "usage: scp [-pqrvBC1246] [-F config] [-S program] [-P port]\n" - " [-c cipher] [-i identity] [-l limit] [-o option]\n" - " [[user@]host1:]file1 [...] [[user@]host2:]file2\n"); + " [-c cipher] [-i identity] [-w remote prog] [-o option]\n" + " [-l limit] [[user@]host1:]file1... [[user@]host2:]file2\n"); exit(1); } From iamphr at gmail.com Tue Nov 8 11:17:10 2005 From: iamphr at gmail.com (phr phr) Date: Tue, 8 Nov 2005 11:17:10 +0800 Subject: Memory question on non-MMU system Message-ID: <3cf26ab60511071917w5078553ew@mail.gmail.com> Hi all, I can run dropbear 0.46 now, but i got some memory problem, dropbear server is getting bigger and bigger after someone login and logout. It seems that after logout dropbear server, memory can not be released. What should i do? What can i do? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20051108/0d24f5b5/attachment.htm From ari.hyttinen at ailocom.com Tue Nov 8 17:31:37 2005 From: ari.hyttinen at ailocom.com (Ari Hyttinen) Date: Tue, 08 Nov 2005 11:31:37 +0200 Subject: zlib compression with dbclient Message-ID: <43707079.8060406@ailocom.com> Only way I could get zlib compression to work with dbclient and OpenSSH sshd was to - either disable "none" compression completely or at least put it after "zlib" compression (in common-algo.c) *and* - set 'Compression Yes' in OpenSSH sshd_config. OpenSSH compression default is "delayed", ie to allow compression only after authentication, and if I left it to be default, then dbclient with "none" compression disabled could not connect at all (as expected). With both "zlib" and "none" (no matter the order in common-algo.c), dbclient would never switch to using zlib after authenticating with "none". I looked at trace log "enter buf_compress"/"leave buf_compress" messages to determine if compression was actually in use. So to use zlib compression with dbclient, I had to tweak both OpenSSH sshd_config *and* dropbear source. Am I missing something or is this simply an unimplemented feature? -- Ailocom Oy Ari Hyttinen mobile: +358-50-4040731 e-mail: ari.hyttinen at ailocom.com From mixonic at synitech.com Wed Nov 9 00:40:12 2005 From: mixonic at synitech.com (Matthew Beale) Date: Tue, 08 Nov 2005 11:40:12 -0500 Subject: stunnel? Message-ID: <1131468012.31332.6.camel@localhost> Hi all, I'm off-list so a CC would be great. Does dropbear also work as a stunnel? can I symlink stunnel to it and have it act the same (ala busybox)? I've got a light router with webmin, webmin expects stunnel-like functionality. Thanks for your time, -Matthew Beale mixonic at synitech.com :: 607 227 0871 From matt at ucc.asn.au Wed Nov 9 12:14:20 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 9 Nov 2005 12:14:20 +0800 Subject: stunnel? In-Reply-To: <1131468012.31332.6.camel@localhost> References: <1131468012.31332.6.camel@localhost> Message-ID: <20051109041420.GI16724@ucc.gu.uwa.edu.au> On Tue, Nov 08, 2005 at 11:40:12AM -0500, Matthew Beale wrote: > Hi all, I'm off-list so a CC would be great. > > Does dropbear also work as a stunnel? can I symlink stunnel to it and > have it act the same (ala busybox)? > > I've got a light router with webmin, webmin expects stunnel-like > functionality. Stunnel implements SSL which is quite different to SSH, so Dropbear can't work as stunnel. Cheers, Matt From mixonic at synitech.com Wed Nov 9 22:32:27 2005 From: mixonic at synitech.com (Matthew Beale) Date: Wed, 09 Nov 2005 09:32:27 -0500 Subject: stunnel? In-Reply-To: <20051109041420.GI16724@ucc.gu.uwa.edu.au> References: <1131468012.31332.6.camel@localhost> <20051109041420.GI16724@ucc.gu.uwa.edu.au> Message-ID: <1131546747.11385.1.camel@localhost> On Wed, 2005-11-09 at 12:14 +0800, Matt Johnston wrote: > On Tue, Nov 08, 2005 at 11:40:12AM -0500, Matthew Beale wrote: > > Hi all, I'm off-list so a CC would be great. > > > > Does dropbear also work as a stunnel? can I symlink stunnel to it and > > have it act the same (ala busybox)? > > > > I've got a light router with webmin, webmin expects stunnel-like > > functionality. > > Stunnel implements SSL which is quite different to > SSH, so Dropbear can't work as stunnel. Ah, geez, of course, sorry, musta been low on coffee yesterday. Thanks Matt :-p -Matt B > > Cheers, > Matt > From Aubrey.Li at analog.com Mon Nov 14 16:45:01 2005 From: Aubrey.Li at analog.com (Li, Aubrey) Date: Mon, 14 Nov 2005 03:45:01 -0500 Subject: Bad package length Message-ID: Hi all, After ported dropbear to my target board, I run dropbear in the INETD_MODE. I got the following error message when I ssh to my target board: - - - - - - - - ssh 192.168.0.15 Disconnecting: Bad packet length 1530147165. - - - - - - - - I did it by this way: 1) built dropbear on the host ./configure --disable-zlib --disable-wtmp --disable-openpty --disable-wtmpx --disable-syslog --disable-shadow --disable-lastlog --disable-utmp --disable-utmpx make 2) Create host key ./dropbearkey -t rsa -f dropbear_rsa_host_key ./dropbearkey -t dss -f dropbear_dss_host_key 3) Cross compile dropbear(I modified config.sub to support bfin-uclinux) LDFLAGS=-Wl,-elf2flt ./configure --host=bfin-uclinux --disable-zlib --disable-wtmp --disable-openpty --disable-wtmpx --disable-syslog --disable-shadow --disable-lastlog --disable-utmp --disable-utmpx 4) Make statically linked binary make STATIC=1 5) Copy dropbear_rsa_host_key and dropbear_dss_host_key to my target board under file system "/etc/dropbear". Copy dropbear to my target board under file system "/bin" Add one line to the inetd.conf on my target board: "ssh stream tcp nowait root /bin/dropbear -i" I run uclinux 2.6.12 on my target board. When the system start up, I ssh to the target board and got the error message. Thanks to help me out. -Aubrey From Aubrey.Li at analog.com Mon Nov 14 16:59:30 2005 From: Aubrey.Li at analog.com (Li, Aubrey) Date: Mon, 14 Nov 2005 03:59:30 -0500 Subject: Bad packet length message Message-ID: I paste the message ssh -v say: aubrey at linux:~/cvs/kernel/uClinux-dist> ssh -v root at 192.168.0.15 OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.0.15 [192.168.0.15] port 22. debug1: Connection established. debug1: identity file /home/aubrey/.ssh/identity type -1 debug1: identity file /home/aubrey/.ssh/id_rsa type -1 debug1: identity file /home/aubrey/.ssh/id_dsa type 2 debug1: ssh_exchange_identification: TRACE: enter loadhostkeys debug1: ssh_exchange_identification: TRACE: enter buf_get_priv_key debug1: ssh_exchange_identification: TRACE: enter rsa_key_free debug1: ssh_exchange_identification: TRACE: leave rsa_key_free: key == NULL debug1: ssh_exchange_identification: TRACE: enter buf_get_rsa_priv_key debug1: ssh_exchange_identification: TRACE: enter buf_get_rsa_pub_key debug1: ssh_exchange_identification: TRACE: leave buf_get_rsa_pub_key: success debug1: ssh_exchange_identification: TRACE: leave buf_get_rsa_priv_key debug1: ssh_exchange_identification: TRACE: leave buf_get_priv_key: done get rsa debug1: ssh_exchange_identification: TRACE: enter buf_get_priv_key debug1: ssh_exchange_identification: TRACE: enter dsa_key_free debug1: ssh_exchange_identification: TRACE: enter dsa_key_free: key == NULL debug1: ssh_exchange_identification: TRACE: leave buf_get_priv_key: done get dss debug1: ssh_exchange_identification: TRACE: leave loadhostkeys debug1: ssh_exchange_identification: [27] Aug 02 04:04:53 Child connection from 192.168.0.2:36546 debug1: ssh_exchange_identification: TRACE: enter session_init debug1: ssh_exchange_identification: TRACE: leave session_init debug1: Remote protocol version 2.0, remote software version dropbear_0.43 debug1: no match: dropbear_0.43 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug1: SSH2_MSG_KEXINIT sent Disconnecting: Bad packet length 1414676803. Thanks -Aubrey From matt at ucc.asn.au Mon Nov 14 17:05:34 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 14 Nov 2005 17:05:34 +0800 Subject: Bad package length In-Reply-To: References: Message-ID: <20051114090534.GG16724@ucc.gu.uwa.edu.au> On Mon, Nov 14, 2005 at 03:45:01AM -0500, Li, Aubrey wrote: > Hi all, > > After ported dropbear to my target board, I run dropbear in the > INETD_MODE. > I got the following error message when I ssh to my target board: > - - - - - - - - > ssh 192.168.0.15 > Disconnecting: Bad packet length 1530147165. > - - - - - - - - > ./configure --disable-zlib --disable-wtmp --disable-openpty > --disable-wtmpx --disable-syslog --disable-shadow --disable-lastlog > --disable-utmp --disable-utmpx > > "ssh stream tcp nowait root /bin/dropbear -i" This packet length is 5B34315D in hex, which corresponds to 0000000: 5b34 315d [41] That looks like the standard-error log output that Dropbear gives when syslog is disabled, like "[41] Nov 14 16:51:40 Not forking" etc. Some inetds do put standard-error out the network socket, and some don't - I'm not exactly sure what the expected behaviour should be (if anyone knows, could you share? :) So for your situation, the best bet is either (in vague order of preference): 1) Compile with syslog enabled (if no syslogd is running, it won't matter and nothing will get logged) or 2) Edit svr-session.c and comment out the line fprintf(stderr, "[%d] %s %s\n", getpid(), datestr, printbuf); or 3) Make a wrapper script that runs dropbear but redirects stderr somewhere else, ala dropbear -i 2> /dev/null Since stderr logging doesn't really make sense for inetd mode, I'll disable it in the next release. Let me know if that doesn't fix things. Cheers, Matt From matt at ucc.asn.au Mon Nov 14 17:07:22 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 14 Nov 2005 17:07:22 +0800 Subject: Bad package length In-Reply-To: <20051114090534.GG16724@ucc.gu.uwa.edu.au> References: <20051114090534.GG16724@ucc.gu.uwa.edu.au> Message-ID: <20051114090722.GH16724@ucc.gu.uwa.edu.au> On Mon, Nov 14, 2005 at 05:05:34PM +0800, Matt Johnston wrote: > On Mon, Nov 14, 2005 at 03:45:01AM -0500, Li, Aubrey wrote: > > Hi all, > > > > After ported dropbear to my target board, I run dropbear in the > > INETD_MODE. > > I got the following error message when I ssh to my target board: > > - - - - - - - - > > ssh 192.168.0.15 > > Disconnecting: Bad packet length 1530147165. > > - - - - - - - - > > ./configure --disable-zlib --disable-wtmp --disable-openpty > > --disable-wtmpx --disable-syslog --disable-shadow --disable-lastlog > > --disable-utmp --disable-utmpx > > > > "ssh stream tcp nowait root /bin/dropbear -i" > > This packet length is 5B34315D in hex, which corresponds to > > 0000000: 5b34 315d [41] > > That looks like the standard-error log output that Dropbear > gives when syslog is disabled, like > "[41] Nov 14 16:51:40 Not forking" etc. > > Some inetds do put standard-error out the network socket, > and some don't - I'm not exactly sure what the expected > behaviour should be (if anyone knows, could you share? :) Forgot to mention, Dropbear's TRACE mode is a bad idea if you're running with inetd for similar reasons, unless you use a wrapper script. (Just saw the other email) Matt > or > > 3) Make a wrapper script that runs dropbear but redirects > stderr somewhere else, ala > dropbear -i 2> /dev/null From Aubrey.Li at analog.com Mon Nov 14 17:25:47 2005 From: Aubrey.Li at analog.com (Li, Aubrey) Date: Mon, 14 Nov 2005 04:25:47 -0500 Subject: Bad package length Message-ID: Thanks for the reply. I followed your instruction, 1 or 3. But the issue remains. I paste the ssh -v saying: aubrey at linux:~/cvs/kernel/uClinux-dist> ssh -v root at 192.168.0.15 OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.0.15 [192.168.0.15] port 22. debug1: Connection established. debug1: identity file /home/aubrey/.ssh/identity type -1 debug1: identity file /home/aubrey/.ssh/id_rsa type -1 debug1: identity file /home/aubrey/.ssh/id_dsa type 2 debug1: ssh_exchange_identification: TRACE: enter loadhostkeys debug1: ssh_exchange_identification: TRACE: enter buf_get_priv_key debug1: ssh_exchange_identification: TRACE: enter rsa_key_free debug1: ssh_exchange_identification: TRACE: leave rsa_key_free: key == NULL debug1: ssh_exchange_identification: TRACE: enter buf_get_rsa_priv_key debug1: ssh_exchange_identification: TRACE: enter buf_get_rsa_pub_key debug1: ssh_exchange_identification: TRACE: leave buf_get_rsa_pub_key: success debug1: ssh_exchange_identification: TRACE: leave buf_get_rsa_priv_key debug1: ssh_exchange_identification: TRACE: leave buf_get_priv_key: done get rsa debug1: ssh_exchange_identification: TRACE: enter buf_get_priv_key debug1: ssh_exchange_identification: TRACE: enter dsa_key_free debug1: ssh_exchange_identification: TRACE: enter dsa_key_free: key == NULL debug1: ssh_exchange_identification: TRACE: leave buf_get_priv_key: done get dss debug1: ssh_exchange_identification: TRACE: leave loadhostkeys debug1: ssh_exchange_identification: [26] Aug 02 04:29:52 Child connection from 192.168.0.2:34014 debug1: ssh_exchange_identification: TRACE: enter session_init debug1: ssh_exchange_identification: TRACE: leave session_init debug1: Remote protocol version 2.0, remote software version dropbear_0.43 debug1: no match: dropbear_0.43 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug1: SSH2_MSG_KEXINIT sent Disconnecting: Bad packet length 1414676803. Regards -Aubrey From adyakov at mail.ru Thu Nov 17 20:06:46 2005 From: adyakov at mail.ru (=?koi8-r?Q?=F3=C1=DB=C1=20=E4=D8=D1=CB=CF=D7?=) Date: Thu, 17 Nov 2005 15:06:46 +0300 Subject: Putty format to Key converter Message-ID: I found out with Putty Key generator and found that the Dropbear can not convert Putty keys to its own format. So, OpenSSH keys can be converted only. It could be nice to add to dropbear converter Putty format also. And please describe why are you use your own format for keys? With what it connected? regards Dyakov Alex From adyakov at mail.ru Thu Nov 17 20:49:31 2005 From: adyakov at mail.ru (=?koi8-r?Q?=F3=C1=DB=C1=20=E4=D8=D1=CB=CF=D7?=) Date: Thu, 17 Nov 2005 15:49:31 +0300 Subject: Memory for buffer Message-ID: Please describe how much memory can be used for 8 simulteniously used SSH connections. I mean buffer (I have limitation by memory). regards Dyakov Alex From matt at ucc.asn.au Fri Nov 18 01:16:58 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 18 Nov 2005 01:16:58 +0800 Subject: Putty format to Key converter In-Reply-To: References: Message-ID: <20051117171658.GZ16724@ucc.gu.uwa.edu.au> On Thu, Nov 17, 2005 at 03:06:46PM +0300, ???? ?????? wrote: > I found out with Putty Key generator and found that the Dropbear can not convert Putty keys to its own format. So, OpenSSH keys can be converted only. It could be nice to add to dropbear converter Putty format also. > > And please describe why are you use your own format for keys? With what it connected? Dropbear uses a simple private key format that is close to what is used within the SSH protocol for transmitting public keys. I've got OpenSSH private key conversion support since people may have existing OpenSSH installs they want to replace with Dropbear (particularly for keeping host keys the same) - PuTTY is for a different platform, so that's not such a big issue. As far as I recall, PuTTY's key generator has a fairly easy way to get OpenSSH format public keys (which is what Dropbear uses natively) - that's what seems to be most common on Unix platforms (excluding ssh.com). You can use standard OpenSSH public keys for ~/.ssh/authorized_keys public key authentication. Matt From matt at ucc.asn.au Fri Nov 18 01:21:42 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 18 Nov 2005 01:21:42 +0800 Subject: Memory for buffer In-Reply-To: References: Message-ID: <20051117172142.GA16724@ucc.gu.uwa.edu.au> On Thu, Nov 17, 2005 at 03:49:31PM +0300, ???? ?????? wrote: > Please describe how much memory can be used for 8 simulteniously used SSH connections. I mean buffer (I have limitation by memory). Checking briefly on my openwrt install here, each connection seems to decrease the amount of free memory by ~250kB. The shell itself then uses around 90kB on top of that. That's on a MIPS type platform with uClibc and Linux 2.4.30, with AES encryption and md5 hmac. You should be able to get it lower by turning off some algorithms etc, though not sure by how much. Cheers, Matt From adyakov at mail.ru Tue Nov 22 20:01:59 2005 From: adyakov at mail.ru (=?koi8-r?Q?=F3=C1=DB=C1=20=E4=D8=D1=CB=CF=D7?=) Date: Tue, 22 Nov 2005 15:01:59 +0300 Subject: key Converter Message-ID: I have generate rsa and dss keys in Linux in that way: /usr/bin/ssh-keygen -q -t dsa -f dsa.key -C '' -N '' /usr/bin/ssh-keygen -q -t rsa -f rsa.key -C '' -N '' and then send them over e-mail. Then I have tried to convert these keys to Dropbear format but system said me: Error: File does not begin with OpenSSH key header Error reading key from '/ssh/rsa.key' Error: File does not begin with OpenSSH key header Error reading key from '/ssh/dsa.key' The problem is in '\n' symbol in keyimport.c file: line 385: 0 != strcmp(buffer+strlen(buffer)-17, "PRIVATE KEY-----\n")) { so in binary format symbol '\n' will be as "0D 0A", but in original format it is simple "0A". I have removed '\n' simbol from comparison. Regards Dyakov Alex From adyakov at mail.ru Thu Nov 24 22:23:52 2005 From: adyakov at mail.ru (=?koi8-r?Q?=F3=C1=DB=C1=20=E4=D8=D1=CB=CF=D7?=) Date: Thu, 24 Nov 2005 17:23:52 +0300 Subject: key Converter Message-ID: I think I found a little bug: in function dropbear_write() file keyimport.c ln 175 it would be better to add fclose (fp); line to close open file descriptor. Posibbly in Linux it is not a problem but in other OS I have got a file with 0 length. regards Dyakov Alex From matt at ucc.asn.au Wed Nov 30 14:32:46 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 30 Nov 2005 14:32:46 +0800 Subject: key Converter In-Reply-To: References: Message-ID: <20051130063246.GZ29695@ucc.gu.uwa.edu.au> On Thu, Nov 24, 2005 at 05:23:52PM +0300, ???? ?????? wrote: > I think I found a little bug: > in function dropbear_write() file keyimport.c ln 175 > it would be better to add > > fclose (fp); > > line to close open file descriptor. Posibbly in Linux it is not a problem but in other OS I have got a file with 0 length. Ah, I've added that now, thanks. Cheers, Matt From matthew at capgo.com Mon Dec 5 07:40:24 2005 From: matthew at capgo.com (Matthew Percival) Date: Mon, 05 Dec 2005 10:40:24 +1100 Subject: Hang on successful log in... Message-ID: <1133739624.8910.9.camel@localhost.localdomain> G'Day, I have Dropbear server (0.46) running on an embedded system, however, I have had trouble connecting to it. Things seem to be running normally most of the time, however, when I successfully log in (if I intentionally type the password wrong, the log in fails in the expected manner) everything simply hangs. I had assumed it was an entropy issue, so I recompiled with /dev/urandom selected, rather than /dev/random, in options.h, but the problem remains --- perhaps it still is an entropy issue, but I understand urandom should spit out any old garbage when it runs. I also checked to see if it were simply a long delay in the log in sequence, but after an hour or so there was still no change. If anyone can offer any advice to what the problem may be, it would be greatly appreciated. -- Matthew From matt at ucc.asn.au Tue Dec 6 00:40:36 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 6 Dec 2005 00:40:36 +0800 Subject: Hang on successful log in... In-Reply-To: <1133739624.8910.9.camel@localhost.localdomain> References: <1133739624.8910.9.camel@localhost.localdomain> Message-ID: <20051205164035.GG29695@ucc.gu.uwa.edu.au> On Mon, Dec 05, 2005 at 10:40:24AM +1100, Matthew Percival wrote: > G'Day, > > I have Dropbear server (0.46) running on an embedded system, however, I > have had trouble connecting to it. Things seem to be running normally > most of the time, however, when I successfully log in (if I > intentionally type the password wrong, the log in fails in the expected > manner) everything simply hangs. I had assumed it was an entropy issue, > so I recompiled with /dev/urandom selected, rather than /dev/random, in > options.h, but the problem remains --- perhaps it still is an entropy > issue, but I understand urandom should spit out any old garbage when it > runs. I also checked to see if it were simply a long delay in the log > in sequence, but after an hour or so there was still no change. > > If anyone can offer any advice to what the problem may be, it would be > greatly appreciated. My first suspicion would be terminal handling code. Could you try logging in without getting a PTY and shell, with something like ssh user at host "echo testing123" and seeing if you get output? dbclient and openssh both have a -T option which will disable the pty for an interactive session, you'll only get a response after sending a newline for each command. I assume there's nothing logged in /var/log/auth.log or similar? Let me know how that goes to try and debug it further. Cheers, Matt From matthew at capgo.com Tue Dec 6 06:39:14 2005 From: matthew at capgo.com (Matthew Percival) Date: Tue, 06 Dec 2005 09:39:14 +1100 Subject: Hang on successful log in... In-Reply-To: <20051205164035.GG29695@ucc.gu.uwa.edu.au> References: <1133739624.8910.9.camel@localhost.localdomain> <20051205164035.GG29695@ucc.gu.uwa.edu.au> Message-ID: <1133822354.8836.8.camel@localhost.localdomain> On Tue, 2005-12-06 at 00:40 +0800, Matt Johnston wrote: > On Mon, Dec 05, 2005 at 10:40:24AM +1100, Matthew Percival wrote: > > G'Day, > > > > I have Dropbear server (0.46) running on an embedded system, however, I > > have had trouble connecting to it. Things seem to be running normally > > most of the time, however, when I successfully log in (if I > > intentionally type the password wrong, the log in fails in the expected > > manner) everything simply hangs. I had assumed it was an entropy issue, > > so I recompiled with /dev/urandom selected, rather than /dev/random, in > > options.h, but the problem remains --- perhaps it still is an entropy > > issue, but I understand urandom should spit out any old garbage when it > > runs. I also checked to see if it were simply a long delay in the log > > in sequence, but after an hour or so there was still no change. > > > > If anyone can offer any advice to what the problem may be, it would be > > greatly appreciated. > > My first suspicion would be terminal handling code. Could > you try logging in without getting a PTY and shell, with > something like > ssh user at host "echo testing123" > and seeing if you get output? dbclient and openssh both have > a -T option which will disable the pty for an interactive > session, you'll only get a response after sending a newline for > each command. > > I assume there's nothing logged in /var/log/auth.log or > similar? > > Let me know how that goes to try and debug it further. > > Cheers, > Matt > G'Day, Thanks a lot for your response. It looks like you are on to something here too! I used the command as you suggested, and received `testing123' on the screen before ssh exited gracefully. There is no logging, as you have assumed. The session was as follows: $ ssh -T sysadmin at 10.0.0.13 "echo testing123" sysadmin at 10.0.0.13's password: testing123 $ -- Matthew From matt at ucc.asn.au Sun Dec 11 23:30:02 2005 From: matt at ucc.asn.au (Matt Johnston) Date: Sun, 11 Dec 2005 23:30:02 +0800 Subject: Dropbear 0.47 (and security fix) Message-ID: <20051211153002.GH28839@ucc.gu.uwa.edu.au> Hi all. I've put up a new release 0.47 of Dropbear, which has various fixes and new features - see the change summary below. http://matt.ucc.asn.au/dropbear/dropbear.html is the url as usual or directly at http://matt.ucc.asn.au/dropbear/dropbear-0.47.tar.bz2 This release also fixes a potential security issue, which may allow authenticated users to run arbitrary code as the server user. I'm unsure exactly how likely it is to be exploitable, but anyone who's running a multi-user server is advised to upgrade. For older releases, the patch is: (against chanesssion.c for 0.43 and earlier). --- svr-chansession.c +++ svr-chansession.c @@ -810,7 +810,7 @@ /* need to increase size */ if (i == svr_ses.childpidsize) { svr_ses.childpids = (struct ChildPid*)m_realloc(svr_ses.childpids, - sizeof(struct ChildPid) * svr_ses.childpidsize+1); + sizeof(struct ChildPid) * (svr_ses.childpidsize+1)); svr_ses.childpidsize++; } Matt 0.47 - Thurs Dec 8 2005 - SECURITY: fix for buffer allocation error in server code, could potentially allow authenticated users to gain elevated privileges. All multi-user systems running the server should upgrade (or apply the patch available on the Dropbear webpage). - Fix channel handling code so that redirecting to /dev/null doesn't use 100% CPU. - Turn on zlib compression for dbclient. - Set "low delay" TOS bit, can significantly improve interactivity over some links. - Added client keyboard-interactive mode support, allows operation with newer OpenSSH servers in default config. - Log when pubkey auth fails because of bad ~/.ssh/authorized_keys permissions - Improve logging of assertions - Added aes-256 cipher and sha1-96 hmac. - Fix twofish so that it actually works. - Improve PAM prompt comparison. - Added -g (dbclient) and -a (dropbear server) options to allow connections to listening forwarded ports from remote machines. - Various other minor fixes - Compile fixes for glibc 2.1 (ss_family vs __ss_family) and NetBSD (netinet/in_systm.h needs to be included).