Que opções `ServerAliveInterval` e` ClientAliveInterval` no sshd_config exatamente fazem?


161

Encontrei essa pergunta , mas desculpe-me por não entender completamente as configurações das duas variáveis ServerAliveIntervale ClientAliveIntervalmencionadas na resposta aceita. Se meu servidor local estiver atingindo o tempo limite, devo definir esse valor como zero? Será que isso nunca vai expirar? Em vez disso, devo configurá-lo para 300 segundos ou algo assim?

Minha pergunta é simplesmente: algumas das minhas conexões atingem o tempo limite quando eu suspiro e depois desinstalo o laptop com a resposta Write failed: Broken pipee outras não. Como posso configurar corretamente um sshd local para que eles não falhem com um pipe quebrado?

Respostas:


202

ServerAliveInterval : número de segundos que o cliente aguardará antes de enviar um pacote nulo ao servidor (para manter a conexão ativa).

ClientAliveInterval : número de segundos que o servidor aguardará antes de enviar um pacote nulo ao cliente (para manter a conexão ativa).

Definir um valor 0 (o padrão) desabilitará esses recursos para que sua conexão caia se ficar inativa por muito tempo.

ServerAliveInterval parece ser a estratégia mais comum para manter uma conexão ativa. Para evitar o problema de tubo quebrado, aqui está a configuração ssh que eu uso no meu arquivo .ssh / config:

Host myhostshortcut
     HostName myhost.com
     User barthelemy
     ServerAliveInterval 60
     ServerAliveCountMax 10

A configuração acima funcionará da seguinte maneira,

  1. O cliente aguardará inativo por 60 segundos (tempo ServerAliveInterval) e enviará um "pacote nulo não operacional" para o servidor e esperará uma resposta. Se não houver resposta, ele continuará tentando o processo acima até 10 (ServerAliveCountMax) vezes (600 segundos). Se o servidor ainda não responder, o cliente desconectará a conexão ssh.

ClientAliveCountMax no lado do servidor também pode ajudar. Esse é o limite de quanto tempo um cliente pode permanecer sem resposta antes de ser desconectado. O valor padrão é 3, como em três ClientAliveInterval.


Ok, então eu interpretaria zero segundos para sugerir "não se mantenha vivo", e é por isso que não pesquisa o cliente / servidor?
— M. Tibbits

3
yup 0 = não envia um pacote nulo. Outra diferença seria que ServerAliveInterval está definido na configuração do cliente, enquanto ClientAliveInternal está definido na configuração do servidor.
— Barthelemy

8
Parece um bom conselho para evitar que ociosidade cause timeouts, mas não entendo como isso se relaciona com a questão do OP de evitar canos quebrados quando o cliente suspende. Quando adormecido, o cliente não poderia enviar um pacote nulo; portanto, essa configuração é discutível?
— Sparhawk #

A parte ServerAlive é, certamente. ClientAliveInterval / ClientAliveCountMax é o que ajudaria aqui.
— Javawizard # 29/14

1
Olhando para esta antiga resposta, acredito que tenha respondido à pergunta no título e não à pergunta no segundo parágrafo, portanto, os comentários sobre ServerAliveInternal não são úteis para suspender, com os quais concordo. @JonasWielicki ClientAliveInterval pode ser ruim em um caso de suspensão porque o cliente suspenso não responde ao servidor e, eventualmente, o servidor desconecta o cliente após ClientAliveCountMax.
— Barthelemy

18

Isso é explicado no sshd_configmanual ( man sshd_config):

ClientAliveInterval

Define um intervalo de tempo limite em segundos, após o qual, se nenhum dado foi recebido do cliente, o sshd enviará uma mensagem através do canal criptografado para solicitar uma resposta do cliente. O padrão é 0, indicando que essas mensagens não serão enviadas ao cliente. Esta opção se aplica apenas ao protocolo versão 2.

ClientAliveCountMax

O valor padrão é 3. Se ClientAliveInterval(veja abaixo) estiver definido como 15 e ClientAliveCountMaxpermanecer no padrão, os clientes SSH que não responderem serão desconectados após aproximadamente 45 segundos. Esta opção se aplica apenas ao protocolo versão 2.

Para as opções do cliente, consulte a explicação em man ssh_config:

ServerAliveInterval

Define um intervalo de tempo limite em segundos, após o qual, se nenhum dado tiver sido recebido do servidor, sshenviará uma mensagem pelo canal criptografado para solicitar uma resposta do servidor. O padrão é 0, indicando que essas mensagens não serão enviadas ao servidor. Esta opção se aplica apenas ao protocolo versão 2.

ServerAliveCountMax

O valor padrão é 3. Se, por exemplo, ServerAliveIntervalestiver definido como 15 e ServerAliveCountMaxpermanecer no padrão, se o servidor não responder, sshserá desconectado após aproximadamente 45 segundos. Esta opção se aplica apenas ao protocolo versão 2.

Com base no acima, 0 significa que está desativado. Portanto, você deve definir esses valores altos o suficiente para evitar erros no tubo quebrado .


Postagem útil. Mas estou tão frustrado com isso. Estou definindo grandes intervalos em todo o lugar e minha conexão ainda está sendo interrompida após alguns minutos. (usando o OpenSSH no Ubuntu, não tenho certeza se isso é relevante)
— Sridhar Sarnobat

1
@ user7000 Configure o cliente (ssh) e o servidor (sshd). Isso pode ajudar: Como corrigir problemas com 'A conexão SSH foi inesperadamente fechada pela extremidade remota' .
— kenorb

Eu acho que estou chegando a algum lugar. Pode ser que eu não estivesse colocando um espaço antes ServerAliveIntervalno meu arquivo de configuração.
— Sridhar Sarnobat

16

A resposta de Barthelemy é legal, mas realmente não chega à raiz do problema. Você suspende sua máquina e deseja que a sessão SSH ainda esteja ativa quando você inicializar o computador.

Não existe uma configuração para o ssh que mantenha a conexão ativa assim. O SSH usa o TCP. Para começar, você precisa do handshake de três direções e, em seguida, mantém-se vivo após algum tempo ocioso. Quando você encerra / hiberna, todas as suas conexões TCP são fechadas com FIN. Não há como superar isso.

Para uma solução alternativa suja, você pode usar o VPS ou outra caixa online com tela para manter a conexão. Meu conselho não faz isso por razões de segurança.


1
Esta é de fato a única resposta para a pergunta.
— Calimo

1
Esta é de fato uma solução de segurança terrível, nunca faça isso.
— jahrichie

14

Como você não pode garantir que uma conexão SSH (sendo TCP) permaneça ativa quando uma extremidade parar de enviar ACKs para pacotes recebidos, eu pessoalmente uso http://www.harding.motd.ca/autossh/ para reiniciar todas as minhas conexões SSH quase assim que eu suspender.

Como o GNU Screen estará em uso no servidor, a reconectação me leva a onde eu estava antes.

Você pode ouvi-lo em portas extras para verificar continuamente se as conexões ainda estão ativas, mas, pessoalmente, acho que funciona bem o suficiente com os desabilitados e confiando apenas no ServerAliveInterval/ do próprio SSH ServerAliveCountMax.

Outra opção é http://mosh.mit.edu/, que usa UDP e se recupera perfeitamente da falta de conectividade a longo prazo.


5

Você também pode executar comandos nohupse quiser que eles sejam executados, independentemente da sua conexão SSH.

por exemplo

$ nohup tar -xzf some_huge.tar.gz &

A &é, penso eu, não é necessário, mas é conveniente, uma vez que torna o processo de execução em segundo plano para que você possa fazer outras coisas.

Eu sempre uso nohup para qualquer processo que demore um pouco, para não precisar recomeçar se perder a conexão por qualquer motivo - falta de energia (na minha localização remota, não no host obviamente), falta de rede, qualquer que seja.


Observe que nohup no zsh não funciona corretamente!
— Sridhar Sarnobat

@ user7000 o que é impróprio?
— precisa saber é o seguinte

Não me lembro, acho que basicamente não manteve o processo em execução depois que o cliente foi desconectado. Isso foi há alguns anos e eu parei de usar nohup e usei o repúdio.
— precisa saber é o seguinte

2
Eu acho que os zshusuários devem ficar com, em disown -hvez de nohup, a menos que o problema tenha sido corrigido desde então.
— precisa saber é o seguinte

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.