scp leaves processes

[als...@my-deja.com]

I have 2 machines set up to test scp. Both machine's dsa keys were
generated with a blank passphrase, public keys put in the other's
(not same user) ~/.ssh/authorized_keys2 file.

I can scp from machine A to B, no problem.

If I try machine B to A, I am prompted for user's password on machineA.
(Why? I've regenerated keys several times, same result.)
I type it in, it is accepted, file is transferred, all looks ok, but the
sshd on machine A is still there and there is a process on B
/usr/local/bin/ssh -x -oFallBackToRsh -v -l usernameA machineA scp -
v -t filename

When I kill the (extra) sshd on machineA some remaining output from the
scp -v output comes out on machineB.

This is with OpenSSH 2.1.1p4 . MachineA is a SCO 5.0.5 PC.
MachineB is a Sun Sparc Solaris 5.6

This is frustrating. I'm ALMOST there. So close, but not quite....
Allan

Sent via Deja.com http://www.deja.com/
Before you buy.

[Richard E. Silverman]

>>>>> "als2rt" == als2rt <als...@my-deja.com> writes:

als2rt> If I try machine B to A, I am prompted for user's password on
als2rt> machineA. (Why? I've regenerated keys several times, same
als2rt> result.)

Run the client and server in verbose mode and see what they say about
attempting to use publickey authentication.

als2rt> I type it in, it is accepted, file is transferred,
als2rt> all looks ok, but...

It sounds as if there's a bug in the scp compiled on the SCO box which
causes it not to exit when it's done. This wouldn't surprise me too much,
as SCO Unix is a little out of the way as Unix flavors go. I would
examine the state of the waiting process, or run it under a debugger and
find out what it's up to.

--
Richard Silverman
sl...@shore.net

[Darryl Krasman]

"Richard E. Silverman" wrote:

> It sounds as if there's a bug in the scp compiled on the SCO box which
> causes it not to exit when it's done. This wouldn't surprise me too much,
> as SCO Unix is a little out of the way as Unix flavors go. I would
> examine the state of the waiting process, or run it under a debugger and
> find out what it's up to.
>
> --
> Richard Silverman
> sl...@shore.net

I haven't seen this happen to/from SCO OpenServer 5.0.5 using
ssh-1.2.26, ssh-2.0.13 openssh-2.1.1p2, openssh-2.1.1p4 or
openssh-2.2.0p1.
--
Darryl
Ideal Computer Group Inc.

[Lutz Jaenicke]

In article <8rapqs$6jt$1...@nnrp1.deja.com>, als...@my-deja.com wrote:
>
>
>I have 2 machines set up to test scp. Both machine's dsa keys were
>generated with a blank passphrase, public keys put in the other's
>(not same user) ~/.ssh/authorized_keys2 file.
>
>I can scp from machine A to B, no problem.
>
>If I try machine B to A, I am prompted for user's password on machineA.
>(Why? I've regenerated keys several times, same result.)
>I type it in, it is accepted, file is transferred, all looks ok, but the
>sshd on machine A is still there and there is a process on B
> /usr/local/bin/ssh -x -oFallBackToRsh -v -l usernameA machineA scp -
>v -t filename
>
>When I kill the (extra) sshd on machineA some remaining output from the
>scp -v output comes out on machineB.
>
>This is with OpenSSH 2.1.1p4 . MachineA is a SCO 5.0.5 PC.
>MachineB is a Sun Sparc Solaris 5.6

This behaviour occured on HP-UX to me and seems also to happen on other
platforms. It is related to the socketpair() implementation.
On HP-UX it was cured by using -DUSE_PIPES=1 when compiling; by now it
is the default for HP-UX, SunOS 4 and SCO 3.2something.
Please check out whether USE_PIPES=1 helps and report to
openssh-...@mindrot.org, so that it can be included by default
for later versions.

Best regards,
Lutz
--
Lutz Jaenicke Lutz.J...@iee.TU-Berlin.DE
TU Berlin http://www.iee.TU-Berlin.DE/personen/jaenicke/
Institut fuer Elektrische Energietechnik Tel. +49 30 314-24552
Einsteinufer 11, D-10587 Berlin Fax. +49 30 314-21133

[als...@my-deja.com]

In article <slrn8tmd09....@emserv1.ee.TU-Berlin.DE>,
jaen...@iee.TU-Berlin.DE (Lutz Jaenicke) wrote:

> This behaviour occured on HP-UX to me and seems also to happen on
other
> platforms. It is related to the socketpair() implementation.
> On HP-UX it was cured by using -DUSE_PIPES=1 when compiling; by now it
> is the default for HP-UX, SunOS 4 and SCO 3.2something.
> Please check out whether USE_PIPES=1 helps and report to
> openssh-...@mindrot.org, so that it can be included by default
> for later versions.
>
> Best regards,
> Lutz
> --
> Lutz Jaenicke Lutz.J...@iee.TU-Berlin.DE
>

Thanks, Lutz.

I just recompiled the SCO box with the -DUSE_PIPES=1. (no changes to
the Sun/Solaris box since Solaris <-> Solaris had no problems)
Early test results look good. I'll test a little more and report
results. (next week)

Allan M. Stewart
aste...@xinetix.com