Quelles sont les options `ServerAliveInterval` et` ClientAliveInterval` dans sshd_config exactement?

J'ai trouvé cette question , mais je suis désolé, je ne comprends pas très bien les paramètres des deux variables ServerAliveIntervalet ceux ClientAliveIntervalmentionnés dans la réponse acceptée. Si mon serveur local arrive à expiration, devrais-je définir cette valeur à zéro? Est-ce qu'il n'y aura jamais de temps mort? Devrais-je plutôt le régler à 300 secondes ou quelque chose?

Ma question est simplement la suivante: certaines de mes connexions arrivent à expiration lorsque je suspends puis suspends mon ordinateur portable avec la réponse, Write failed: Broken pipetandis que d’autres ne le font pas. Comment puis-je configurer correctement un sshd local afin qu'il n'échoue pas avec un tuyau cassé?

ServerAliveInterval : nombre de secondes que le client attend avant d'envoyer un paquet nul au serveur (pour maintenir la connexion active).

ClientAliveInterval : nombre de secondes que le serveur attend avant d'envoyer un paquet nul au client (pour maintenir la connexion active).

Si vous définissez une valeur de 0 (valeur par défaut), ces fonctionnalités seront désactivées. Votre connexion pourrait alors être interrompue si elle était inactive trop longtemps.

ServerAliveInterval semble être la stratégie la plus courante pour maintenir une connexion active. Pour éviter ce problème, voici la configuration ssh que j'utilise dans mon fichier .ssh / config:

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

Le réglage ci-dessus fonctionnera de la manière suivante,

1. Le client attendra inactif pendant 60 secondes (heure ServerAliveInterval) et enverra un "paquet nul nul" au serveur et attendra une réponse. Si aucune réponse ne survient, le processus ci-dessus continuera à être utilisé jusqu'à 10 fois (600 secondes) (ServerAliveCountMax). Si le serveur ne répond toujours pas, le client déconnecte la connexion SSH.

ClientAliveCountMax côté serveur peut également aider. C'est la limite de temps pendant laquelle un client est autorisé à ne pas répondre avant d'être déconnecté. La valeur par défaut est 3, comme dans trois ClientAliveInterval.

Ceci est expliqué dans le sshd_configmanuel ( man sshd_config):

ClientAliveInterval

Définit un intervalle de délai en secondes à l'issue duquel, si aucune donnée n'a été reçue du client, sshd enverra un message via le canal chiffré pour demander une réponse du client. La valeur par défaut est 0, indiquant que ces messages ne seront pas envoyés au client. Cette option s'applique uniquement à la version 2 du protocole.

ClientAliveCountMax

La valeur par défaut est 3. Si ClientAliveInterval(voir ci-dessous) est défini sur 15 et qu'il ClientAliveCountMaxreste la valeur par défaut, les clients SSH qui ne répondent pas seront déconnectés au bout de 45 secondes environ. Cette option s'applique uniquement à la version 2 du protocole.

Pour les options client, voir l'explication dans man ssh_config:

ServerAliveInterval

Définit un intervalle de délai en secondes à l'issue duquel, si aucune donnée n'a été reçue du serveur, sshun message sera envoyé via le canal crypté pour demander une réponse au serveur. La valeur par défaut est 0, indiquant que ces messages ne seront pas envoyés au serveur. Cette option s'applique uniquement à la version 2 du protocole.

ServerAliveCountMax

La valeur par défaut est 3. Si, par exemple, ServerAliveIntervalest défini sur 15 et qu'il ServerAliveCountMaxreste sur la valeur par défaut, si le serveur ne répond plus, il sshse déconnectera après environ 45 secondes. Cette option s'applique uniquement à la version 2 du protocole.

Basé sur ci-dessus, 0 signifie qu'il est désactivé. Par conséquent, vous devez définir ces valeurs suffisamment élevées pour éviter les erreurs de canal cassé .

La réponse de Barthelemy est cool mais ne va pas vraiment à la racine du problème. Vous suspendez votre ordinateur et souhaitez que la session SSH soit toujours active au démarrage de votre ordinateur.

Il n'y a pas de telle configuration pour ssh qui maintiendra la connexion vivante comme ça. SSH utilise TCP, pour commencer, vous avez besoin d’une poignée de main à trois voies, puis vous restez en vie après un temps mort. Lorsque vous fermez / mettez en veille toutes vos connexions TCP sont fermées avec FIN. Pas moyen de surmonter ça.

Pour contourner le problème, vous pouvez utiliser VPS ou une autre boîte en ligne avec écran pour conserver la connexion. Mon conseil ne fait pas cela pour des raisons de sécurité.

Etant donné que vous ne pouvez pas garantir qu'une connexion SSH (TCP) restera active une fois qu'une extrémité cesse d'envoyer des ACK aux paquets reçus, j'utilise personnellement http://www.harding.motd.ca/autossh/ pour redémarrer toutes mes connexions SSH. presque aussitôt que je méfie.

Etant donné que GNU Screen sera utilisé côté serveur, le rattachement me permet de revenir à l’endroit où j’étais auparavant.

Vous pouvez le laisser écouter sur des ports supplémentaires afin de vérifier en permanence que les connexions sont toujours vivantes, mais personnellement, je trouve que cela fonctionne assez bien avec cette désactivation et en nous fiant uniquement à ServerAliveInterval/ ServerAliveCountMax.

Une autre option est http://mosh.mit.edu/, qui utilise UDP et permet de récupérer de manière transparente du manque de connectivité à long terme.

Vous pouvez également exécuter des commandes avec nohupsi vous souhaitez qu'elles s'exécutent indépendamment de votre connexion SSH.

par exemple

$ nohup tar -xzf some_huge.tar.gz &

Le &est, je crois, pas nécessaire, mais il est pratique car il fait tourner le processus en arrière - plan afin que vous puissiez faire d' autres choses.

J'utilise toujours nohup pour tout processus qui prend un certain temps, de sorte que je n'ai pas à recommencer si je perds la connexion pour une raison quelconque - coupure de courant (sur mon site distant, pas chez l'hôte), panne de réseau, peu importe.

Mettez votre longue session de course à l'intérieur de l'écran. Voir screen -h pour plus de détails.

De cette façon, vous pouvez vous reconnecter à la machine en utilisant ssh et vous reconnecter à la session écran.