Le client SSH s'arrête au bout de quelque minute sans erreur

Support Debian
,
Tags: #<Tag:0x00007f509fb6b808> #<Tag:0x00007f509fb6b6a0>
#1

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 :

ssh -NT -D 5838 pi@xxxxxxx -vvvv

côté serveur il apparaît que la déconnexion se fait côté client :

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’à :

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 :

/etc/ssh/ssh_config
Host *
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    ServerAliveInterval 5

/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 !

#2

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 :slight_smile:
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)

#3

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 ~
#4

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.
#5

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…

#6

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)

1 J'aime