Thomas Güttler wrote: > Example: > ssh root@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@localhost 'kill -TERM insert_pid_here' which sends the signal. This expands on the second point in the stackoverflow answer. //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
