scp - Remote: Failed to launch child process

[Geoff Wild]

Having an issue with scp.

sftp works fine.

OS 11i
SSH: based on OpenSSH 3.6p2
T1471AA_A.03.61.002_HP-UX_B.11.11_32+64.depot

Session:


# scp -v aaa test.can@sshtest.somedomain.com:fuelsale/
Executing: program /opt/ssh/bin/ssh host sshtest.somedomain.com, user test.can, command scp -v -t sale/
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090702f
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to sshtest.somedomain.com [142.229.6.7] port 22.
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version 3.2.3 SSH Secure Shell Windows NT Server
debug1: no match: 3.2.3 SSH Secure Shell Windows NT Server
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
debug1: Miscellaneous failure
No credentials cache file found

debug1: Miscellaneous failure
No credentials cache file found

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'sshtest.somedomain.com' is known and matches the DSA host key.
debug1: Found key in /.ssh/known_hosts:2
debug1: ssh_dss_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/id_rsa
debug1: Trying private key: /.ssh/id_dsa
debug1: Next authentication method: password
test.can@sshtest.somedomain.com's password:
debug1: Authentication succeeded (password).
debug1: fd 5 setting O_NONBLOCK
debug1: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: scp -v -t sale/
debug1: channel 0: request exec
debug1: channel 0: open confirm rwindow 10000 rmax 32768
debug1: Remote: Failed to launch child process!

debug1: channel_free: channel 0: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Killed by signal 2.
debug1: Calling cleanup 0x40016f9a(0x0)
debug1: Calling cleanup 0x40017092(0x0)


Any ideas?

[Steven E. Protter]

There is something wrong with isntallation and/or permissions on the NT Samba Server.

There may be configuration issues preventing th e server process from spawning.

SEP

[Geoff Wild]

SEP - yeah - thought of that - but if we use a FSECURE client on another HP-UX box - scp works. It also works using scp on an AIX box....but AIX is using scp2

Rgds...Geoff

[James A. Donovan]

Did a search of the ssh source code for the string "Remote:". The only place it appears (packet.c) would lead me to suspect that you have a permissions issue on the remote server. The message, "Failed to launch child process!", is being passed directly to the scp/ssh client from the remote host. It is not generated from anything with ssh/sshd on either side.

[Massimo Bianchi]

Does ssh towards the server works well ?


I had similar problem, while setting up my little PC as an openssh server, and the problem was in the shell that opensshd forks.


Try to troubleshoot doing the ssh connection, it will exclude some other rumor.

SCP rely on an underlying shell, after all, and if it do not start, scp do not work.

sftp connects directly to its server...

Massimo

[Jordan Bean]

Try: ssh remotehost 'type ssh scp; echo $PATH'

If this does not show you were ssh or scp are on the remote host, then sshd cannot find them in its PATH. This should not be a problem with the HP build because /opt/ssh/bin is part of the builtin secure PATH (see /sbin/init.d/secsh). If it shows that ssh is at /usr/bin/ssh, then it is likely that this is a symbolic link to the real binary. If so, then create one for scp.

I often see this problem on systems that have OpenSSH installed in a location that is not in the standard PATH (see /etc/PATH) or included in the compile-time secure PATH, and only ssh is symbolically linked in /usr/bin or /usr/local/bin.

Also make sure that scp exists, and all users have execution rights to it.

The easiest work around would be to use symbolic links in a path that appears in the secure PATH discovered above.

Another thought... does scp2 exist? If so, then scp may not be linked to that.

...

I just did some testing to duplicate your errors using OpenSSH 3.5p1 for Linux and 3.6.1p2 for HP-UX, but get either "scp not found" or "scp execution denied" or similar. So maybe I'm wrong about your particular error.

[Elmar P. Kolkman]

I think your problem is with the remote machine not having the command 'scp' in the PATH of the ssh daemon...
scp opens a ssh connection and then tries to start, on the remote server, the following command:
scp -v -t sale/

And starting that fails.

Another reason might be you're out of processes on the remote server.

So: check out where scp is located (which scp) on the remote server and make sure the path to it is in the PATH when the ssh daemon is started.

Hope this helps you started solving the problem.