Sending Signal to remote process

[Peter Stuge]

Thomas Güttler wrote:
> Example:
>     ssh root at localhost /root/print-signal.py
> 
> Get PID of ssh:
>      ps aux| grep print-signal
> 
> Kill the matching ssh process:
>      kill pid-of-ssh
> 
> Unfortunately only the ssh process itself gets the signal, not the
> remote command (print-signal.py).  The remote command does not
> terminate :-(
> 
> How can I make ssh "forward" the SIGTERM signal to the remote command?
> 
> See https://stackoverflow.com/questions/48377993/forwards-sigterm-over-ssh
> 
> According to this[1] answer, openssh does not implement this.

Correct, that channel message is currently not supported by OpenSSH.


> It would be realy great if openssh could forward the signal to the
> remote-command.

Yes and no.

I agree that sending signals to remote processes (channels, actually)
can be very useful.

But I absolutely do not want to lose the ability to send signals to
the ssh client itself on the system where it is running.

So "remote signals" need to be separate from local signals - meaning
that they probably need some other interface than kill().

This gets complicated. How do you know which channel to send the
signal to? One ssh process can have many open channels.

So whatever interface is used would possibly also have to allow
enumerating open channels, but obviously only for the respectiveuser.

How to accomplish that in a portable manner? Maybe a AF_UNIX socket
with a custom protocol?

I don't think there exists any development for such an interface, and 
it's not a trivial thing.


Meanwhile, what you can do is make /root/print-signal.py on the
output its own pid to stdout which you save in your software/script
on the client side, and open a second channel (e.g. using multiplexing):

ssh root at localhost 'kill -TERM insert_pid_here'

which sends the signal.

This expands on the second point in the stackoverflow answer.


//Peter