ssh exit_status not 255

[Tom Brown <tdbrown@uiuc.edu>]

I'm having some trouble with ssh version 1:3.8.1p1-8.sarge.4

I expect ssh to either return 255 or the exit value of the remote
command but it frequently returns other values.
I want it to return 255 when it cannot connect, for example in this
case:
$ ssh -v -o ConnectTimeout=5 tdbrownth@paypal.com echo hi
OpenSSH_3.8.1p1, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to paypal.com [216.113.188.64] port 22.
debug1: connect to address 216.113.188.64 port 22: Connection timed out
debug1: Connecting to paypal.com [216.113.188.34] port 22.
debug1: connect to address 216.113.188.34 port 22: Connection timed out
ssh: connect to host paypal.com port 22: Connection timed out
$ echo $?
1


The following fixes my problem

--- openssh-3.8.1p1/ssh.c       2005-05-26 13:25:16.000000000 -0700
+++ openssh-3.8.1p1.mine/ssh.c  2005-05-26 13:24:51.000000000 -0700
@@ -579,7 +579,7 @@
            original_effective_uid == 0 && options.use_privileged_port,
 #endif
            options.proxy_command) != 0)
-               exit(1);
+               exit(255);

        /*
         * If we successfully made the connection, load the host private key



but `grep exit\( *.c` reveals that ssh frequently returns 1 instead of
255 when it has an error. Is this considered by design or a bug?
I thought I'd try debian-ssh before going upstream.


This is why I care about the return value...
I am using a pipe transport in local exim4 to run 
ssh user@host.in.office /usr/sbin/exim4 -bS

If ssh is unable to connect I want the message to be queued again but if
the remote exim4 returns an error the message should bounce. The local
exim4 can queue or error depending on the exit status of ssh.

The man page for ssh says...
     ssh exits with the exit status of the remote command or with 255
		 if an error occurred.
and exim should return exit status 0, 1, or 2.

Therefore I thought I could set up the local exim to queue on 255,
fail on 1 or 2. Because of what appears to be a bug in ssh.


Thank you for your contributions to debian, I really enjoy using it
(most of the time ;-),
Tom



-- 
Tom Brown   tdbrown@uiuc.edu