Hi, It sounds like you have a symlink from /usr/bin/scp to a non-multi dbclient binary, instead of a symlink to the dropbearmulti binary?
Cheers, Matt On Mon, Apr 09, 2012 at 11:16:15AM -0400, Ian McDonnell wrote: > Matt, > > Thanks for a quick reply. I have two traces from the client side, > one talking to my old target running dropbear 0.50 and another > trace talking to dropbear 0.55 target. In both cases, the openssh > client appears not to be using the 'subsystem' mechanism and > is simply directing the server-end to exec rcp. > > So, how does this work? On my old 0.50 server I don't have > an /usr/bin/rcp binary, nor /usr/libexec/sftp-server, and yet > the remote copy works. Dropbear server must be catching the > exec 'rcp' somewhere and doing something special. > > On my newer 0.55 target, I linked the dropbearmulti binary to > /usr/bin/rcp, and this appears to be being exec'd by the > dropbear server; the client tells it to run "rcp -v -t -- filename". > This is where it hiccups; the rcp invocation runs as an rcp > client, not a remote rcp-protocol server, so uses the 'filename' > argument is a target hostname, thus the host lookup "Error Resolving..." > error message. > > Below are the two openssh (rcp) client debug traces: > > -Ian > > Same client interacting with dropbear 0.50 server: > > > 0.55: think$ scp -vvv Makefile tsct:junk > > 0.55: Executing: program /usr/bin/ssh host tsct, user (unspecified), > > command scp -v -t -- junk > > 0.55: OpenSSH_5.6p1, OpenSSL 1.0.0g-fips 18 Jan 2012 > > 0.55: debug1: Reading configuration data /home/imcd/.ssh/config > > 0.55: debug1: Applying options for tsct > > 0.55: debug1: Reading configuration data /etc/ssh/ssh_config > > 0.55: debug1: Applying options for * > > 0.55: debug2: ssh_connect: needpriv 0 > > 0.55: debug1: Connecting to 192.0.1.13 [192.0.1.13] port 22. > > 0.55: debug1: Connection established. > <snip> > > 0.55: debug1: Next authentication method: password > > 0.55: [email protected]'s password: > > 0.55: debug3: packet_send2: adding 64 (len 52 padlen 12 extra_pad 64) > > 0.55: debug2: we sent a password packet, wait for reply > > 0.55: debug1: Authentication succeeded (password). > > 0.55: Authenticated to 192.0.1.13 ([192.0.1.13]:22). > > 0.55: debug2: fd 4 setting O_NONBLOCK > > 0.55: debug2: fd 5 setting O_NONBLOCK > > 0.55: debug1: channel 0: new [client-session] > > 0.55: debug3: ssh_session2_open: channel_new: 0 > > 0.55: debug2: channel 0: send open > > 0.55: debug1: Entering interactive session. > > 0.55: debug2: callback start > > 0.55: debug2: client_session2_setup: id 0 > > 0.55: debug1: Sending environment. > > 0.55: debug3: Ignored env SSH_AGENT_PID > <snip> more env... > > 0.55: debug3: Ignored env OLDPWD > > 0.55: debug1: Sending command: scp -v -t -- junk > > 0.55: debug2: channel 0: request exec confirm 1 > > 0.55: debug2: fd 3 setting TCP_NODELAY > > 0.55: debug2: callback done > > 0.55: debug2: channel 0: open confirm rwindow 24576 rmax 32768 > > 0.55: debug2: channel_input_status_confirm: type 99 id 0 > > 0.55: debug2: exec request accepted on channel 0 > > 0.55: debug2: channel 0: rcvd ext data 80 > > 0.55: WARNING: Ignoring unknown argument '-v' > > 0.55: WARNING: Ignoring unknown argument '--' > > 0.55: debug2: channel 0: written 80 to efd 6 > > 0.55: debug2: channel 0: rcvd ext data 73 > > 0.55: scp: exited: Error resolving 'junk' port '22'. Name or service not > > known > > 0.55: debug2: channel 0: written 73 to efd 6 > > 0.55: debug2: channel 0: rcvd eof > > 0.55: debug2: channel 0: output open -> drain > > 0.55: debug2: channel 0: obuf empty > > 0.55: debug2: channel 0: close_write > > 0.55: debug2: channel 0: output drain -> closed > > 0.55: debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > > Same client command but with dropbear 0.50 server: > > > 0.50: think$ scp -vvv Makefile tsct-050:junk > > 0.50: Executing: program /usr/bin/ssh host tsct-050, user (unspecified), > > command scp -v -t -- junk > > 0.50: OpenSSH_5.6p1, OpenSSL 1.0.0g-fips 18 Jan 2012 > > 0.50: debug1: Reading configuration data /home/imcd/.ssh/config > > 0.50: debug1: Applying options for tsct-050 > > 0.50: debug1: Host '192.0.1.14' is known and matches the RSA host key. > > 0.50: debug1: Found key in /home/imcd/.ssh/known_hosts:17 > <snip> > > 0.50: debug3: remaining preferred: ,password > > 0.50: debug3: authmethod_is_enabled password > > 0.50: debug1: Next authentication method: password > > 0.50: [email protected]'s password: > > 0.50: debug3: packet_send2: adding 64 (len 52 padlen 12 extra_pad 64) > > 0.50: debug2: we sent a password packet, wait for reply > > 0.50: debug1: Authentication succeeded (password). > > 0.50: Authenticated to 192.0.1.14 ([192.0.1.14]:22). > > 0.50: debug2: fd 4 setting O_NONBLOCK > > 0.50: debug2: fd 5 setting O_NONBLOCK > > 0.50: debug1: channel 0: new [client-session] > > 0.50: debug3: ssh_session2_open: channel_new: 0 > > 0.50: debug2: channel 0: send open > > 0.50: debug1: Entering interactive session. > > 0.50: debug2: callback start > > 0.50: debug2: client_session2_setup: id 0 > > 0.50: debug1: Sending environment. > > 0.50: debug3: Ignored env SSH_AGENT_PID > <snip> more env... > > 0.50: debug3: Ignored env OLDPWD > > 0.50: debug1: Sending command: scp -v -t -- junk > > 0.50: debug2: channel 0: request exec confirm 1 > > 0.50: debug2: fd 3 setting TCP_NODELAY > > 0.50: debug2: callback done > > 0.50: debug2: channel 0: open confirm rwindow 24576 rmax 32768 > > 0.50: debug2: channel_input_status_confirm: type 99 id 0 > > 0.50: debug2: exec request accepted on channel 0 > > 0.50: Sending file modes: C0644 3026 Makefile > > 0.50: debug2: channel 0: rcvd ext data 26 > > 0.50: Sink: C0644 3026 Makefile > > 0.50: debug2: channel 0: written 26 to efd 6 > > 0.50: Makefile 100% 3026 3.0KB/s 00:00 > > 0.50: debug2: channel 0: read<=0 rfd 4 len 0 > > 0.50: debug2: channel 0: read failed > > 0.50: debug2: channel 0: close_read > > 0.50: debug2: channel 0: input open -> drain > > 0.50: debug2: channel 0: ibuf empty > > 0.50: debug2: channel 0: send eof > > 0.50: debug2: channel 0: input drain -> closed > <snip> > > 0.50: debug2: channel 0: garbage collecting > > 0.50: debug1: channel 0: free: client-session, nchannels 1 > > 0.50: debug3: channel 0: status: The following connections are open: > > 0.50: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1) > > 0.50: > > 0.50: debug3: channel 0: close_fds r -1 w -1 e 6 > > 0.50: debug1: fd 0 clearing O_NONBLOCK > > 0.50: debug1: fd 1 clearing O_NONBLOCK > > 0.50: Transferred: sent 5240, received 1208 bytes, in 0.0 seconds > > 0.50: Bytes per second: sent 225133.4, received 51901.0 > > 0.50: debug1: Exit status -1 > > > On Sunday, April 08, 2012 00:48:37 Matt Johnston wrote: > > Hi, > > > > There isn't any scp specific code, so I think something else > > must be going wrong. Does running "ssh tsct hostname" work? > > (scp gets run as a command argument like that). > > > > Could it be that 0.55 was compiled against a different libc > > that has dependencies on libnss* or something? To me it > > looks as if the "Error Resolving..." message is coming from > > the client side, either scp or ssh. It's possible that it's > > be getting written from the scp binary on the server though. > > > > Cheers, > > Matt > > > > On Fri, Apr 06, 2012 at 06:49:49PM -0400, Ian McDonnell wrote: > > > All, > > > > > > I've moved from version 0.50 to 0.55 and find that I can > > > login just fine using openssh client ssh and dropbear 0.55 > > > server, but when using openssh client scp to the same > > > dropbear server the > > > > > > command fails with: > > > > $ scp Makefile tsct: > > > > toor@tsct's password: > > > > WARNING: Ignoring unknown argument '--' > > > > scp: exited: Error resolving: Name or service not known > > > > > > I've looked for options for reverse DNS lookup auth checks > > > etc. The server host has an /etc/hosts entry for the > > > client machine's IP, but looks to me like dropbear scp > > > server is still unhappy. Anyone know why 'ssh' works just > > > fine, but 'scp' does not? > > > > > > I'm using the multidropbear binary, with links in the usual > > > places, eg /usr/bin/rcp etc. I can see using strace that > > > the dropbear server is exec'ing (dropbear) rcp. It looks > > > like it does a DNS (NSS?) lookup before failing. Does > > > 0.55 have some new authentication logic that is just for > > > scp? > > > > > > Thanks, > > > -Ian
