Empêcher les timeout ssh
Lorsqu’on est connecté en ssh à un ordinateur distant et qu’on laisse la connexion inactive pendant un certain temps, il arrive que l’on soit déconnecté. On se retrouve alors avec un message du style :
Read from remote host buzut.fr: Connection reset by peer Connection to buzut.fr closed.Voyons comment résoudre ce problème.
Deux approches permettent de contourner ce désagrément : l’approche serveur, et l’approche cliente.
Serveur
Si vous avez un accès administrateur au serveur, il est possible de configurer ClientAliveInterval et ClientAliveCountMax.
Il existe bien un paramètre TCPKeepAlive, mais il fonctionne sur la couche transport et non sur la couche applicative. C’est donc un petit peu moins fiable [en] et on préférera le désactiver au profit de ClientAliveInterval ou ClientAliveCountMax.
ClientAliveIntervalenvoie un message au client ssh après x secondes sans activité (0 = jamais). Si le client répond au serveur, la connexion est maintenue.ClientAliveCountMaxquant à lui, concerne le nombre maximal de requêtesClientAliveIntervalsans réponse que tolérera le serveur avant de fermer la connexion.
On va donc ajouter les lignes suivantes à /etc/ssh/sshd_config :
ClientAliveInterval 600
ClientAliveCountMax 0On redémarre ensuite le serveur en faisant service ssh restart.
Client
Cette solution est très pratique si l’on a pas un accès root à la machine. Il va s’agir d’utiliser la directive ServerAliveInterval. Cette dernière va faire en sorte que le client envoie toutes les x secondes une requête au serveur ssh pour lui signaler qu’il est toujours en vie. Ainsi, on évite la déconnexion par timeout. On ouvre donc /etc/ssh/ssh_config sur notre client et on y ajoute la ligne suivante :
ServerAliveInterval 120Votre ssh ne devrait désormais plus se couper lors de vos poses cafés ;)
Commentaires
Christian dit –
Salut.
ServerAliveInterval c'est pas dans /etc/ssh/ssh_config (et non dans /etc/ssh/sshd_config ) ?
Bye
Buzut dit –
Salut Christian,
Tu as tout à fait raison, merci de m'avoir indiqué l'erreur, c'est corrigé !
Zer00CooL dit –
Intéressant, je ne connaissais pas. Par contre, tu dis que c'est pratique dans un contexte ou l'on ne serait pas root ? Tu aurais un exemple qui nécessite de rafraîchir une connexion SSH pour qu'elle ne soit pas désactivée ?
J'ai rajouté cette directive sur la synthèse de SSH, en français : https://wiki.visionduweb.fr/index.php?title=SSH
Buzut dit –
Oui, ça arrive très fréquemment avec les hébergements web, par exemple chez OVH. C'est vraiment en fonction des réglages de la config su serveur ssh. Et donc quand tu n'es pas root sur la machine, tu ne peux pas modifier la configuration SSH… il ne reste donc plus que le client sur lequel tu peux jouer.
Zer00CooL dit –
Ok, je pense comprendre, mais, il me semblait que de toute façon, être root n'est pas recommandé. De ce fait, j'utilise des utilisateurs sudoers, qui dépendent de la configuration du serveur SSH, comme root d'ailleurs. Le délais de déconnexion est de 150 secondes.
Je comprend que avec le client, je pourrais contourner le délais de déconnexion, par exemple, en le configurant à 70 secondes, pour renvoyer 2 demandes d'actualisation, durant la période limitée par le serveur de 150 secondes, afin d'être sur de ne pas être déconnecté.
Buzut dit –
Ce que je voulais dire par là, c'est un compte qui possède un accès root. Le fait que le compte soit dans les sudoers fait qu'il peut accéder au même pouvoir que sudo, contrairement à un compte n'en faisant pas partie.
En revanche, le fait de se connecter en root ou non, c'est sujet à débat et cela dépend de l'usage du compte en question. Si c'est un compte qui ne sert qu'à de l'administration et que tu fais sudo sur toutes les commandes exécutées, utiliser un compte non-root ne changera pas grand chose, si ce n'est faire perdre du temps (ce n'est que mon opinion).
Rejoignez la discussion !