per-connection sshd doesn't always pass on SIGQUIT

[Damien Miller]

On Tue, 27 Dec 2022, Philippe Cerfon wrote:

> 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?

It's because the monitor process doesn't explicitly handle SIGQUIT.
Try this:

diff --git a/monitor.c b/monitor.c
index 93d122e..ea44873 100644
--- a/monitor.c
+++ b/monitor.c
@@ -328,6 +328,7 @@ monitor_child_postauth(struct ssh *ssh, struct monitor *pmonitor)
 	ssh_signal(SIGHUP, &monitor_child_handler);
 	ssh_signal(SIGTERM, &monitor_child_handler);
 	ssh_signal(SIGINT, &monitor_child_handler);
+	ssh_signal(SIGQUIT, &monitor_child_handler);
 
 	mon_dispatch = mon_dispatch_postauth20;