screen -D -R ... Se necessário desanexar e sair remotamente - qual é o propósito de "logout remotamente" aqui?

Quando você executa screenno servidor, na verdade você tem duas sessões de terminal ao mesmo tempo: a primeira com a qual você fez o SSH e uma segunda "local" gerenciada pelo screencomando. Se a primeira sessão for encerrada por qualquer motivo sem sair screencorretamente primeiro, essas duas sessões serão automaticamente separadas uma da outra e, quando você estabelecer uma nova sessão SSH, screenpermitirá que você se reconecte à segunda sessão existente.

Se o tempo limite que está cortando suas conexões for algo como um firewall cortando uma conexão existente por inatividade, o problema é que o firewall pode não ter um método para sinalizar o corte para qualquer extremidade da conexão, até o final em question tenta enviar algo pela conexão que foi cortada.

Portanto, se o firewall cortar a conexão SSH e você inserir um único caractere na conexão SSH, o firewall enviará de volta um TCP Reset para o cliente SSH e você verá que a conexão foi cortada. Mas o lado do servidor SSH não está necessariamente ciente disso: se o servidor não tentou enviar nada para você, ele ainda pode estar lá, esperando por qualquer entrada sua, em uma conexão TCP que é -até o servidor sabe- ainda conectado, mas ocioso.

Nesse caso em particular, você precisará da -Dopção screen -DRpara extrair a screensessão da sessão SSH antiga, mesmo screenque ela ainda esteja conectada.

Como efeito colateral, isso fará com que o servidor tente enviar a saída (a mensagem "desconectada" de screen, e um novo prompt de shell) na sessão SSH inicial e cortada, o firewall enviará um TCP Reset de volta e, portanto, o sshdlado do servidor finalmente obterá as informações de que a antiga conexão SSH foi interrompida no nível da rede e a limpará.

Mas se o que está causando o tempo limite da sua sessão SSH é algo no servidor que está fazendo com que sua primeira sessão SSH termine, por exemplo, o administrador do servidor definindo ClientAliveCountMaxcomo 0 sshd_confige ClientAliveIntervalpara algum valor diferente de zero como um hack para obter uma espécie de tempo limite de inatividade de sshd, sua antiga sessão SSH será totalmente desconectada e a screensessão já estará esperando por você em um estado já separado. Nesse caso, screen -Rbastaria reconectar-se a ele... mas, além disso, especificar a -Dopção não fará mal neste caso.

A propósito, abusar das configurações ClientAliveIntervale dessa maneira é uma maneira pouco confiável de configurar um tempo limite de inatividade do usuário, pois o lado do cliente pode contornar isso sem saber que está fazendo isso . Isso ocorre porque se trata de monitorar a atividade no nível da conexão SSH, não a atividade real do usuário.ClientAliveCountMaxsshd_configClientAliveInterval

Se o usuário do cliente SSH estiver enfrentando problemas de tempo limite de rede, ele poderá definir ServerAliveIntervalem seu ~/.ssh/config(ou uma configuração equivalente em um cliente não OpenSSH). Se o ServerAliveIntervaltempo limite de inatividade de conexão do firewall for menor que o do cliente, isso fará com que o cliente SSH envie automaticamente um SSH criptografado "você ainda está aí?" pacote em inatividade, e sshdo servidor responderia a ele, redefinindo os temporizadores de inatividade no firewall.

Mas definir um lado do cliente ServerAliveIntervalcom um valor de tempo limite mais curto também faria com que o servidor nunca alcançasse o ClientAliveIntervaltempo limite enquanto a conexão SSH estivesse realmente funcionando, anulando o suposto "tempo limite de inatividade do usuário".

Infelizmente, alguns padrões de proteção de segurança parecem ter incorporado esse ClientAliveIntervalhack de tempo limite de inatividade do usuário baseado em e, portanto, alguns auditores de segurança podem exigi-lo, mesmo que não seja realmente adequado para sua suposta finalidade.