Por que meu tempo limite do ssh varia com o local da rede?

Quando sou transferido para um dos nossos servidores de escritório (que executa o Fedora 10) em casa, minha sessão expira após um período bastante curto de atividade (5 minutos ou mais). Eu tentei usar TcpKeepAliveno lado do cliente, sem efeito.

O que não entendo é que, se estou no escritório da LAN da empresa, posso deixar uma sessão inativa o dia todo sem que o tempo limite se esgote, de modo que o comportamento parece depender da minha localização.

Alguma idéia de por que isso está acontecendo e como evitar tempos limite quando não estou na LAN? Estou usando o cliente Terminal no Mac OSX, se isso ajudar.

ATUALIZAÇÃO - A sugestão de Dave Drager de usar o ServerAliveIntervalconjunto como diferente de zero TcpKeepAlive=nofuncionou para mim. Em relação a algumas das outras respostas, as ClientAliveconfigurações ... não são aceitas pelo cliente SSH do Mac OSX.

Há uma boa descrição sobre esse problema aqui .

Eles recomendam:

ssh -o TCPKeepAlive=yes

ou:

ssh -o TCPKeepAlive=no -o ServerAliveInterval=15

No entanto, tenho um problema no meu local de trabalho em que sou desconectado das sessões, onde em casa eles estão bem. Acredito que meu firewall (SonicWall) possa estar interferindo no TCPKeepAlive, talvez por causa do NAT.

Meu cliente SSH, SecureCRT, felizmente tem uma opção para um protocolo "NO-OP", que, acredito, basicamente envia um comando que não faz nada ao servidor. Ao ativar isso manualmente, posso permanecer conectado. Não tenho certeza do que o cliente de terminal do MacOSX possui, é semelhante a isso. Há um artigo sobre como implementar "NO-OP" na linha de comando.

Finalmente, você pode usar o Wireshark ou outro sniffer para assistir à sua conexão TCP real e descobrir o que está acontecendo com ela. Essa seria a maneira final de ver por que ainda está se desconectando ocasionalmente.

Provavelmente porque, quando você está se conectando em casa, passa por um firewall que fecha a sessão TCP após um pequeno período de tempo. Mas TcpKeepAlive deve evitar isso. Você ativou o TcpKeepAlive no lado do cliente ou no servidor?

Eu recebo isso o tempo todo na minha conexão Comcast. O problema é que o intervalo de manutenção do seu cliente SSH é muito longo para o tempo limite configurado no caminho da rede. Se você estiver no Linux, poderá modificar os valores ServerAliveIntervale ServerAliveCounterpara serem menores que os padrões. Este valor é definido em segundos. O arquivo de configuração em todo o sistema é encontrado (geralmente) em /etc/ssh/ssh_config. Definir esses dois AND TcpKeepAlivedeve ajudar a manter a conexão.

Como diz o raio, alguns firewalls cheios de estado 'esquecem' uma conexão após um tempo (geralmente configurável) e não permitem mais comunicação para a conexão; eles esperam que a conexão comece com um TCP SYN (refiro-me à sua comunicação SSH aqui).

Existe outra possibilidade. O caminho da rede entre sua casa e escritório pode ter perdas (do tipo pacote). Ao tentar digitar no cliente SSH, se o seu link parar por um tempo, o cliente poderá desistir e falhar.

A configuração keepalive no cliente manipulará o primeiro caso aqui, mas não poderá ajudar no segundo caso. O firewall normalmente fica no perímetro do escritório e, portanto, pode ser configurável. Isso também ajudaria no primeiro ponto.

Para verificar se você está tendo perdas intermitentes de link, você pode manter um 'ping' ativo em segundo plano a partir da sua máquina cliente.

Você também pode adicionar as configurações sugeridas por outras pessoas como padrão no seu ~/.ssh/configarquivo, para não precisar transmiti-las sshsempre que iniciar uma conexão:

nano ~/.ssh/config e adicione:

TCPKeepAlive=no
ServerAliveInterval=15