trying to resurrect discussion about "Cannot signal a process over a channel (rfc 4254, section 6.9)"

Yonathan Bleyfuesz yonathan.bleyfuesz at
Wed Jul 25 22:41:12 AEST 2018

Hi all,

I would like to propose some ideas to revivify this subject.

-First, we could add support on the client to send signal thanks to the escape characters.
(code : ).

With this, in order to send a message requesting the server to send a SIGTERM to the remote process, you need to type  “~ST” which is not really invasive client-side.

But this means that the client has to enable TTY.

-Secondly , server-side, there is a problem with the currently suggested patch : it only works when we do an ‘exec’ request to the server (eg : ssh some-host “some; commands;”).

This is because in the other possible configuration, a shell is launched by the server. Then when we launch a process, it is forked by this shell and thus it has its own group-id.

When the user launches a signal-request hoping to reach a blocking process, the pid that is used by the ‘killpg’ function is the one of the shell. So it is this shell that catches the signal resulting in it:
	- dying and leaving zombies 
	- dying and taking its child with him (SIGHUP and SIGKILL)
	- ignoring the signal (SIGINT, SIGTERM, SIGQUIT).

Example of ID’s when I connect to a server and launch the script :  
 4060  1598  4060  1556 sshd            sshd: root at pts/2
 4062  4060  4062  4062 bash            -bash
 4075  4062  4075  4062 sh              sh
 4076  4075  4075  4062 sh              sh

So in order to take this use case into account we could use the 'tcgetpgrp()’  function from ‘unistd.h’. 
(code : )

Of course this would still work if there are no TTY present since we can still access the PGID of the forked child in the session attributes.

-Finally, in order to test these functionalities, we could integrate a test case in the regress folder. (code :

I tested all these features on MacOSX and Ubuntu 18.

I hope this helps,
Thanks in advance for your returns,


More information about the openssh-unix-dev mailing list