On Fri, Feb 12, 2016 at 9:25 AM, Randall S. Becker <rsbecker at nexbridge.com> 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.
Randall S. Becker
2016-Feb-25 23:36 UTC
Test Failure OpenSSH 7.1 P2 on HPE NSE for integrity
On February 11, 2016 7:12 PM, Darren Tucker wrote:> On Fri, Feb 12, 2016 at 9:25 AM, Randall S. Becker > <rsbecker at nexbridge.com> 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
On Thu, 25 Feb 2016, Randall S. Becker wrote:> > 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?The exec in sshd-log-wrapper.sh is just an optimisation to avoid keeping an unnecessary shell around. You could just try removing it. -d