Each of those processes, in turn, will do whatever they're configured to do on receipt of that signal. This notifies the shell that you've vanished and that it should begin cleaning up after itself what happens at this point is shell specific (search its documentation page for 'HUP'), but for the most part it will start sending SIGHUP to running jobs associated with it before terminating. When the SSH daemon process associated with your connection decides that your connection is dead, it sends a hangup signal (SIGHUP) to the login shell.

You can observe this with the pstree command. Every program you start normally at that point, no matter how many layers of shells deep, will ultimately 'trace its ancestry' back to that shell. When you logged in, the SSH daemon allocated a pseudo-terminal for you and attached it to your user's configured login shell. What follows is a longer explanation that will help you understand how it actually works.

It depends on how long it takes for the SSH daemon to decide that your connection is dead. They will get killed, but not necessarily immediately. The text below describes how things have traditionally worked in UNIX designspace for longer than Linux has existed. Those mechanisms are outside the scope of this question. The behavior can be changed by setting KillUserProcesses=no in /etc/systemd/nf, or circumvented using the systemd-specific mechanisms for starting a daemon in userspace. As of systemd v230, the new default is to kill all children of a terminating login session, regardless of what historically valid precautions were taken to prevent this. This Q&A predates the systemd v230 debacle. Does getting disconnected from an SSH session kill your programs?

Putty terminate ssh session