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

[Ian McDonnell]

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