per-connection sshd doesn't always pass on SIGQUIT

Philippe Cerfon philcerf at gmail.com
Wed Dec 28 01:42:46 AEDT 2022


Hey.

I've noticed the following behavior and wondered whether it's possibly
a bug or why it behaves like this:

When having a SSH connection, than it seems there may be two sshd
processes for that, one running as root the other as the user. As far
as I know this is because of privilege separation, like e.g.:
├─sshd(2931)─┬─sshd(10174)───bash(10180)
│            └─sshd(10000)───sshd(10050,someuser)───sleep(10051)


When sending INT, TERM, QUIT or HUB to the 2nd process (10050), the
first one always exits with and error, and the remote command gets a
HUP when RequestTTY=yes|force or nothing when it's =no.

When sending INT, TERM, QUIT or HUB to the 1st process (10000), than
the second get the same (sent by the 1st) except for the case of QUIT.
Plus the same behavior with the remote command (here sleep) as above,
depending on RequestTTY (but of course, not working in the QUIT case,
as the 2nd process doesn't get that).


Is there any reason why it passes on all these signals but not QUIT?
Or is the perhaps a bug?

Thanks,
Philippe


More information about the openssh-unix-dev mailing list