Bug 587

Summary:	ssh returns non-zero return code but appears to work
Product:	Portable OpenSSH	Reporter:	John Canger <jcanger>
Component:	ssh	Assignee:	OpenSSH Bugzilla mailing list <openssh-bugs>
Status:	CLOSED DUPLICATE
Severity:	normal
Priority:	P2
Version:	-current
Hardware:	All
OS:	AIX

Description John Canger 2003-06-05 07:01:05 AEST

Code in question is a shell script which invokes ssh on a remote system. A 
non-zero (-1) return code results, however it appears the ssh does work. The 
function of the ssh is to kick off another shell script on a remote system which 
in turn invokes an scp on the originating system. The file that is requested by 
the scp is always present on the remote server. Finally, after several attempts, 
a zero return code is returned. I turned on verbose mode and compared the logged 
messages from a successful attempt against the logged messages from the failed 
attempts and saw no differences. What exactly  is the meaning of a -1 Exit 
Status?

Comment 1 Markus Friedl 2003-06-05 08:46:48 AEST

exit(255) usually happens on fatal errors.

how can i reproduce your problem?

Comment 2 John Canger 2003-06-06 00:16:37 AEST

Duplicating the bug:

Server A issues an ssh to Server B. The ssh kicks off a script on Server B. The 
script on Server B scp's a file from Server A and stores it on Server B. Run 
this repeatedly so see if any -1 exit status codes are seen, even though the scp 
appears to function.

Note: I happened to notice the ssh verion on these pair of servers is OpenSSH 
2.9.2. I thought I saw something somewhere where 2.9.2 returns inconsistent 
exit status codes.

Comment 3 Markus Friedl 2003-06-07 08:34:58 AEST

this works fine for me:



rm -f /tmp/ls2
while date; do
        ssh -oBatchMode=yes -A localhost \
                scp localhost:/bin/ls /tmp/ls2
        if [ $? -ne 0 ]; then
                echo ssh failed
        fi
        cmp /tmp/ls2 /bin/ls
        if [ $? -ne 0 ]; then
                echo scp failed
        fi
        rm -f /tmp/ls2
done

Comment 4 Darren Tucker 2003-06-12 20:46:02 AEST

This is probably a dupe of bug #341 which has not been sighted for a long while 
(version-wise).

Comment 5 Darren Tucker 2003-06-12 20:59:53 AEST

Thinking about it this might be a variant of bug #375.  If so it's been fixed 
since 3.6p1, so please try to replicate with the latest version (3.6.1p2).

Previously sshd would deref some random location right at the end of the session 
which would account for the random nature.  If this is the case you'll see 
Software Program errors in "errpt -a" on AIX in at least some cases.

Comment 6 John Canger 2003-06-13 00:54:31 AEST

Will instruct user to upgrade SSH version. This problem has not surfaced on any 
other installations running more current SSH levels.

*** This bug has been marked as a duplicate of 341 ***

Comment 7 Damien Miller 2004-04-14 12:24:19 AEST

Mass change of RESOLVED bugs to CLOSED