PuTTy SSH Session morta pelo sinal 2

Question

Quando me conecto a uma máquina via ssh, não consigo usar a combinação "Ctrl + C", pois ela envia um sinal de kill para a sessão.

Como exemplo, inicio uma sessão SSH na máquina cliente da máquina principal, executo o comando "top" no cliente e quando quero sair da "parte superior", uso a combinação "Ctrl + C" e a sessão SSH fecha . A saída deste processo é esta:

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

saída "ssh -vvv":

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 ~]#

Quando eu tento o MobaXterm para o ssh, não há problema. Portanto, o problema não é sobre as configurações dos servidores, é sobre a configuração do PuTTy.

Eu acho que enquanto eu uso o MobaXterm o Ctrl + C foi enviado para o servidor do cliente, enquanto o PuTTy foi usado, o sinal de interrupção foi enviado para o servidor principal (assim o processo de conexão ssh). Acho que se consertarmos esse caminho, o problema será resolvido.

    

Answer 1

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

Ctrl + C normalmente deve enviar um sinal de interrupção . O sinal de interrupção é Signal 2. Então está fazendo o que se pretendia.

Killed by signal 2

Essa mensagem não é aquela que você normalmente vê, mas é bem correta. O processo foi encerrado porque recebeu um sinal 2, o sinal interrupção SIGINT produzido por Ctrl + C

Primeiro, vamos ver qual combinação de teclas corresponde ao sinal de interrupção

$ stty -a | grep intr
intr = ^C

Agora vamos verificar o valor numérico do sinal de interrupção

$ 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

Observe que o sinal KILL é o sinal 9 (não 2). Você pode enviar qualquer um desses sinais usando o comando kill , mas apenas um deles é um sinal KILL e não é sinal 2.

Então a questão permanece: o que está produzindo a mensagem "Killed by signal 2".

Se olharmos para link vemos que esta mensagem pode ser produzida se você tiver um script que use trap SIGINT para interceptar sinais e realizar manuseio especial.

Talvez você tenha um alias top ou top anterior em $PATH than /usr/bin ?

$ type top
top is /usr/bin/top

Você sugere que uma sessão SSH de * nix computer main to * nix computer client seja descartada. Deixando você em um prompt de shell * nix.

A partir da sua menção ao MobaXterm como alternativa ao PuTTY, deduzo que você está usando a versão do Windows do PuTTY, não a versão * nix do PuTTY. Se assim for, não está claro por que sua conexão SSH é em duas partes (Win-PC - > "main" - > "client").

Se você estiver usando o PuTTY para efetuar login no main e, em seguida, usar ssh para efetuar login no cliente, não é de se surpreender que o ^ C do PuTTY seja manipulado por main e não seja passado ao cliente por top .

Podemos nos referir ao link que discute esse tópico.

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.

Então eu suspeito que sua sessão do PuTTY está configurada de forma diferente da sua sessão do MobaXterm e que algumas coisas estão acontecendo, das quais você (e portanto nós) não estamos cientes.

PuTTY não está enviando um sinal, está enviando um caractere de controle ASCII. Isso é fácil de provar. Nós apenas pedimos ao shell para fazer com que o caractere de controle ASCII 0x03 (ETX, Ctrl + C) não tenha nenhuma manipulação especial pelo shell e então veja o que o PuTTY envia:

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

Veja link 130 = 128 + 2 = sinal 2. Neste caso, usei ^ A para envie 0x01 para o shell que enviou o sinal 2 para o processo top . ^ C acabou de enviar 0x03, que cat-V exibe como ^ C.

Então, eu NÃO estaria tentando descobrir por que Putty "envia" o SIGINTR quando o mobaXterm não o faz. Nenhum deles faz isso. Eles apenas enviam um caractere de controle ASCII.

Então, veja como você invoca o PuTTY, clicando em um ícone na área de trabalho? Esse ícone tem propriedades (Alt + Enter) com parâmetros extras no Target? etc etc.