openssh unix dev - Sep 2002 - [Bug 369] Inconsistant exiit status from scp

http://bugzilla.mindrot.org/show_bug.cgi?id=369





------- Additional Comments From devel at pitux.com  2002-09-10 19:19 -------
I confirm that this bug does exist. It's especially annoying since we use
here
a lot of scripts which check for the return values of scp to indicate success 
or failure.

In fact it does the good thing on nonexistent files/dirs/etc, but fails in case 
of auth failure, name resolution failures and so on (the number after
"rtfm" in
the prompt reports the cmd exit status):

fg!rtfm 0 (pts/2) ~ $ scp -v root at mod-tsf.pitux.com:.bashrc /tmp
Executing: program /usr/bin/ssh host mod-tsf.pitux.com, user root, command scp 
-v -f .bashrc
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
ssh: mod-tsf.pitux.com: Name or service not known
fg!rtfm 0 (pts/2) ~ $ scp -v root at mod-tsd.pitux.com:fartr /tmp  
Executing: program /usr/bin/ssh host mod-tsd.pitux.com, user root, command scp 
-v -f fartr
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to mod-tsd.pitux.com [212.67.34.43] port 22.
debug1: Connection established.
debug1: identity file /home/fg/.ssh/identity type 0
debug1: identity file /home/fg/.ssh/id_rsa type -1
debug1: identity file /home/fg/.ssh/id_dsa type -1
debug1: Remote protocol version 1.5, remote software version OpenSSH_3.2.2p1
debug1: match: OpenSSH_3.2.2p1 pat OpenSSH*
debug1: Local version string SSH-1.5-OpenSSH_3.4p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
debug1: Host 'mod-tsd.pitux.com' is known and matches the RSA1 host key.
debug1: Found key in /home/fg/.ssh/known_hosts:17
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Trying RSA authentication via agent with 'fgaliegue at
ovh.tbs-internet.com'
debug1: Received RSA challenge from server.
debug1: Sending response to RSA challenge.
debug1: Remote: RSA authentication accepted.
debug1: RSA authentication accepted by server.
debug1: Sending command: scp -v -f fartr
debug1: Entering interactive session.
debug1: fd 0 setting O_NONBLOCK
debug1: fd 1 setting O_NONBLOCK
scp: fartr: No such file or directory
debug1: fd 1 clearing O_NONBLOCK
debug1: Transferred: stdin 1, stdout 39, stderr 0 bytes in 0.3 seconds
debug1: Bytes per second: stdin 3.5, stdout 136.5, stderr 0.0
debug1: Exit status 1
fg!rtfm 1 (pts/2) ~ $  scp -v fg at mod-tsd.pitux.com:fartr /tmp
Executing: program /usr/bin/ssh host mod-tsd.pitux.com, user fg, command scp -v 
-f fartr
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to mod-tsd.pitux.com [212.67.34.43] port 22.
debug1: Connection established.
debug1: identity file /home/fg/.ssh/identity type 0
debug1: identity file /home/fg/.ssh/id_rsa type -1
debug1: identity file /home/fg/.ssh/id_dsa type -1
debug1: Remote protocol version 1.5, remote software version OpenSSH_3.2.2p1
debug1: match: OpenSSH_3.2.2p1 pat OpenSSH*
debug1: Local version string SSH-1.5-OpenSSH_3.4p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
debug1: Host 'mod-tsd.pitux.com' is known and matches the RSA1 host key.
debug1: Found key in /home/fg/.ssh/known_hosts:17
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Trying RSA authentication via agent with 'fgaliegue at
ovh.tbs-internet.com'
debug1: Server refused our key.
debug1: RSA authentication using agent refused.
debug1: Trying RSA authentication with key '/home/fg/.ssh/identity'
debug1: Server refused our key.
debug1: Doing challenge response authentication.
debug1: No challenge.
Permission denied.
debug1: Calling cleanup 0x8067140(0x0)
fg!rtfm 0 (pts/2) ~ $ 







------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=369





------- Additional Comments From markus at openbsd.org  2002-09-10 22:45 -------
do you have a patch for checking the exit status of ssh? 



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=369





------- Additional Comments From oberman at es.net  2002-09-11 03:26 -------
I have no patch for this. I simply reported the problem I discovered when
running scp from a Perl script and checking for errors.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

The only hang-on-exit problem left, that I know of, is the Solaris-
/bin/csh-doesn't-HUP-its-bg-procs-when-exiting problem, and that is
relevant only to pty sessions. SCP does not use pty sessions,
therefore this hang-on-exit problem won't bite an scp that wait()s
for its ssh child process.

Cheers,

Nico
-- 
> -----Original Message-----
> From: Thomas Binder [mailto:binder at arago.de]
> Sent: Tuesday, September 10, 2002 1:37 PM
> To: openssh-unix-dev at mindrot.org
> Subject: Re: [Bug 369] Inconsistant exiit status from scp
> 
> 
> Hi!
> 
> > ------- Additional Comments From markus at openbsd.org  
> 2002-09-10 22:45 -------
> > do you have a patch for checking the exit status of ssh? 
> 
> I attached a rough patch for that. It probably (I haven't been
> able to check) has one drawback, though: If the remote sshd has
> the "scp hangs on exit" problem, then the patched local scp will
> now do so, too.
> 
> Besides, the patch also adds a check for fork() returning an
> error.
> 
> 
> Ciao
> 
> Thomas
> 
Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

On Tuesday, September 10, 2002, Thomas Binder wrote:
> On Tue, Sep 10, 2002 at 02:26:38PM -0400, 
> Nicolas.Williams at ubsw.com wrote:
> > The only hang-on-exit problem left, that I know of, is the
> > Solaris- /bin/csh-doesn't-HUP-its-bg-procs-when-exiting problem,
> > and that is relevant only to pty sessions. SCP does not use pty
> > sessions, therefore this hang-on-exit problem won't bite an scp
> > that wait()s for its ssh child process.
> 
> No, scp can also hang on some systems where OpenSSH should have
> been compiled with USE_PIPES, but hasn't:
[...]

Ah, thanks. Is this why scp doesn't wait() for ssh? Is there any other
reason?
> Ciao
> 
> Thomas

Cheers,

Nico
-- 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

http://bugzilla.mindrot.org/show_bug.cgi?id=369





------- Additional Comments From devel at pitux.com  2002-09-11 17:29 -------
In response to #4:

I attempted to do a patch to scp.c which adds a call to waitpid() in do_cmd() 
in order to check for the exit status in the parent. Unfortunately, while it 
does the right thing on ssh failures, it just hangs the command in case it is 
bound to succeed. I'll investigate some more when I have the time.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=369





------- Additional Comments From binder at arago.de  2002-09-12 00:43 -------
Created an attachment (id=144)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=144&action=view)
Check ssh's exit status in scp

The attached rough patch should do the trick. Note that you have to close()
the file handles used to communicate with the ssh process, as otherwise the
remote scp (when copying to remote) will continue waiting for data, causing
waitpid() to wait forever.

Also note that this patch may cause hangs of the local scp client when the
remote sshd should have been compiled with USE_PIPES defined, but hasn't.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=369





------- Additional Comments From binder at arago.de  2002-09-12 00:45 -------
Forgot to mention that the patch in attachment #144 also adds a check for
fork() failure.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=369





------- Additional Comments From devel at pitux.com  2002-09-14 00:22 -------
Congratulations Thomas, it Works Wonderfully For Me(tm). I've retried all
test
cases in #3 and it returned the good error code each time. Problem solved for 
me, I just recompiled my 3.4p1 with this patch and so far so good.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.