Who is the original sender of SIGHUP when the ssh connection is closed?

Question

As we know, when the ssh connection is gone, the bash will receive a SIGHUP, and forward this signal to all its children.

I wonder who is the original sender of this SIGHUP, is it ssh client, ssh server, OS or something else?

I read the code of openssh-portabal, and I found only here uses the SIGHUP: https://github.com/openssh/openssh-portable/blob/master/sshconnect.c#L285

And the caller seems to be client: https://github.com/openssh/openssh-portable/blob/master/ssh.c#L1533

I didn't find any sender code in the server-side sshd.c

Does this mean that the sender is client? In this case, the SIGHUP will not be received by the server if the connection was interrupted. I'm not pretty sure about this, but in my experience this doesn't seem to be true.

So I'm curious about who is supposed to be the original sender. Is there a standard for this?

Answer 1

The bash process on the server side of the connection is running with its controlling terminal set to the slave side of a pseudo-terminal pair, with the master side attached to the sshd process.

When the connection is terminated, the sshd process closes the master side of the pseudo-terminal, which results in the kernel pseudo-terminal driver hanging up the slave side of the pseudo-terminal. When the slave side is hung up, the kernel tty core sends SIGHUP and SIGCONT signals to the terminal's session leader (which is usually that bash process) and every process in the session leader's process group.

This isn't specific to pseudo-terminals and ssh - the same thing happens if you are dialled in to the server over a modem attached to a serial port and the modem hangs up (which is where the "hang up" / SIGHUP naming originates). As you can tell, this is historical behaviour of very long standing.