From david at harktech.com Thu Apr 6 11:45:10 2006 From: david at harktech.com (David George) Date: Wed, 05 Apr 2006 23:45:10 -0400 Subject: Port Forwarding in background? Message-ID: <44348EC6.7060303@harktech.com> Using dbclient 0.48.1 on the client attempting to forward a local port to dropbear server 0.48.1 on another machine, how do I get the client to go into the background? I have read the messages in the list archives re: port forwarding and tunnelling and didn't find anything that applies. I am using dbclient -L 20001:localhost:10001 root at 10.100.1.101. It does work, but it actually logs into the remote server and I am presented with a shell. If I telnet localhost 20001 I am connected to the remote server on port 10001, so it is working. If I use OpenSSH on another machine I can ssh -N -f -L 20001:localhost:10001 root at 10.100.1.101 and it will go into the background and the port forwarding also works. But I really need the dbclient port forwarding to run in the background. I did try putting it into background with &, but I can't get the public key authentication to work. I did a dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key -y on the server and copied the public key part to ~/.ssh/authorized_keys, but it still asks for password. I tried dbclient -i ~/.ssh/authorized_keys root at 10.100.1.101 and it returns dbclient: exited: string too long. I also tried running the dropbear server with -a in case that was the problem, but it wasn't. Any help would be appreciated. Thanks. -- David From matt at ucc.asn.au Thu Apr 6 13:06:53 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 6 Apr 2006 13:06:53 +0800 Subject: Port Forwarding in background? In-Reply-To: <44348EC6.7060303@harktech.com> References: <44348EC6.7060303@harktech.com> Message-ID: <20060406050653.GK30413@ucc.gu.uwa.edu.au> On Wed, Apr 05, 2006 at 11:45:10PM -0400, David George wrote: > Using dbclient 0.48.1 on the client attempting to forward a local port > to dropbear server 0.48.1 on another machine, how do I get the client to > go into the background? I have read the messages in the list archives > re: port forwarding and tunnelling and didn't find anything that applies. > > I am using dbclient -L 20001:localhost:10001 root at 10.100.1.101. It does > work, but it actually logs into the remote server and I am presented > with a shell. If I telnet localhost 20001 I am connected to the remote > server on port 10001, so it is working. If I use OpenSSH on another > machine I can ssh -N -f -L 20001:localhost:10001 root at 10.100.1.101 and > it will go into the background and the port forwarding also works. I'll look at adding this as a feature in a future release, it should bfairly straightforward. Running dbclient with a -T option (disabling ttys) and & at the end seems to work for now (as long as you have a public key). Alternatively, you should be able to run with -T but without the &, enter your password, then ctrl-z, "bg". > But I really need the dbclient port forwarding to run in the > background. I did try putting it into background with &, but I can't > get the public key authentication to work. I did a dropbearkey -t rsa > -f /etc/dropbear/dropbear_rsa_host_key -y on the server and copied the > public key part to ~/.ssh/authorized_keys, but it still asks for > password. I tried dbclient -i ~/.ssh/authorized_keys root at 10.100.1.101 > and it returns dbclient: exited: string too long. The host key (used by the server) and the client auth key (used by dbclient) are different things. Generate a key with dropbearkey -t rsa -f ~/.ssh/dbkey.rsa on the machine where you run dbclient, then paste the public key line to ~root/.ssh/authorized_keys on the server (10.100.1.101). Run dbclient -T -i ~/.ssh/dbkey.rsa -L 20001:localhost:10001 root at 10.100.1.101 & and it should work - let me know if it doesn't. Cheers, Matt From david at harktech.com Thu Apr 6 22:36:28 2006 From: david at harktech.com (David George) Date: Thu, 06 Apr 2006 10:36:28 -0400 Subject: Port Forwarding in background? In-Reply-To: <20060406050653.GK30413@ucc.gu.uwa.edu.au> References: <44348EC6.7060303@harktech.com> <20060406050653.GK30413@ucc.gu.uwa.edu.au> Message-ID: <4435276C.1090503@harktech.com> On 4/6/2006 1:06 AM, Matt Johnston wrote: >On Wed, Apr 05, 2006 at 11:45:10PM -0400, David George wrote: > > >>Using dbclient 0.48.1 on the client attempting to forward a local port >>to dropbear server 0.48.1 on another machine, how do I get the client to >>go into the background? >> >I'll look at adding this as a feature in a future release, >it should bfairly straightforward. Running dbclient with >a -T option (disabling ttys) and & at the end seems to work >for now (as long as you have a public key). Alternatively, >you should be able to run with -T but without the &, enter >your password, then ctrl-z, "bg". > > > >Generate a key with > >dropbearkey -t rsa -f ~/.ssh/dbkey.rsa > >on the machine where you run dbclient, then paste the public >key line to ~root/.ssh/authorized_keys on the server >(10.100.1.101). > >Run > >dbclient -T -i ~/.ssh/dbkey.rsa -L 20001:localhost:10001 root at 10.100.1.101 & > >and it should work - let me know if it doesn't. > > I had tried the -T before and got "-sh: cannot open not a tty: No such file". I just tried it and got the same thing. Now that I am doing the public key correctly (thanks) I am able to do the following and it works: dbclient -T -i ~/.ssh/dbkey.rsa -L 20001:localhost:10001 root at 10.100.1.101 >/dev/null 2>&1 & Thank you very much for your help and your very quick response. -- David From swen at vnet.ibm.com Mon Apr 10 16:25:27 2006 From: swen at vnet.ibm.com (Swen Schillig) Date: Mon, 10 Apr 2006 10:25:27 +0200 Subject: PidFile switch Message-ID: <200604100826.k3A8QAnv006897@d06av03.portsmouth.uk.ibm.com> Hi all I want to use the dropbear package in a project but I'm missing a functionality which allows me to provide the pidfile name on the cmd-line. I've created a diff which would provide this functionality and I'd like to get some feedback on this patch. Especially if it's going to be part of the next code-drop. I've posted this diff already to Matt but unfortunately haven't received any feedback so far. Anywy, here it is and let me know what you think ! Only in dropbear-0.48.1-dev: Makefile Only in dropbear-0.48.1-dev: config.h Only in dropbear-0.48.1-dev: config.log Only in dropbear-0.48.1-dev: config.status Only in dropbear-0.48.1-dev/libtomcrypt: Makefile Only in dropbear-0.48.1-dev/libtommath: Makefile diff -aur dropbear-0.48.1/runopts.h dropbear-0.48.1-dev/runopts.h --- dropbear-0.48.1/runopts.h 2006-03-12 05:52:51.000000000 +0100 +++ dropbear-0.48.1-dev/runopts.h 2006-03-21 19:27:05.000000000 +0100 @@ -83,6 +83,7 @@ sign_key *hostkey; buffer * banner; + char * pidfile; } svr_runopts; diff -aur dropbear-0.48.1/svr-main.c dropbear-0.48.1-dev/svr-main.c --- dropbear-0.48.1/svr-main.c 2006-03-12 05:52:52.000000000 +0100 +++ dropbear-0.48.1-dev/svr-main.c 2006-03-21 19:44:37.000000000 +0100 @@ -145,7 +145,7 @@ } /* create a PID file so that we can be killed easily */ - pidfile = fopen(DROPBEAR_PIDFILE, "w"); + pidfile = fopen(svr_opts.pidfile, "w"); if (pidfile) { fprintf(pidfile, "%d\n", getpid()); fclose(pidfile); @@ -188,7 +188,7 @@ val = select(maxsock+1, &fds, NULL, NULL, &seltimeout); if (exitflag) { - unlink(DROPBEAR_PIDFILE); + unlink(svr_opts.pidfile); dropbear_exit("Terminated by signal"); } diff -aur dropbear-0.48.1/svr-runopts.c dropbear-0.48.1-dev/svr-runopts.c --- dropbear-0.48.1/svr-runopts.c 2006-03-12 05:52:52.000000000 +0100 +++ dropbear-0.48.1-dev/svr-runopts.c 2006-03-21 19:40:09.000000000 +0100 @@ -72,6 +72,8 @@ #endif "-p port Listen on specified tcp port, up to %d can be specified\n" " (default %s if none specified)\n" + "-P PidFile Create pid file PidFile\n" + " (default %s)\n" #ifdef INETD_MODE "-i Start for inetd\n" #endif @@ -85,7 +87,7 @@ #ifdef DROPBEAR_RSA RSA_PRIV_FILENAME, #endif - DROPBEAR_MAX_PORTS, DROPBEAR_DEFPORT); + DROPBEAR_MAX_PORTS, DROPBEAR_DEFPORT, DROPBEAR_PIDFILE); } void svr_getopts(int argc, char ** argv) { @@ -105,6 +107,7 @@ svr_opts.inetdmode = 0; svr_opts.portcount = 0; svr_opts.hostkey = NULL; + svr_opts.pidfile = DROPBEAR_PIDFILE; #ifdef ENABLE_SVR_LOCALTCPFWD svr_opts.nolocaltcp = 0; #endif @@ -185,6 +188,9 @@ svr_opts.portcount++; } break; + case 'P': + next = &svr_opts.pidfile; + break; #ifdef DO_MOTD /* motd is displayed by default, -m turns it off */ case 'm': From matt at ucc.asn.au Wed Apr 12 00:02:39 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 12 Apr 2006 00:02:39 +0800 Subject: PidFile switch In-Reply-To: <200604100826.k3A8QAnv006897@d06av03.portsmouth.uk.ibm.com> References: <200604100826.k3A8QAnv006897@d06av03.portsmouth.uk.ibm.com> Message-ID: <20060411160239.GJ22639@ucc.gu.uwa.edu.au> On Mon, Apr 10, 2006 at 10:25:27AM +0200, Swen Schillig wrote: > Hi all > > I want to use the dropbear package in a project > but I'm missing a functionality which allows me to > provide the pidfile name on the cmd-line. > > I've created a diff which would provide this functionality > and I'd like to get some feedback on this patch. > Especially if it's going to be part of the next code-drop. > Anywy, here it is and let me know what you think ! The patch itself looks fine from a quick look over, though I'm curious of your need to specify a filename at runtime. I've generally been reluctant to add options that work fine as compile-time settings, though if there's a good reason for setting it at runtime, I'll add it. Cheers, Matt From swen at vnet.ibm.com Wed Apr 12 20:20:16 2006 From: swen at vnet.ibm.com (Swen Schillig) Date: Wed, 12 Apr 2006 14:20:16 +0200 Subject: PidFile switch In-Reply-To: <20060411160239.GJ22639@ucc.gu.uwa.edu.au> References: <200604100826.k3A8QAnv006897@d06av03.portsmouth.uk.ibm.com> <20060411160239.GJ22639@ucc.gu.uwa.edu.au> Message-ID: <200604121220.k3CCKxfw025998@d12av01.megacenter.de.ibm.com> On Wed, 12 Apr 2006 00:02:39 +0800 Matt Johnston wrote: > On Mon, Apr 10, 2006 at 10:25:27AM +0200, Swen Schillig wrote: > > Hi all > > > > I want to use the dropbear package in a project > > but I'm missing a functionality which allows me to > > provide the pidfile name on the cmd-line. > > > > I've created a diff which would provide this functionality > > and I'd like to get some feedback on this patch. > > Especially if it's going to be part of the next code-drop. > > > Anywy, here it is and let me know what you think ! > > The patch itself looks fine from a quick look over, though > I'm curious of your need to specify a filename at runtime. > I've generally been reluctant to add options that work fine > as compile-time settings, though if there's a good reason for > setting it at runtime, I'll add it. > > Cheers, > Matt > We're using dropbear in an environment where we can start a couple of server instances (on different ports) each providing individual user-interfaces on client connection. If I do that with the current version the one and only pidfile gets replaced by the last server started, meaning I'm losing a way to track which server is running under which PID. The easiest way for me was to have a pidfile which has the port-number included in the name and therefor have a direct connection between port# and PID. E.g.: /tmp/dropbear.2222 I really hope this make sense to you, if not let me know. From pedro.aguilar at visionee.com Wed Apr 19 20:57:27 2006 From: pedro.aguilar at visionee.com (Pedro Aguilar) Date: Wed, 19 Apr 2006 14:57:27 +0200 Subject: Problem when connecting from client openssh to server dropbear Message-ID: <1145451448.2554.22.camel@lab01> Hi, I installed dropbear 0.48.1 in a MIPS AU1550 without problems. I can execute the server normally with -s -g options because there is only the root user: $ dropbear -E -s -g When I try to connect from a desktop using openssh I have a publickey problem. Desktop: $ ssh root at 192.168.1.30 Permission denied (publickey). $ The logs in the server (the MIPS) are: # [126] Jan 01 02:05:30 Child connection from 192.168.1.31:35944 [126] Jan 01 02:05:31 exit before auth: Exited normally I generated the keys in the server with $ dropbear -t rsa -f /etc/dropbear/dropbear_rsa_host_key $ dropbear -t dss -f /etc/dropbear/dropbear_dss_host_key The dir /etc/dropbear has permissions 700 and the key files 600 Is there something that I'm missing? Could you give me any ideas for solving this issue? Thanks! Pedro From matt at ucc.asn.au Wed Apr 19 21:04:02 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 19 Apr 2006 21:04:02 +0800 Subject: Problem when connecting from client openssh to server dropbear In-Reply-To: <1145451448.2554.22.camel@lab01> References: <1145451448.2554.22.camel@lab01> Message-ID: <20060419130402.GX23259@ucc.gu.uwa.edu.au> On Wed, Apr 19, 2006 at 02:57:27PM +0200, Pedro Aguilar wrote: > Hi, > > I installed dropbear 0.48.1 in a MIPS AU1550 without problems. I can > execute the server normally with -s -g options because there is only the > root user: > $ dropbear -E -s -g > > When I try to connect from a desktop using openssh I have a publickey > problem. > > Desktop: > $ ssh root at 192.168.1.30 > Permission denied (publickey). > $ > > The logs in the server (the MIPS) are: > # [126] Jan 01 02:05:30 Child connection from 192.168.1.31:35944 > [126] Jan 01 02:05:31 exit before auth: Exited normally > > I generated the keys in the server with > $ dropbear -t rsa -f /etc/dropbear/dropbear_rsa_host_key > $ dropbear -t dss -f /etc/dropbear/dropbear_dss_host_key Those are the server's own keys that it uses to identify itself to the client. I assume you've already got a ~/.ssh/id_rsa or ~/.ssh/id_dsa on the desktop computer? You have to put the .pub public key portion of that key in /root/.ssh/authorized_keys on the server, with correct permissions. (Paths may vary depending on the user setup). Dropbear exits straight away because it won't allow a password with -s -g, and there's no public key it can check. Cheers, Matt From tmassey at obscorp.com Fri Apr 21 04:33:45 2006 From: tmassey at obscorp.com (tmassey@obscorp.com) Date: Thu, 20 Apr 2006 16:33:45 -0400 Subject: Port forwarding control options Message-ID: Hello! I'm looking at using Dropbear to encapsulate non-encrypted protocol traffic (like SMTP). I would like to limit users' ability to port forwarding to specific hosts and ports. I have a couple of questions: 1) Does Dropbear support this? I know that the Dropbear website says: "Compatible with OpenSSH ~/.ssh/authorized_keys public key authentication". But does that mean that it actually obeys "permitopen" information? 2) Is there a more centralized way of controlling this, preferably server-wide? I would love to be able to limit the entire SSH server to forward to only the specific ports on the specific hosts that I want to access, and use the ~/.ssh/authorized_keys file to define, if necessary, a *subset* of those ports on a per-user basis. I've thought about using Shorewall/iptables to do the centralized port/host control, but that seems like a fair bit of a hassle, when all I want to do is limit *Dropbear*, not the entire system... I'm surprised that this seems to be such an undocumented area of limiting SSH's power. Giving users the ability to port forward to *any* host and *any* port from the outside seems to be significantly dangerous. What am I missing? Thank you very much for your thoughts. I appreciate your help. Tim Massey From matt at ucc.asn.au Sun Apr 23 00:14:19 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sun, 23 Apr 2006 00:14:19 +0800 Subject: Port forwarding control options In-Reply-To: References: Message-ID: <20060422161419.GQ23259@ucc.gu.uwa.edu.au> On Thu, Apr 20, 2006 at 04:33:45PM -0400, tmassey at obscorp.com wrote: > Hello! > > I'm looking at using Dropbear to encapsulate non-encrypted protocol > traffic (like SMTP). I would like to limit users' ability to port > forwarding to specific hosts and ports. I have a couple of questions: > > 1) Does Dropbear support this? I know that the Dropbear website says: > "Compatible with OpenSSH ~/.ssh/authorized_keys public key > authentication". But does that mean that it actually obeys "permitopen" > information? Nope, if keys have any restrictions on them, then Dropbear won't allow those keys to be used. I intend to implement some of OpenSSH's restriction functionality eventually. > 2) Is there a more centralized way of controlling this, preferably > server-wide? I would love to be able to limit the entire SSH server to > forward to only the specific ports on the specific hosts that I want to > access, and use the ~/.ssh/authorized_keys file to define, if necessary, a > *subset* of those ports on a per-user basis. Currently there isn't support for that. It probably wouldn't be too hard to set up a config file that is loaded and then compared for each TCP forwarding request. I don't have time to implement it at the moment though. > I'm surprised that this seems to be such an undocumented area of limiting > SSH's power. Giving users the ability to port forward to *any* host and > *any* port from the outside seems to be significantly dangerous. What am > I missing? The general case is that users have the ability to run arbitrary programs on the host anyway, so port forwarding isn't such a great concern. Cheers, Matt From seven at 7labs.de Sat May 13 06:44:07 2006 From: seven at 7labs.de (Sebastian Haag) Date: Sat, 13 May 2006 00:44:07 +0200 Subject: "premature exit: string too long" Message-ID: <200605130044.07984.seven@7labs.de> Hi, I?m using dropbear 0.48.1 and have a little problem with the public/private keys. I generated the public and private keys with dropbearkey and copied the public key to "/etc/dropbear/dropbear_rsa_host_key" (on the SERVER, where 'dropbear' is running/should run). This file is readable and writeable only to user root. The content is: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwChT3x47P43i1yc5KrUodYJYlKl7efDqt9x6fF/doazGT3t3hcC/rBpKzIqRUFFrER54rIMnt4ngPQ1J0NsOlpg4sRnIV5V4D4kFDinBZax5Fg4vUJQ2vh2LBioXTRDYr5gaDQfMS7X6pXJ5NiDTE5k8GddBiRPR/INm1scSo/q0qZz (without any linebreaks or anything else) Do I have to append username at host or anything else? When i want to start dropbear (with 'dropbear'), i get the following message: "premature exit: string too long". I think i missunderstood something essential in public-key-authentication. Is there a howto where to put which key when using dropbear? I found something like that: "To create a new RSA key to store in /.ssh/id_rsa.db, you can use the following command: dropbearkey -t rsa -f ~/.ssh/id\_rsa.db The public key part of the new key will be printed to the screen. You can put it into the /.ssh/authorized_keys file on all machines where you want to be able to login using your new private key stored in /.ssh/id_rsa.db" But that doesn?t work either... Thanks in advance for your help Sebastian From matt at ucc.asn.au Sat May 13 12:42:40 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 13 May 2006 12:42:40 +0800 Subject: "premature exit: string too long" In-Reply-To: <200605130044.07984.seven@7labs.de> References: <200605130044.07984.seven@7labs.de> Message-ID: <20060513044240.GO2851@ucc.gu.uwa.edu.au> On Sat, May 13, 2006 at 12:44:07AM +0200, Sebastian Haag wrote: > Hi, > > I?m using dropbear 0.48.1 and have a little problem with the public/private > keys. > > I generated the public and private keys with dropbearkey and copied the public > key to "/etc/dropbear/dropbear_rsa_host_key" (on the SERVER, where 'dropbear' > is running/should run). This file is readable and writeable only to user > root. > When i want to start dropbear (with 'dropbear'), i get the following message: > "premature exit: string too long". The /etc/dropbear/dropbear_rsa_host_key file is the server's _private_ key, used for all sessions (even password authed) so that the client knows that it's talking to the same server each time. This is independent of using public keys for user auth. If you generate a key using dropbearkey and copy the private key part to dropbear_rsa_host_key, it should work fine. If you then want to use public key authentication, on the client you have to generate a key, then paste the public part into ~/.ssh/authorized_keys on the server. If you're using dbclient then you'd generate it with dropbearkey and specify it with "dbclient -i ~/.ssh/id_rsa.db", otherwise you'd use the client-specific key generator - dbclient for OpenSSH, PuTTYgen for putty, etc. Cheers, Matt From seven at 7labs.de Sun May 14 22:06:59 2006 From: seven at 7labs.de (Sebastian Haag) Date: Sun, 14 May 2006 16:06:59 +0200 Subject: "premature exit: string too long" In-Reply-To: <20060513044240.GO2851@ucc.gu.uwa.edu.au> References: <200605130044.07984.seven@7labs.de> <20060513044240.GO2851@ucc.gu.uwa.edu.au> Message-ID: <200605141606.59580.seven@7labs.de> Thank you very much for your help. Sorry, but I didn?t get it running... now I get "no auth methods could be used". When I start dbclient with option "-i", it says "Ignoring unknown argument...". My system/what i did: server (dropbear) -> 192.168.0.20: + dropbear started as root (dropbear -v -F -r /etc/dropbear/dropbear_rsa_host_key) [see trace (1)] + -rw------- 1 root root 427 ... dropbear_rsa_host_key + /root/.ssh/authorized_keys contains public key of client: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwCG ... 7ITwqih9hTB9ItPfgtggvclIVlMzVJ= root at 192.168.0.23 It doesn?t make any difference if I append user at host or not. + -rw------- 1 root root 232 ... authorized_keys client (dbclient) -> 192.168.0.23 + generated new keys on client + private key in id_rsa.db / public key appended to authorized_keys on the server + under user root: dbclient -v -l root 192.168.0.20 [see trace (2)] (+ 'dbclient -i id_rsa.db -v -l root 192.168.0.20' results in WARNING: Ignoring unknown argument `-i`) + on serverside i get the appended trace (3) I don?t know whats wrong, but could it be that this problem occurs cause I compiled dropbear and dbclient statically against uclibc? (btw I use the original version of options.h). When I call 'make LDFLAGS="-static" PROGRAMS=dropbear dbclient', compilation fails: cli-auth.c: In function `recv_msg_userauth_specific_60': cli-auth.c:109: error: `cli_ses' undeclared (first use in this function) cli-auth.c:109: error: (Each undeclared identifier is reported only once cli-auth.c:109: error: for each function it appears in.) cli-auth.c: In function `recv_msg_userauth_failure': cli-auth.c:147: error: `cli_ses' undeclared (first use in this function) cli-auth.c: In function `recv_msg_userauth_success': cli-auth.c:233: error: `cli_ses' undeclared (first use in this function) cli-auth.c: In function `cli_auth_try': cli-auth.c:249: error: `cli_ses' undeclared (first use in this function) make: *** [cli-auth.o] Fehler 1 Compiling them apart works well (PROGRAMS=dropbear or PROGRAMS=dbclient). Sorry, this mail became really long... greetings Sebastian -------------------------------------------------------------------------------------------------------------- (1) Trace dropbear prompt # dropbear -v -F -r /etc/dropbear/dropbear_rsa_host_key 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 TRACE: leave loadhostkeys [15632] May 14 12:51:07 Not forking TRACE: listensockets: 1 to try TRACE: listening on '22' TRACE: enter dropbear_listen TRACE: dropbear_listen: all interfaces TRACE: bind(22) failed TRACE: leave dropbear_listen: success, 1 socks bound -------------------------------------------------------------------------------------------------------------- (2) Trace dbclient prompt# ./dbclient -v -l root 192.168.0.20 TRACE: non-flag arg: '192.168.0.20' TRACE: user='root' host='192.168.0.20' port='22' TRACE: enter connect_remote TRACE: leave connect_remote: sock 3 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.48 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 TRACE: enter write_packet TRACE: empty queue dequeing TRACE: leave write_packet TRACE: enter read_packet TRACE: enter decrypt_packet TRACE: leave decrypt_packet TRACE: leave read_packet TRACE: enter process_packet TRACE: process_packet: packet type = 20 TRACE: <- KEXINIT TRACE: enter recv_msg_kexinit TRACE: cli_buf_match_algo: diffie-hellman-group1-sha1 TRACE: kex algo diffie-hellman-group1-sha1 TRACE: cli_buf_match_algo: ssh-rsa TRACE: hostkey algo ssh-rsa TRACE: cli_buf_match_algo: aes128-cbc,3des-cbc,aes256-cbc TRACE: enc c2s is aes128-cbc TRACE: cli_buf_match_algo: aes128-cbc,3des-cbc,aes256-cbc TRACE: enc s2c is aes128-cbc TRACE: cli_buf_match_algo: hmac-sha1-96,hmac-sha1 TRACE: hash c2s is hmac-sha1-96 TRACE: cli_buf_match_algo: hmac-sha1-96,hmac-sha1 TRACE: hash s2c is hmac-sha1-96 TRACE: cli_buf_match_algo: none TRACE: hash c2s is none TRACE: cli_buf_match_algo: none TRACE: hash s2c is none TRACE: leave recv_msg_kexinit TRACE: leave process_packet TRACE: enter cli_sessionloop TRACE: enter send_msg_kexdh_reply TRACE: enter buf_putmpint TRACE: leave buf_putmpint TRACE: enter encrypt_packet() TRACE: encrypt_packet type is 30 TRACE: enter writemac TRACE: leave writemac TRACE: enter enqueue TRACE: leave enqueue TRACE: leave encrypt_packet() TRACE: leave cli_sessionloop: done with KEXINIT_RCVD TRACE: enter write_packet TRACE: empty queue dequeing TRACE: leave write_packet TRACE: enter cli_sessionloop TRACE: leave cli_sessionloop: kex_state != KEX_NOTHING 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 = 31 TRACE: enter recv_msg_kexdh_reply TRACE: type is 1 TRACE: enter buf_getline TRACE: leave buf_getline: success TRACE: hosts don't match TRACE: enter buf_getline TRACE: leave buf_getline: success TRACE: checkpubkey: base64_decode success TRACE: good matching key TRACE: enter buf_get_pub_key TRACE: enter rsa_key_free TRACE: leave rsa_key_free: key == NULL TRACE: enter buf_get_rsa_pub_key TRACE: leave buf_get_rsa_pub_key: success TRACE: leave buf_get_pub_key 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_verify TRACE: enter buf_rsa_verify TRACE: success! TRACE: leave buf_rsa_verify: ret 0 TRACE: enter sign_key_free TRACE: enter rsa_key_free TRACE: leave rsa_key_free TRACE: leave sign_key_free 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: SENTNEWKEYS=1 TRACE: -> MSG_NEWKEYS TRACE: leave send_msg_newkeys TRACE: leave recv_msg_kexdh_init TRACE: leave process_packet TRACE: enter cli_sessionloop TRACE: leave cli_sessionloop: kex_state != KEX_NOTHING TRACE: enter write_packet TRACE: empty queue dequeing TRACE: leave write_packet TRACE: enter read_packet TRACE: enter decrypt_packet TRACE: leave decrypt_packet TRACE: leave read_packet TRACE: enter process_packet TRACE: process_packet: packet type = 21 TRACE: <- MSG_NEWKEYS TRACE: enter recv_msg_newkeys TRACE: while SENTNEWKEYS=1 TRACE: enter gen_new_keys TRACE: enter buf_putmpint TRACE: leave buf_putmpint TRACE: leave gen_new_keys TRACE: kexinitialise() TRACE: -> DATAALLOWED=1 TRACE: leave recv_msg_newkeys TRACE: leave process_packet TRACE: enter cli_sessionloop TRACE: enter send_msg_service_request: servicename='ssh-userauth' TRACE: enter encrypt_packet() TRACE: encrypt_packet type is 5 TRACE: enter writemac TRACE: leave writemac TRACE: enter enqueue TRACE: leave enqueue TRACE: leave encrypt_packet() TRACE: leave send_msg_service_request TRACE: leave cli_sessionloop: sent userauth service req TRACE: enter write_packet TRACE: empty queue dequeing TRACE: leave write_packet TRACE: enter cli_sessionloop TRACE: leave cli_sessionloop: fell out 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 = 6 TRACE: enter recv_msg_service_accept TRACE: leave recv_msg_service_accept: done ssh-userauth TRACE: leave process_packet TRACE: enter cli_sessionloop TRACE: enter cli_auth_getmethods TRACE: enter encrypt_packet() TRACE: encrypt_packet type is 50 TRACE: enter writemac TRACE: leave writemac TRACE: enter enqueue TRACE: leave enqueue TRACE: leave encrypt_packet() TRACE: leave cli_auth_getmethods TRACE: leave cli_sessionloop: sent userauth methods req TRACE: enter write_packet TRACE: empty queue dequeing TRACE: leave write_packet TRACE: enter cli_sessionloop TRACE: leave cli_sessionloop: fell out 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 = 51 TRACE: <- MSG_USERAUTH_FAILURE TRACE: enter recv_msg_userauth_failure TRACE: Methods (len 9): 'publickey' TRACE: auth method 'publickey' TRACE: leave recv_msg_userauth_failure TRACE: leave process_packet TRACE: enter cli_sessionloop TRACE: enter cli_auth_try TRACE: cli_auth_try lastauthtype 1 TRACE: enter cli_tty_cleanup TRACE: leave cli_tty_cleanup: not in raw mode TRACE: enter session_cleanup TRACE: enter chancleanup TRACE: leave chancleanup TRACE: leave session_cleanup ./dbclient: connection to root at 192.168.0.20:22 exited: No auth methods could be used. -------------------------------------------------------------------------------------------------------------- (3) Trace serverside after executing dbclient (excerpt) ... 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 2, '' TRACE: leave send_msg_userauth_failure TRACE: leave process_packet TRACE: enter write_packet TRACE: empty queue dequeing TRACE: leave write_packet TRACE: enter read_packet [16168] May 14 13:06:46 exit before auth: Exited normally ... Am Samstag, 13. Mai 2006 06:42 schrieben Sie: > > The /etc/dropbear/dropbear_rsa_host_key file is the server's > _private_ key, used for all sessions (even password authed) > so that the client knows that it's talking to the same > server each time. This is independent of using public keys for > user auth. If you generate a key using dropbearkey and copy > the private key part to dropbear_rsa_host_key, it should > work fine. > > If you then want to use public key authentication, on the > client you have to generate a key, then paste the public > part into ~/.ssh/authorized_keys on the server. If you're > using dbclient then you'd generate it with dropbearkey and > specify it with "dbclient -i ~/.ssh/id_rsa.db", otherwise > you'd use the client-specific key generator - dbclient for > OpenSSH, PuTTYgen for putty, etc. > > Cheers, > Matt From matt at ucc.asn.au Sun May 14 23:10:13 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sun, 14 May 2006 23:10:13 +0800 Subject: "premature exit: string too long" In-Reply-To: <200605141606.59580.seven@7labs.de> References: <200605130044.07984.seven@7labs.de> <20060513044240.GO2851@ucc.gu.uwa.edu.au> <200605141606.59580.seven@7labs.de> Message-ID: <20060514151013.GP2851@ucc.gu.uwa.edu.au> On Sun, May 14, 2006 at 04:06:59PM +0200, Sebastian Haag wrote: > Thank you very much for your help. > > Sorry, but I didn?t get it running... now I get "no auth methods could be > used". When I start dbclient with option "-i", it says "Ignoring unknown > argument...". > I don?t know whats wrong, but could it be that this problem occurs cause I > compiled dropbear and dbclient statically against uclibc? (btw I use the > original version of options.h). dbclient not recognising the -i option (and the server not allowing password auth) really sounds like a modified options.h. Perhaps "make clean", ensure it's the standard options.h, then make it again? Let me know how that goes, if that doesn't help we can debug it further. Matt From seven at 7labs.de Mon May 15 00:04:05 2006 From: seven at 7labs.de (Sebastian Haag) Date: Sun, 14 May 2006 18:04:05 +0200 Subject: "premature exit: string too long" In-Reply-To: <20060514151013.GP2851@ucc.gu.uwa.edu.au> References: <200605130044.07984.seven@7labs.de> <200605141606.59580.seven@7labs.de> <20060514151013.GP2851@ucc.gu.uwa.edu.au> Message-ID: <200605141804.05313.seven@7labs.de> so, I downloaded a fresh copy of dropbear, compiled it and ... you were right! I dont?t know how but I guess I mixed up my options.h-files. thank you very much for your time and your useful hints. Sebastian Am Sonntag, 14. Mai 2006 17:10 schrieb Matt Johnston: > On Sun, May 14, 2006 at 04:06:59PM +0200, Sebastian Haag wrote: > > Thank you very much for your help. > > > > Sorry, but I didn?t get it running... now I get "no auth methods could be > > used". When I start dbclient with option "-i", it says "Ignoring unknown > > argument...". > > > > I don?t know whats wrong, but could it be that this problem occurs cause > > I compiled dropbear and dbclient statically against uclibc? (btw I use > > the original version of options.h). > > dbclient not recognising the -i option (and the server not > allowing password auth) really sounds like a modified > options.h. Perhaps "make clean", ensure it's the standard > options.h, then make it again? > > Let me know how that goes, if that doesn't help we can debug > it further. > > Matt From Sebastian at 7labs.de Tue May 16 21:34:15 2006 From: Sebastian at 7labs.de (Sebastian Haag) Date: Tue, 16 May 2006 15:34:15 +0200 Subject: exit after auth (root): couldn't change user as non-root Message-ID: <20060516153415.pt92wvx2ig8ok0ws@webmail.7labs.de> Hi, next problem: I?m using pubkey auth which works fine. But after auth I get the following message on the client: "exit after auth (root): couldn't change user as non-root". dbclient and dropbear are startet by user "root". dropbear runs in an embedded system, emulated by qemu. I testet the whole thing on 2 "real" machines (running suse linux) and it worked. So I guess something?s wrong with my rootfilesystem on the emulated embedded system. E.g. there is no command 'su'... When and why does the prog try to change the user? And why isn?t that operation performed as 'root' (server and client are both started as 'root')? Probably I made a mistake in my user configuration (on the server), so I appended the files below: /etc/passwd root:x:0:0:root:/root:/bin/sh httpd:x:1001:1001:webuser:/usr/httpd:/bin/sh /etc/group root:x:0: httpd:x:1001: Got someone else this message before? cheers, Sebastian From seven at 7labs.de Wed May 17 04:36:51 2006 From: seven at 7labs.de (Sebastian Haag) Date: Tue, 16 May 2006 22:36:51 +0200 Subject: exit after auth (root): couldn't change user as non-root In-Reply-To: <20060516153357.GU2851@ucc.gu.uwa.edu.au> References: <20060516153415.pt92wvx2ig8ok0ws@webmail.7labs.de> <20060516153357.GU2851@ucc.gu.uwa.edu.au> Message-ID: <200605162236.51886.seven@7labs.de> Am Dienstag, 16. Mai 2006 17:33 schrieb Matt Johnston: > That's quite strange. The code in question is: > > if (getuid() == 0) { > if ((setgid(ses.authstate.pw->pw_gid) < 0) || > (initgroups(ses.authstate.pw->pw_name, > ses.authstate.pw->pw_gid) < 0)) { > dropbear_exit("error changing user group"); > } > if (setuid(ses.authstate.pw->pw_uid) < 0) { > dropbear_exit("error changing user"); > } > } else { > if (getuid() != ses.authstate.pw->pw_uid) { > dropbear_exit("couldn't change user as non-root"); > } > } > > so getuid() must not be 0, ie it's not root. That doesn't > depend on the config files at all as far as I know - it's > asking it straight from the kernel. > > You could change the exit message to > dropbear_exit("couldn't change user as non-root user %d", getuid()); > and see what it prints - perhaps the emulated environment > can't emulate root? > > Matt I changed the exit message and got as return value -1. Thats funny cause getuid() shouldn?t return error codes... ;-) So I checked my kernel config and found under "General setup" the option "Enable 16 bit UID calls", activated it and getuid() now works properly. Thanks a lot Sebastian From rob at landley.net Fri May 19 03:35:31 2006 From: rob at landley.net (Rob Landley) Date: Thu, 18 May 2006 15:35:31 -0400 Subject: exit after auth (root): couldn't change user as non-root In-Reply-To: <200605162236.51886.seven@7labs.de> References: <20060516153415.pt92wvx2ig8ok0ws@webmail.7labs.de> <20060516153357.GU2851@ucc.gu.uwa.edu.au> <200605162236.51886.seven@7labs.de> Message-ID: <200605181535.31852.rob@landley.net> On Tuesday 16 May 2006 4:36 pm, Sebastian Haag wrote: > I changed the exit message and got as return value -1. Thats funny cause > getuid() shouldn?t return error codes... ;-) > > So I checked my kernel config and found under "General setup" the option > "Enable 16 bit UID calls", activated it and getuid() now works properly. Upgrade your uClibc. I believe the current one (0.9.28) doesn't make obsolete syscalls anymore. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Fri May 19 03:35:31 2006 From: rob at landley.net (Rob Landley) Date: Thu, 18 May 2006 15:35:31 -0400 Subject: exit after auth (root): couldn't change user as non-root In-Reply-To: <200605162236.51886.seven@7labs.de> References: <20060516153415.pt92wvx2ig8ok0ws@webmail.7labs.de> <20060516153357.GU2851@ucc.gu.uwa.edu.au> <200605162236.51886.seven@7labs.de> Message-ID: <200605181535.31852.rob@landley.net> On Tuesday 16 May 2006 4:36 pm, Sebastian Haag wrote: > I changed the exit message and got as return value -1. Thats funny cause > getuid() shouldn?t return error codes... ;-) > > So I checked my kernel config and found under "General setup" the option > "Enable 16 bit UID calls", activated it and getuid() now works properly. Upgrade your uClibc. I believe the current one (0.9.28) doesn't make obsolete syscalls anymore. Rob -- Never bet against the cheap plastic solution. From rich at storix.com Sat Jun 17 00:02:50 2006 From: rich at storix.com (Rich Turner) Date: Fri, 16 Jun 2006 09:02:50 -0700 Subject: Limit concurrent connections Message-ID: <200606160902.50878.rich@storix.com> I have looked through options.h and could not find where I could define the total number of concurrent client connections that are allowed to be connected to the dropbear server. I would like to limit the number of authorized connections to 1. Is this possible? I do see in options.h the ability to limit the number unauthorized clients, but nothing to limit the number of authorized clients. -- Rich Turner Storix, Inc. 619-543-0200 x113 From matt at ucc.asn.au Sat Jun 17 00:21:27 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 17 Jun 2006 00:21:27 +0800 Subject: Limit concurrent connections In-Reply-To: <200606160902.50878.rich@storix.com> References: <200606160902.50878.rich@storix.com> Message-ID: <20060616162127.GQ12898@ucc.gu.uwa.edu.au> On Fri, Jun 16, 2006 at 09:02:50AM -0700, Rich Turner wrote: > I have looked through options.h and could not find where I could define the > total number of concurrent client connections that are allowed to be > connected to the dropbear server. I would like to limit the number of > authorized connections to 1. Is this possible? > > I do see in options.h the ability to limit the number unauthorized clients, > but nothing to limit the number of authorized clients. There isn't a setting for this by default. You can achieve it by setting MAX_UNAUTH_CLIENTS 1, then commenting out the "m_close(svr_ses.childpipe)" call near the bottom of svr-auth.c. It seems to work here, you might want to test it a bit though. Let me know how it goes. Cheers, Matt From rich at storix.com Sat Jun 17 00:52:05 2006 From: rich at storix.com (Rich Turner) Date: Fri, 16 Jun 2006 09:52:05 -0700 Subject: Limit concurrent connections In-Reply-To: <20060616162127.GQ12898@ucc.gu.uwa.edu.au> References: <200606160902.50878.rich@storix.com> <20060616162127.GQ12898@ucc.gu.uwa.edu.au> Message-ID: <200606160952.05714.rich@storix.com> This seems to be working just fine. Thanks for the help. I must admit I am not that verse with C programming. Can you tell me what I just did by commenting out "m_close(svr_ses.childpipe)" in svr-auth.c. I would like to know what I did so that if something odd happens I may be able to relate it to the change I made. Also, the error message that I receive when a second client attempts to connect is "dbclient: connection to root at rich-laptop:22 exited: Failed to get remote version". I would prefer that the error message indicate that I have exceeded the maximum number of concurrent connections. I have found in common.session.c where I can change the text, but I do not want to change it if this would be a valid error for another reason other than maximum connections exceeding. Under what circumstances would I get this error? On Friday 16 June 2006 09:21, Matt Johnston wrote: > On Fri, Jun 16, 2006 at 09:02:50AM -0700, Rich Turner wrote: > > I have looked through options.h and could not find where I could define > > the total number of concurrent client connections that are allowed to be > > connected to the dropbear server. I would like to limit the number of > > authorized connections to 1. Is this possible? > > > > I do see in options.h the ability to limit the number unauthorized > > clients, but nothing to limit the number of authorized clients. > > There isn't a setting for this by default. You can achieve > it by setting MAX_UNAUTH_CLIENTS 1, then commenting out the > "m_close(svr_ses.childpipe)" call near the bottom of > svr-auth.c. It seems to work here, you might want to test it > a bit though. Let me know how it goes. > > Cheers, > Matt From matt at ucc.asn.au Sat Jun 17 01:10:56 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 17 Jun 2006 01:10:56 +0800 Subject: Limit concurrent connections In-Reply-To: <200606160952.05714.rich@storix.com> References: <200606160902.50878.rich@storix.com> <20060616162127.GQ12898@ucc.gu.uwa.edu.au> <200606160952.05714.rich@storix.com> Message-ID: <20060616171056.GT12898@ucc.gu.uwa.edu.au> On Fri, Jun 16, 2006 at 09:52:05AM -0700, Rich Turner wrote: > This seems to be working just fine. Thanks for the help. > > I must admit I am not that verse with C programming. Can you tell me what I > just did by commenting out "m_close(svr_ses.childpipe)" in svr-auth.c. I > would like to know what I did so that if something odd happens I may be able > to relate it to the change I made. Whenever the listening Dropbear process accepts a new incoming connection, it forks off a separate child process to handle it. A pipe is kept open between the listening process and the child process, which is used to indicate whether authentication has occurred. When the child session has been authenticated, it closes the pipe and the main listener can then keep count of how many unauthenticated sessions exist at a point in time. By commenting out that line, the listening process won't ever recognise the process as "authenticated", except until the child session exits and the pipe is closed. It will apply the "unauthenticated connection limit" to all processes regardless of their state. Past that limit it will simply close connections immediately. > Also, the error message that I receive when a second client attempts to > connect is "dbclient: connection to root at rich-laptop:22 exited: Failed to get > remote version". I would prefer that the error message indicate that I have > exceeded the maximum number of concurrent connections. I have found in > common.session.c where I can change the text, but I do not want to change it > if this would be a valid error for another reason other than maximum > connections exceeding. Under what circumstances would I get this error? The current error message is somewhat misleading. It basically happens any time there's a connection failure in the earliest part of the session setup. In this case, the server is closing the connection immediately (since that's most appropriate for closing pre-auth connections). Something like "Remote host closed the connection" is probably more appropriate. To send a specific "connection limit exceeded" type message the server would have to send a more useful disconnect message, though Dropbear is currently a bit lacking in that area - it's on the todo list. Matt From wcm at guinix.com Sat Jun 17 03:19:13 2006 From: wcm at guinix.com (Wayne Marshall) Date: 16 Jun 2006 12:19:13 -0700 Subject: Limit concurrent connections In-Reply-To: <200606160902.50878.rich@storix.com> References: <200606160902.50878.rich@storix.com> Message-ID: <20060616121913.36838233@alloy.copperisle.com> On Fri, 16 Jun 2006 09:02:50 -0700 Rich Turner wrote: > I have looked through options.h and could not find where I could > define the total number of concurrent client connections that are > allowed to be connected to the dropbear server. I would like to limit > the number of authorized connections to 1. Is this possible? > It is also possible to run dropbear under supervision with an external listener that enables connection limits. Such utilities include daemontools + ucspi-tcp and runit + ipsvd. Here is a run script snippet that I use: exec \ chpst \ -m 10000000 \ tcpsvd -vv \ -c $CONLIMIT \ -C $CONPER \ -l 0 \ -x iprules.cdb \ $IP $PORT \ $DROPBEAR -d $DB_DSS_KEY -r $DB_RSA_KEY -i -E -g Here $CONLIMIT may be defined to limit the total number of concurrent connections, and $CONPER may be defined to limit the total number of concurrent connections per IP address. Wayne From larry.brigman at gmail.com Thu Jun 22 07:44:37 2006 From: larry.brigman at gmail.com (Larry Brigman) Date: Wed, 21 Jun 2006 16:44:37 -0700 Subject: devices and permissions Message-ID: I am trying to build a simple system with dropbear installed but I cannot seem to get it to allow connections. I believe it has something to do with the kernel config or devices. I have busybox running with telnetd working. Any help? From rob at landley.net Fri Jun 23 01:04:10 2006 From: rob at landley.net (Rob Landley) Date: Thu, 22 Jun 2006 13:04:10 -0400 Subject: devices and permissions In-Reply-To: References: Message-ID: <200606221304.10606.rob@landley.net> On Wednesday 21 June 2006 7:44 pm, Larry Brigman wrote: > I am trying to build a simple system with dropbear installed but > I cannot seem to get it to allow connections. > > I believe it has something to do with the kernel config or devices. > > I have busybox running with telnetd working. > > Any help? I find "dropbear -F -E" to be generally helpful. Tells you what it's doing, and why, right there on stderr... Try getting it working via loopback on the same machine first. Rob -- Never bet against the cheap plastic solution. From larry.brigman at gmail.com Fri Jun 23 02:03:54 2006 From: larry.brigman at gmail.com (Larry Brigman) Date: Thu, 22 Jun 2006 11:03:54 -0700 Subject: devices and permissions In-Reply-To: <200606221304.10606.rob@landley.net> References: <200606221304.10606.rob@landley.net> Message-ID: On 6/22/06, Rob Landley wrote: > On Wednesday 21 June 2006 7:44 pm, Larry Brigman wrote: > > I am trying to build a simple system with dropbear installed but > > I cannot seem to get it to allow connections. > > > > I believe it has something to do with the kernel config or devices. > > > > I have busybox running with telnetd working. > > > > Any help? > > I find "dropbear -F -E" to be generally helpful. Tells you what it's doing, > and why, right there on stderr... > > Try getting it working via loopback on the same machine first. > libnss_files: symbol: _nss_files_parse_pwent GLIBC_PRIVATE not defined in libc.so.6 It looks like mklibs got me or is that dropbear not linking to all the libs explicitly such that the elf file header doesn't have the right libs. I guess if I had used ulibc this would not be an issue. Is there a way to have dropbear use something like that of busybox for password access to remove this dependency or is that asking too much? From floydpink at gmail.com Fri Jun 23 02:09:48 2006 From: floydpink at gmail.com (Jason Schoon) Date: Thu, 22 Jun 2006 13:09:48 -0500 Subject: devices and permissions In-Reply-To: References: <200606221304.10606.rob@landley.net> Message-ID: <78a54e1b0606221109i1480534cm4676212fe8e48524@mail.gmail.com> On 6/22/06, Larry Brigman wrote: > > On 6/22/06, Rob Landley wrote: > > On Wednesday 21 June 2006 7:44 pm, Larry Brigman wrote: > > > I am trying to build a simple system with dropbear installed but > > > I cannot seem to get it to allow connections. > > > > > > I believe it has something to do with the kernel config or devices. > > > > > > I have busybox running with telnetd working. > > > > > > Any help? > > > > I find "dropbear -F -E" to be generally helpful. Tells you what it's > doing, > > and why, right there on stderr... > > > > Try getting it working via loopback on the same machine first. > > > libnss_files: symbol: _nss_files_parse_pwent GLIBC_PRIVATE not defined > in libc.so.6 > > It looks like mklibs got me or is that dropbear not linking to all the > libs explicitly such > that the elf file header doesn't have the right libs. > > I guess if I had used ulibc this would not be an issue. > > Is there a way to have dropbear use something like that of busybox for > password > access to remove this dependency or is that asking too much? Nope, this is a glibc thing. If you are using glibc, even if you statically link your application, you need libnss present on the system. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060622/2772c0f8/attachment.htm From rich at storix.com Fri Jun 23 05:39:20 2006 From: rich at storix.com (Rich Turner) Date: Thu, 22 Jun 2006 14:39:20 -0700 Subject: dbclient execute command Message-ID: <200606221439.20670.rich@storix.com> does dbclient have the ability to run a command on the remote dropbear server? something like this: # dbclient -i /tmp/privkey mylaptop /bin/program i know with openssh client it accepts an argument to run a command on the remote system and i was hoping dbclient could do the same. From matt at ucc.asn.au Fri Jun 23 09:17:40 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 23 Jun 2006 09:17:40 +0800 Subject: dbclient execute command In-Reply-To: <200606221439.20670.rich@storix.com> References: <200606221439.20670.rich@storix.com> Message-ID: <20060623011740.GV12898@ucc.gu.uwa.edu.au> On Thu, Jun 22, 2006 at 02:39:20PM -0700, Rich Turner wrote: > does dbclient have the ability to run a command on the remote dropbear server? > something like this: > # dbclient -i /tmp/privkey mylaptop /bin/program > > i know with openssh client it accepts an argument to run a command on the > remote system and i was hoping dbclient could do the same. Yep, that should work, the help text is just a bit misleading. Matt From martin.jaeschke at gmail.com Sun Jun 25 01:33:06 2006 From: martin.jaeschke at gmail.com (Martin Jaeschke) Date: Sat, 24 Jun 2006 19:33:06 +0200 Subject: Dropbear- argument Message-ID: <000001c697b4$432b81b0$03011eac@c00> Hello, i start the dropbearclient with the following arguments: ssh user at server this server is using passwort-auth not key-auth. So i have to use the key-auth. It is possible to use an argument like '-pw password'? Is it possible to send the password with an argument, so that i dont need to enter manually the password? Greetings Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060624/6c82e8d7/attachment.html From rob at landley.net Sun Jun 25 06:23:27 2006 From: rob at landley.net (Rob Landley) Date: Sat, 24 Jun 2006 18:23:27 -0400 Subject: Dropbear- argument In-Reply-To: <000001c697b4$432b81b0$03011eac@c00> References: <000001c697b4$432b81b0$03011eac@c00> Message-ID: <200606241823.27765.rob@landley.net> On Saturday 24 June 2006 1:33 pm, Martin Jaeschke wrote: > It is possible to use an argument like '-pw password'? Then your password would be viewable to all users in "ps". This is generally considered a bad thing. The key authentication mechanism (.ssh/authorized_keys) was developed so you wouldn't have to provide a password by hand. Rob -- Never bet against the cheap plastic solution. From cthomas at Soneticom.com Fri Jun 30 05:07:22 2006 From: cthomas at Soneticom.com (Clint Thomas) Date: Thu, 29 Jun 2006 17:07:22 -0400 Subject: Dropbear or SSH on Busybox Message-ID: <3C02138692C13C4BB675FE7EA24095291327F6@bluefin.Soneticom.local> Hey, I am running a dev board based around the 8555E powerpc processor, running an embedded version of linux with glibc version 2.2.3, kernel 2.4.27, and busybox version .52. I am trying to figure out if there is any way to setup SSH on this machine without updating the glibc libraries, the kernel or busybox. The telnet server is having a hard time connnecting, and I would much rather be using SSH to remote connect into this machine. Is there any way for dropbear to run without glibc version 2.3 or higher? Perhaps an older version ? Clint -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060629/afe1e702/attachment.htm From rob at landley.net Fri Jun 30 08:30:22 2006 From: rob at landley.net (Rob Landley) Date: Thu, 29 Jun 2006 20:30:22 -0400 Subject: Dropbear or SSH on Busybox In-Reply-To: <3C02138692C13C4BB675FE7EA24095291327F6@bluefin.Soneticom.local> References: <3C02138692C13C4BB675FE7EA24095291327F6@bluefin.Soneticom.local> Message-ID: <200606292030.22275.rob@landley.net> On Thursday 29 June 2006 5:07 pm, Clint Thomas wrote: > Hey, > > I am running a dev board based around the 8555E powerpc processor, > running an embedded version of linux with glibc version 2.2.3, kernel > 2.4.27, and busybox version .52. I am trying to figure out if there is > any way to setup SSH on this machine without updating the glibc > libraries, the kernel or busybox. The telnet server is having a hard > time connnecting, and I would much rather be using SSH to remote connect > into this machine. Is there any way for dropbear to run without glibc > version 2.3 or higher? Perhaps an older version ? A) You don't have to update busybox. It's unrelated. B) What error do you get when you try to build it against the old glibc? C) You could always statically link it against a current uClibc. Rob -- Never bet against the cheap plastic solution.