Created attachment 1432 [details]
Implement "signal" channel request type, server and client.

Please try this patch, which is based on the one posted by Markus.

The client interace is not documented, but it's an escape sequence command line:

[CR]~C (should give you the "ssh> " prompt, then
-SHUP

(In reply to comment #1)
> Created an attachment (id=1432) [details]
> Implement "signal" channel request type, server and client.
> 
> Please try this patch, which is based on the one posted by Markus.
> 
> The client interace is not documented, but it's an escape sequence
> command line:
> 
> [CR]~C (should give you the "ssh> " prompt, then
> -SHUP

I haven't tested the client, but the server side of your patch appears to work. I applied it to the CVS head (as of about noon -0800 on 07 Jan 2008), and compiled and ran sshd on a Fedora 8 i386 box. Sending the TERM signal from my custom client (based on ruby Net::SSH) now appears to work as expected.

To get it to compile, I did have to modify your patch to add the following line to misc.c:

#include <signal.h>

Thanks! Looking forward to seeing this in the release version.

(In reply to comment #2)
> I haven't tested the client, but the server side of your patch appears
> to work. I applied it to the CVS head (as of about noon -0800 on 07 Jan
> 2008), and compiled and ran sshd on a Fedora 8 i386 box. Sending the
> TERM signal from my custom client (based on ruby Net::SSH) now appears
> to work as expected.

Sorry, a little (probably unnecessary) clarification... my "applied to cvs head" != "checked in". I'm not a maintainer. Just mentioning that the patch seems to work against my test case. I'd still like to see it get into cvs and an official release, though, since I'd rather wait for it to trickle into the package management of our linux distribution before installing onto our production servers.

Created attachment 1438 [details]
Move signo2name functions to channels.c

Minor tweak to the patch: move the signal no -> name functions to channels.c.  This saves ~120 bytes in some of the other programs the link in misc.o via libssh.a but don't actually need those channel name functions.

Comment on attachment 1438 [details]
Move signo2name functions to channels.c

>+} no2name[] = {
>+	{ SIGABRT,	"ABRT" },
>+	{ SIGALRM,	"ALRM" },
>+	{ SIGFPE,	"FPE" },
>+	{ SIGHUP,	"HUP" },
>+	{ SIGILL,	"ILL" },
>+	{ SIGINT,	"INT" },
>+	{ SIGKILL,	"KILL" },
>+	{ SIGPIPE,	"PIPE" },
>+	{ SIGQUIT,	"QUIT" },
>+	{ SIGSEGV,	"SEGV" },
>+	{ SIGTERM,	"TERM" },
>+	{ SIGUSR1,	"USR1" },
>+	{ SIGUSR2,	"USR2" },

I don't think it makes sense to automatically pass some of these from the client to the server. E.g. SIGSEGV, SIGFPE, SIGILL, SIGBUS, SIGPIPE, SIGALRM and SIGABRT should be considered "internal" and never passed (or acted upon by the server).

(In reply to comment #5)
> I don't think it makes sense to automatically pass some of these from
> the client to the server. E.g. SIGSEGV, SIGFPE, SIGILL, SIGBUS,
> SIGPIPE, SIGALRM and SIGABRT should be considered "internal" and never
> passed (or acted upon by the server).

The list of signals is specified in the RFC, but while we can generate (and process) all of these, only the ones for which the client has a signal handler will be automatically passed on.

I'm not entirely happy with the client interface, but it worked for testing.  (Should also interop test with at least one other implementation, I think PuTTY has it these days.)

This may be interesting for us. Is there any plan to get this patch released?

I'm voting for this one.  I sent an email to openssh-unix-dev and Darren Tucker was kind enough to point me here.

I'm building an app based on JSch, a Java implementation of SSH2, and I strongly desire the ability to send SIGINT and SIGKILL to the remote processes that will be spawned via my program.  Currently I have no clean way to do this, but this patch should allow it.

I concur with Damien Miller (though I am not a contributor) that some of these signals make little or no sense to send through to clients.  I would imagine that HUP, INT and KILL are probably the most frequent use cases for remote clients trying to talk to something they've spawned on the other side of the channel.  USR1 and USR2 probably make sense as well for custom magic.

Would people be more comfortable committing this if the signals that Damien lists as inappropriate (SIGSEGV, SIGFPE, SIGILL, SIGBUS,
SIGPIPE, SIGALRM and SIGABRT) are suppressed?

As a gentle nudge, the patch mentioned by the original poster, Daniel Azuma, was proposed over 5 years ago.  I'm *not* complaining about the timeline, as I'm not a committer and don't have any OpenSSH domain knowledge whatsoever, but it would be *fantastic* if this could actually make it into a release soon, especially since there's another independent path here along with confirmation that it, too, works.

I'll be eternally grateful :)

Thanks, regardless.

-Andrew Hayden

look at this for 5.4

Getting signal support would be awesome.
I'm curious if there are any reasons why it wasn't added yet (almost 2 years after the patch was submitted).

Created attachment 1699 [details]
update, improve the client UI a bit, remove client pass-through of signal

Created attachment 1700 [details]
extend the signals patch to accept them over the mux socket

Note, Darren Tucker patch 1699 has to be applied first!

This patch adds support for two new -O commands: ps and kill

- ps will list the PIDs of slave ssh processes
- kill allows to send signals

It also adds support to sshd to accept signals by number.

Sample session:
===============
 $ ./ssh -S /tmp/mux -M localhost -f perl ~/g/my-ssh/tellsignal.pl 
 $ ./ssh -S /tmp/mux localhost -O ps      
 24140
 $ ./ssh -S /tmp/mux localhost -O kill HUP 24140
 Signal request sent.
 signal HUP received
 $ ./ssh -S /tmp/mux localhost -O kill 15 24140
 Signal request sent.
 signal TERM received
 $ ./ssh -S /tmp/mux localhost -O kill KILL 24140
 Signal request sent.
 $ 

Some notes:
===========
* A new field "tag" is added to Channel, it is used as the session logical name. The current client implementation (muxclient) uses the process PID as the tag.

* muxclient() now gets the arguments remaining in argv after getopt processing so it can use them for the -O commands (currently, just "kill"). I am not completely sure about this because it can be a bit counterintuitive when the "-O cmd" part is used before the hostname:

  $ ssh -S /tmp/mux -O kill localhost TERM 24140


Bye,

 - Salva

The silly perl script that tells about the received signals...

$ cat tellsignal.pl 
#!/usr/bin/perl

for my $name (grep /^[A-Z]+$/, keys %SIG) {
    $SIG{$name} = sub { warn "signal $name received\n" };
}

while (1) {
    sleep 1;
}

(In reply to comment #12)
> Created an attachment (id=1700) [details]
> extend the signals patch to accept them over the mux socket

Nice idea, and I think I like the concept of "friendly names" for subsessions but this is really a separate enhancement. Could you please file it under a new bug of its own?

> Nice idea, and I think I like the concept of "friendly names" for
> subsessions but this is really a separate enhancement. Could you please
> file it under a new bug of its own?

done, see ticket 1664

Created attachment 1709 [details]
control command for sending signals

This patch contains the implementation of the kill command that allows to send signals to remote processes.

The patches attached to 1664 must be applied first.

We are freezing for the OpenSSH 5.6 release. Retargetting these bugs to the next release.

Targetting OpenSSH 5.7

In 5.8, there is still no support for the "signal" request. What's holding it back?

Retarget unresolved bugs/features to 6.0 release

Retarget unresolved bugs/features to 6.0 release

Retarget unresolved bugs/features to 6.0 release

(try again - bugzilla's "change several" isn't)

Retarget from 6.0 to 6.1

Retarget 6.0 => 6.1

Retarget uncompleted bugs from 6.1 => 6.2

Retarget bugs from 6.1 => 6.2

retarget to openssh-6.3

Retarget to openssh-6.4

Retarget 6.3 -> 6.4

Retarget incomplete bugs / feature requests to 6.6 release

Retarget incomplete bugs / feature requests to 6.6 release

Retarget to 6.7 release, since 6.6 was mostly bugfixing.

Remove from 6.6 tracking bug

Retarget incomplete bugs to 6.8 release.

These bugs are no longer targeted at the imminent 6.7 release

Created attachment 2500 [details]
Update of #1699 versus 6.7p1

Updated Darren's patch. Testing limited to compiling and basic client
functionality; no server testing.

It looks to me like the ability to have signals "automatically passed
on" is no lnnger present. That functionality is what I am really looking
for: We have some users that require the ability to pass SIGINT,
SIGQUIT, and SIGTERM to remote porcesses in a manner similar to what rsh
supports.

I like the idea of adding -O support for sending the signal. That might
be more useful than the ~S mechanism. I think I would lean towards
something like: -O signal INT rather than imitating kill(1)'s syntax.

OpenSSH 6.8 is approaching release and closed for major work. Retarget these bugs for the next release.

Retarget to 6.9

Retarget pending bugs to openssh-7.1

The OpenSSH 7.4 release notes state "OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support." which made me think of this bug, and how great it would be to have this RFC documented protocol feature in OpenSSH.

Lack of support for this channel message has been raised as an issue a couple of times in the last month from AsyncSSH users. AsyncSSH is capable of sending "signal" channel requests, but it's usually OpenSSH on the other end, and so these messages end up getting ignored, with no indication on the client why they didn't work.

I'd like to second the request for this support to be added! There are definitely users out there who are trying to use it.

Is there anything we can do to move this forwards? I've also just run into the lack of support for signalling processes started through SSH.

Would it help to separate out the client part from the server part? It seems that most of the discussion that has held it up is about the user interface. If the server part went in, other clients could start using it to send signals while OpenSSH worked out how to expose it in the client.

At present, other implementations are stuck waiting for OpenSSH to support this, because they're usually used against an OpenSSH server.

E.g. for Python: https://github.com/paramiko/paramiko/issues/785
and for Go: https://github.com/golang/go/issues/16597

(Also, a slightly belated happy 10th birthday to this bug ;-)

+1 for adding signal support to the daemon and punting on the client, if necessary.

Created attachment 3120 [details]
Add server support for signal channel (subset of previous patches)

This is a subset of previous patches that adds signal channel support to just the server. I lightly tested it using Go's SSH package as a client. The patch was generated from the tip of master (currently affa6ba) of the openssh-portable Git repo.

I'd like to second the request about adding this feature to the openssh server in priority, as an AsyncSSH user myself, and on behalf of my own users who run consequently into this issue as well.

I've committed a slightly revised version of the sshd changes. Signalling will only be supported to login and command sessions (i.e. not subsystems like sftp) and only for sessions without a forced command.

Thanks, Damien. Glad to see this. And thanks for the long-term commitment here, it's pretty awesome to see this issue still progressing and tracked after 10 years. I really appreciate that it never got closed as "will not implement" or working as intended.

Also thanks to Darren for the patch and to the other folks here who have built on top of it over the years.

Thanks Damien!

For reference, I'll link what looks like the main change implementing this: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/session.c.diff?r1=1.305&r2=1.306&f=h

Should this issue be marked resolved? Or will it be kept for tracking the implementation of signalling in the client side?

I was the original reporter. This issue has long since ceased to be relevant to me, but in my original report, I was looking only for a server-side implementation, as I was using a custom client. In my opinion, this issue can be closed, as solving the server side will unblock a lot of users on other clients. And it would be good, as has been suggested previously, to separate out a discussion of the client interface since it raises a whole different set of questions.

I just tested OpenSSH 7.9p1 against AsyncSSH and can confirm that the server support for handling signals seems to be working nicely. I second that this bug can probably be closed, and a new bug should be opened if anyone wants to re-visit client-side support.

I'll close this - please open a separate bug if anyone wants the ability to send signals from the client.

Close bugs fixed in openssh-8.1 release cycle