dropbear scp server rejecting client with "Name or service not known"

Thu Apr 12 22:02:23 WST 2012

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: toor at 192.0.1.13'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: toor at 192.0.1.14'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 at 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