On February 11, 2016 7:12 PM, Darren Tucker wrote:
> 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.
Status update:
We have isolated this situation down to at sshd-log-wrapper.sh where the exec call is returning immediately and improperly after sshd is started. The output from sshd is never properly captured so we do not see the "Corrupted" messages in the logs. The team is currently suspecting that exec is being a bit wonky and are trying to reproduce this independently. I don't suppose there is a different way to implement this test that does not depend on exec?
More to come.
Randall
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
