On Fri, Feb 12, 2016 at 9:25 AM, Randall S. Becker
<rsbecker@xxxxxxxxxxxxx> wrote:
> On February 10, 2016 10:23 AM, I wrote:
>> On February 9, 2016 9:30 PM, Darren Tucker wrote:
>> [...]
>> > This one looks odd. The ssh session itself looks OK: it authenticates
>> > then sends a printf shell command (basically, just a way of
>> > guaranteeing a minimum amount of output being sent back:
>> >
>> > > debug1: Sending command: printf "%4096s" " "
>> >
>> > The session then closes OK but ssh exists with a -1 error code, which
>> > gets propagated back up the stack as a failure.
>> >
>> > > debug1: Exit status -1
>
> I put in a couple of debug statements in clientloop.c where exit_status is
> set. It looks like the initialization of exit_status = -1 is the only point
> where the value is modified.
Looking closer at the sshd log:
debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0
The code for this is in session_exit_message() and looks like:
if (WIFEXITED(status)) {
channel_request_start(s->chanid, "exit-status", 0);
packet_put_int(WEXITSTATUS(status));
packet_send();
} else if (WIFSIGNALED(status)) {
channel_request_start(s->chanid, "exit-signal", 0);
so your printf is probably dying with a signal rather than exiting.
Which signal? dunno, but my guess would be SIGPIPE. Try adding
something like this to the top of session_exit_message():
debug3("%s: status: %d", __func__, status);
> I'm trying to figure out how the while can exit
> without exit_status being modified. Can you shed some light on that?
if the server never sends an "exit-status" packet (as opposed to an
"exit-signal" packet, which it does send) then the exit-status code in
client_input_channel_req() will never get called and exit_status will
remain -1 since that's what it's initialized to.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
