O analista João trabalha conectado remotamente ao servidor SERV10, através de um cliente Secure Shell (SSH), em sua estação de trabalho ET10. João constatou que, ao deixar de usar o cliente SSH por alguns minutos, ocorre a queda da conexão remota sem, no entanto, ocorrer a queda do link de rede. Ao investigar o motivo da queda, João descobriu que as sessões SSH são encerradas por SERV10 após 5 minutos de ociosidade de tráfego. Para mitigar a queda de conexão por ociosidade, João configurou no cliente SSH o parâmetro que estabelece o envio automático de um pacote criptografado com o objetivo de evitar o encerramento da sessão. Portanto, João configurou no cliente SSH da ET10 o parâmetro:
- A)TCPKeepAlive;
Errada, porque TCPKeepAlive trata de keepalive da camada TCP, não do mecanismo específico do cliente SSH para enviar pacotes criptografados.
- B)ChannelTimeout;
Errada, porque ChannelTimeout não é o parâmetro clássico de keepalive para impedir queda por ociosidade em sessões SSH.
- C)ClientAliveInterval;
Errada, porque ClientAliveInterval é usado no servidor SSH para enviar verificações ao cliente, não no cliente para manter a sessão.
- D)ServerAliveInterval;
Certa, porque ServerAliveInterval é o parâmetro do cliente SSH que define o envio periódico de pacotes criptografados para evitar o encerramento da sessão por ociosidade.
- E)UnusedConnectionTimeout.
Errada, porque UnusedConnectionTimeout não é o parâmetro SSH usado para esse mecanismo de manutenção de sessão.
Gabarito: D
Quando uma sessão SSH cai por ociosidade, normalmente não é o cabo nem o link de rede que falhou. O que aconteceu foi o próprio SSH entender que a conversa ficou tempo demais parada e encerrar a sessão. Para evitar isso, existem parâmetros de keepalive, isto é, mensagens de manutenção da conexão para mostrar que ainda há vida no túnel. No caso da questão, João ajustou o cliente SSH da ET10. Isso é a pista principal: se a configuração foi feita no cliente, o parâmetro correto é o que faz o cliente enviar periodicamente pacotes criptografados ao servidor. No OpenSSH, esse comportamento é controlado por ServerAliveInterval, que define de quanto em quanto tempo o cliente manda uma mensagem de verificação para manter a sessão ativa. Já o ClientAliveInterval atua no sentido inverso, no servidor, para que o SERV10 envie verificações ao cliente. Ou seja: cliente ajusta ServerAliveInterval; servidor ajusta ClientAliveInterval. A banca adora inverter isso, então vale decorar a lógica simples: quem configura no cliente usa a opção do cliente para falar com o servidor. Resumo de prova: SSH caiu por inatividade, link físico segue vivo, e você quer um keepalive criptografado no cliente. Então o gabarito é ServerAliveInterval.