# Le client SSH s'arrête au bout de quelque minute sans erreur **URL:** \ **Category:** Support Debian\ **Tags:** buster, ssh\ **Created:** [Janvier 1, 2019, 7:05 UTC](https://www.debian-fr.org/t/le-client-ssh-sarrete-au-bout-de-quelque-minute-sans-erreur/78311 "2019-01-01T19:05:37Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![kro](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kro/32/7458_2.png) [@kro](https://www.debian-fr.org/u/kro)\ **Post date:** [Janvier 1, 2019, 7:05 UTC](https://www.debian-fr.org/t/le-client-ssh-sarrete-au-bout-de-quelque-minute-sans-erreur/78311/1 "2019-01-01T19:05:38Z")
bonjour, j’essaie de configurer un `proxy socks` avec `ssh`. `debian buster` côté client et `raspbian stretch` côté serveur. la connexion s’arrête toujours au bout de quelques minutes (durée variables, mais généralement en moins de 5 minutes) la commande ressemble à ça : ```nohighlight ssh -NT -D 5838 pi@xxxxxxx -vvvv ``` côté serveur il apparaît que la déconnexion se fait côté client : ```nohighlight Jan 1 18:55:01 raspberrypi sshd[27541]: Received disconnect from XX.XX.XX.XX port 59808:11: disconnected by user Jan 1 18:55:01 raspberrypi sshd[27541]: Disconnected from XX.XX.XX.XX port 59808 Jan 1 18:55:17 raspberrypi sshd[27578]: Connection closed by ::1 port 58798 [preauth] ``` et côté client je ne vois pas d’erreur, même avec `-vvvv` tout est normal jusqu’à : ```nohighlight Jan 01 19:45:01 micropoutre ssh[24528]: debug3: fd 0 is not O_NONBLOCK Jan 01 19:45:01 micropoutre ssh[24528]: debug3: fd 1 is not O_NONBLOCK Jan 01 19:45:01 micropoutre ssh[24528]: debug3: fd 2 is not O_NONBLOCK Jan 01 19:45:01 micropoutre ssh[24528]: Transferred: sent 43932, received 1032760 bytes, in 164.4 seconds Jan 01 19:45:01 micropoutre ssh[24528]: Bytes per second: sent 267.2, received 6281.2 Jan 01 19:45:01 micropoutre ssh[24528]: debug1: Exit status 0 ``` j’ai essayé toute sorte de config avec `Server` ou `Client` `AliveInterval` : ```nohighlight /etc/ssh/ssh_config Host * SendEnv LANG LC_* HashKnownHosts yes GSSAPIAuthentication yes ServerAliveInterval 5 ``` ```nohighlight /etc/ssh/sshd_config TCPKeepAlive yes ClientAliveInterval 25 ClientAliveCountMax 3 ``` mais ça ne change rien, quels que soient les intervals. avec `autossh` je peux relancer automatiquement la connexion mais les services qui en dépendent plantent quand même. bref je préférerai corriger le problème à la source. quelqu’un aurait une idée ? merci ! ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Janvier 1, 2019, 8:32 UTC](https://www.debian-fr.org/t/le-client-ssh-sarrete-au-bout-de-quelque-minute-sans-erreur/78311/2 "2019-01-01T20:32:17Z")
> [@kro](#): > > la commande ressemble à ça : > > ```auto > ssh -NT -D 5838 pi@xxxxxxx -vvvv > > ``` Cela c’est la manière d’avoir un mandataire (proxy socks) avec une simple commande `ssh` Vous auriez pu mettre `raspberrypi` ) la place des xxxx dans la commande 🙂 Pouvez-vous nous dire quelles sont les applications qui sont censées utiliser le mandataire et comment vous les avez configurées ? Je vois que le tunnel a été déconnecté au bout de 164 secondes ( \< 3 minutes ) mais que 1Mo a été transféré. Quel type de liaison existe entre `micropoutre` et `raspberrypi` ? et tentez de retrouver la déconnexion vers 19h45 dans les journaux du serveur. Bonne année 2019 Cordialement, Regards, Mit freundlichen Grüßen, مع تحياتي الخالصة * * * F. Petitjean Ingénieur civil du Génie Maritime. « On ne perd pas son temps en aiguisant ses outils. » Proverbe français « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos) ---
**Author:** ![kro](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kro/32/7458_2.png) [@kro](https://www.debian-fr.org/u/kro)\ **Post date:** [Janvier 2, 2019, 8:16 UTC](https://www.debian-fr.org/t/le-client-ssh-sarrete-au-bout-de-quelque-minute-sans-erreur/78311/3 "2019-01-02T08:16:02Z")
bonjour littlejohn, et merci de m’aider une nouvelle fois ! micropoutre est un nuc derrière un nat en france, le raspberry est derrière un nat en suisse. IP fixe fibrée des deux côtés. il y a plusieurs applications qui peuvent éventuellement utiliser le mandataire, celle qui plante systématiquement à chaque déconnexion ssh est le daemon deluge, configuré pour utiliser socksv5 en localhost:5838 (j’ai essayé avec la version des dépôts APT officiels ou avec un container docker, j’ai le même problème). je me suis un peu planté dans les logs que j’ai collé, mais le message est systématiquement le même côté serveur : `Received disconnect from XX.XX.XX.XX port 59808:11: disconnected by user` je me trompe peut-être mais par “disconnected by user” je comprends que c’est le client qui s’est déconnecté, du coup je cherche plutôt des infos de ce côté mais pour le moment je ne trouve rien qui explique ces déconnexions intempestives. pour simplifier un peu le problème, j’ai le même souci en établissant une connexion ssh normale (avec un shell) de micropoutre au raspberry (déco environ toutes les 5 min). donc le problème ne serait pas à chercher du côté du proxy socks5. par contre depuis un autre ordi situé au même niveau que micropoutre (client SSH sur ubuntu 18.04 WSL), je ne note pas de problème de déconnexion particulier. la configuration du client SSH est la même sur les 2 machines (`/etc/ssh/ssh_config` dans le message précédent, même comportement avec ou sans la directive ServerAliveInterval). ``` krodelabestiole@micropoutre ~ ssh -V OpenSSH_7.9p1 Debian-4, OpenSSL 1.1.1a 20 Nov 2018 ``` un exemple de déconnexion du client SSH avec un shell et -vvvv : ``` pi@raspberrypi ~ debug3: send packet: type 80 debug3: receive packet: type 82 debug3: send packet: type 80 debug3: receive packet: type 82 debug3: send packet: type 80 debug3: receive packet: type 82 debug3: send packet: type 80 debug3: receive packet: type 82 debug3: send packet: type 1 debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 e[write]/0 fd 4/5/6 sock -1 cc -1) debug3: fd 1 is not O_NONBLOCK Killed by signal 15. krodelabestiole@micropoutre ~ ``` ---
**Author:** ![kro](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kro/32/7458_2.png) [@kro](https://www.debian-fr.org/u/kro)\ **Post date:** [Janvier 2, 2019, 8:29 UTC](https://www.debian-fr.org/t/le-client-ssh-sarrete-au-bout-de-quelque-minute-sans-erreur/78311/4 "2019-01-02T08:29:54Z")
ah et je viens de voir que j’ai le même problème en me connectant sur un serveur chez Infomaniak. tout porte à croire que le problème se situe bien côté client / micropoutre / debian buster. malheureusement je comprends que pouic à ce message : ``` debug3: send packet: type 1 debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 e[write]/0 fd 4/5/6 sock -1 cc -1) debug3: fd 1 is not O_NONBLOCK Killed by signal 15. ``` ---
**Author:** ![kro](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kro/32/7458_2.png) [@kro](https://www.debian-fr.org/u/kro)\ **Post date:** [Janvier 2, 2019, 6:36 UTC](https://www.debian-fr.org/t/le-client-ssh-sarrete-au-bout-de-quelque-minute-sans-erreur/78311/5 "2019-01-02T18:36:37Z")
j’ai le même problème toujours sur micropoutre avec un client SSH lancé dans un container docker basé sur alpine. ``` krodelabestiole@micropoutre ~ sudo docker run -v '/root/.ssh/:/root/.ssh/' -it kroniak/ssh-client ssh -V OpenSSH_7.5p1-hpn14v4, LibreSSL 2.5.5 ``` du coup je ne pense pas à un bug du client SSH directement. peut-être plutôt un conflit avec un autre processus, ou un instabilité de la connexion à internet d’une manière ou d’une autre (quoi que j’utilise micropoutre aussi en serveur SSH sans problème, et pas de problème depuis d’autres machine du réseau local) mais je suis à court d’idée pour essayer de trouver l’origine du problème… ---
**Author:** ![kro](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kro/32/7458_2.png) [@kro](https://www.debian-fr.org/u/kro)\ **Post date:** [Janvier 2, 2019, 7:03 UTC](https://www.debian-fr.org/t/le-client-ssh-sarrete-au-bout-de-quelque-minute-sans-erreur/78311/6 "2019-01-02T19:03:40Z")
arf arf arf… bon j’ai très honte : j’avais une tâche cron que j’avais restauré de mon backup de jessie sans y faire attention, et qui check l’existence d’un processus et relance les choses concernées en tuant le processus SSH au passage toute les 5 minutes… argh désolé pour le dérangement. (et merci encore quand même)