Created attachment 3481 [details]
Patch to fix the described wrong behavior

How to reproduce 
# Make sure you have already added localhost to known hosts and have no difficulties connecting it

$ ssh -V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f  31 Mar 2020
OpenSSH_8.0p1, OpenSSL 1.1.1c FIPS  28 May 2019
OpenSSH_8.5p1, OpenSSL 1.1.1f  31 Mar 2020

$ ssh localhost sleep 1000 & sleep 2; kill $!; wait $!; echo "exit code of $! is $?"
[1] 963702
[1]+  Done                    ssh localhost sleep 1000
exit code of 963702 is 0

What does testing code do? It runs ssh session, waits for 2 seconds to make sure connection is established well, kills ssh client and outputs its exit code. 
As you can see ssh client is ended successful on being killed.

    Correct (expected) behavior

$ ssh -V
OpenSSH_7.2p2, OpenSSL 1.0.2p-fips  14 Aug 2018
$ ssh localhost sleep 1000 & sleep 2; kill $!; wait $!; echo "exit code of $! is $?"
[1] 24309
Killed by signal 15.
[1]+  Exit 255                ssh localhost sleep 1000
exit code of 24309 is 255

    Origin
The issue seems was introduced by this commit https://github.com/openssh/openssh-portable/commit/b1e72df2b813ecc15bd0152167bf4af5f91c36d3
which intent was to hide extra message to verbose logging to make the client behavior better. Unfortunately this issue additionally changed the exit code of ssh client.

    Bugfix
        if (received_signal) {
                verbose("Killed by signal %d.", (int) received_signal);
-               cleanup_exit(0);
+               cleanup_exit(255);
        }
 
        /*


    Impact
We are widely using ssh in our environment to run remote execution tasks. And the main controlling point of successful task execution is 0 exit code of ssh client. Unfortunately in rare cases ssh clients might be killed by signals and we count their termination status as successful.
I feel many automation scripts in all modern Linux infrastructures are relying on ssh client exit code and currently may be a bit malfunctioning.