PuTTy SSH Session killed by signal 2

When I connect to a machine via ssh I can't use "Ctrl + C" combination because of it sends kill signal to session.

As an example, I start a SSH session to client machine from main machine, I run "top" command on client and when I want to exit from "top" I use "Ctrl + C" combination and the SSH session closes. The output of this process is this:

[root@client ~]# top //I use Ctrl + C to exit from top
[root@main ~]# Killed by signal 2.

"ssh -vvv" output:

Last login: Tue Feb 13 14:08:57 2018 from main.company.intra
[root@client ~]# debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)
Killed by signal 2.
[root@main ~]#

When I try MobaXterm for ssh there is no problem. So the problem is not about servers configurations, it's about PuTTy configuration.

I think while I using MobaXterm the Ctrl+C has been sent to client server, while using PuTTy the interrupt signal has been sent to main server (so the ssh connection process). I think so if we fix this route the problem will be solved.

1 Answer

I can't use "Ctrl + C" combination because it sends kill signal to session.

Ctrl + C is normally supposed to send an interrupt signal. The interrupt signal is Signal 2. So it is doing what was intended.

Killed by signal 2

That message isn't one you normally see but it is quite correct. The process exited because it received a signal 2, the interrupt signal SIGINT produced by Ctrl + C

First lets see what key combination corresponds to the interrupt signal

$ stty -a | grep intr
intr = ^C

Now lets check the numeric value of the interrupt signal

$ man 7 signal
...
Signal Value Action Comment
-----------------------------------------------------------------------
SIGHUP 1 Term Hangup detected on controlling terminal or death of controlling process
SIGINT 2 Term Interrupt from keyboard
SIGQUIT 3 Core Quit from keyboard
SIGFPE 8 Core Floating point exception
SIGKILL 9 Term Kill signal
SIGSEGV 11 Core Invalid memory reference

Note that the KILL signal is signal 9 (not 2). You can send any of these signals using the kill command but only one of them is a KILL signal and it isn't signal 2.

So the question remains what is producing that message "Killed by signal 2".

If we look at we see this message can be produced if you have a script that uses trap SIGINT to intercept signals and perform special handling.

Maybe you have a top alias or a top script earlier in $PATH than /usr/bin?

$ type top
top is /usr/bin/top

You suggest that an SSH session from *nix computer main to *nix computer client is dropped. Leaving you at a *nix shell prompt.

From your mention of MobaXterm as an alternative to PuTTY I deduce you are using the Windows version of PuTTY not the *nix version of PuTTY. If so it isn't clear why your SSH connection is in two parts (Win-PC -> "main" -> "client").

If you are Using PuTTY to log in to main and then using ssh to log into client, it isn't especially surprising that PuTTY's ^C is handled by main and not passed to client for top.

We can refer to which discusses this topic.

ssh remotehost will run an interactive session on remotehost. On the client side, ssh will try to set the tty used by stdin to "raw" mode, and sshd on the remote host will allocate a pseudo-tty and run your shell as a login shell (e.g. -bash).

Setting raw mode means that characters that would normally send signals (such as Ctrl-C and Ctrl-) are instead just inserted into the input stream. ssh will send such characters as-is to the remote host, where they will likely send SIGINT or SIGQUIT and, typically, kill any command and return you to a shell on the remote host. The ssh connection will stay alive, as long as the remote shell is alive.

...

ssh remotehost command args ... will run a non-interactive session on remotehost. On the client side, ssh will not set the tty to raw mode (well, except to read in a password or passphrase). If you type Ctrl-C, ssh will get sent SIGINT and will immediately be terminated, without even issuing a Connection to remotehost closed message.

So I suspect your PuTTY session is configured differently than your MobaXterm session and that some stuff is going on which you (and therefore we) are unaware of.

PuTTY is not sending a signal, it is sending an ASCII control character. This is easy to prove. We just ask the shell to make ASCII control character 0x03 (ETX, Ctrl+C) not have any special handling by the shell and then see what PuTTY sends:

$ stty intr ^A
$ cat -v
I will now press Ctrl + C ^C
I will now press Ctrl + A
$ $ echo $?
130

See 130 = 128+2 = signal 2. In this case I used ^A to send 0x01 to the shell which sent signal 2 to the top process. ^C just sent 0x03 which cat-V displays as ^C.

So I would NOT be trying to find out why Putty "sends" SIGINTR when mobaXterm doesn't. Neither of them do that. They just send an ASCII control character.

So look at how you invoke PuTTY, is it by clicking a desktop icon? Does that icon have properties (Alt + Enter) with extra parameters in Target? etc etc.