Por que a sessão ssh ainda está ativa se eu “matar” o servidor ssh?

Question

Eu já encontrei isso depois que você se conectou ao Ubuntu 14.04 via ssh e você alterou o sshd_config para um estado inválido para que service ssh reload fizesse com que o servidor parasse de escutar mas não fechará sessões ssh ativas que eu estabeleci.

Para reproduzir os passos que fiz:

1. Conecte-se ao servidor ssh:

   ssh host
   

2. Altere /etc/ssh/sshd_config para um estado inválido, por ex. conjunto:

   GatewayPorts 0.0.0.0:62222
   

3. Recarregue a configuração do servidor

   sudo service ssh reload
   

4. Verifique se a conexão ssh estabelecida na etapa 1) ainda está ativa e você pode inserir o que quiser.

5. Não feche a conexão estabelecida e tente se conectar ao servidor novamente de outro terminal:

   ssh host
   

E no meu caso, recebi esta mensagem:

ssh: connect to host IP_ADDR port SSH_PORT: Connection refused

Isso significa que o servidor ssh não escuta mais as conexões de entrada, mas de alguma forma magicamente ainda executa e manipula minha conexão estabelecida.

Acho que às vezes isso pode ser útil para alguém se se bloquear em uma sessão ssh, para que ninguém mais possa se conectar ao servidor com certeza e ainda sendo capaz de executar qualquer coisa que o usuário queira.

  

Então a questão é: Esse comportamento é desejado? Qual é o propósito original de tal implementação?

btw, notei que o servidor ssh está, nesse caso, em um estado meio inconsistente:

$ service ssh reload
reload: Job is not running: ssh
$ service ssh start
start: Job is already running: ssh

Então, para ressuscitar o servidor, tive que executar:

service ssh reload

  

Notas provavelmente importantes:

     

1. O servidor Ubuntu foi configurado por Mail-in-a-Box v0.20 e não mais mudanças foram feitas.
  
2. O provedor do servidor (DigitalOcean) configurou para mim mais duas regras no sshd_config:      
   • ClientAliveInterval 120
     
   • ClientAliveCountMax 2
     
  

    

Answer 1

Como as conexões de usuários são executadas em diferentes processos. É um recurso bastante útil.

• Impede que você se bloqueie fora do seu servidor com uma configuração ruim
• É muito mais à prova de falhas: a falha de um único processo (usuário) não elimina todas as outras conexões
• Ele oferece um desempenho muito melhor do que um único processo manipulando todas as conexões
• É muito mais seguro: os usuários são realmente separados em diferentes processos.

Esta é uma prática comum para escrever servidores TCP dessa maneira. É um pouco diferente do Apache, por exemplo, que está gerando vários funcionários, que são reutilizados para conexões subsequentes.