Re: ssh_exchange_identification: read: Connection reset by peer

[Goldy <goldy@goldenfish.info>]

Je me réponds à moi-même car le problème vient en réalité de l'accès par 
3G que j'utilise.

C'est assez surprenant mais le réseau réponds qu'une connexion est 
effective alors que le serveur ne répond pas en réalité.

J'ai vérifié ça en passant par une autre machine sur internet qui elle 
me disait que le serveur ne répondait pas, j'étais très surpris au 
début, jusqu'à ce que je teste sur d'autres machines éteintes sur 
lesquelles je semblais pourtant me connecter.

Alors c'est amusant parce qu'on peut mettre n'importe quelle ip et ça se 
connecte toujours... mais comme il n'y a pas de réponse du serveur, 
cette erreur est renvoyée...

Bref, je ne sais pas si c'est la connexion ou le serveur qui est down, 
mais c'est sans doute le serveur qui n'a pas supporté que gmic pompe 
toute la mémoire... c'est embêtant...

Il n'empêche que ce comportement du réseau est très bizarre... j'ai cru 
un instant qu'il y avait une attaque MITM (ce qui est probable si mes 
clés sont corrompu, ce dont je doute toutefois).


Le 19/10/2011 14:51, Goldy a écrit :
> Bonjour,
>
> J'ai un petit soucis sur un serveur pour me connecter en ssh.
>
> J'ai lancé un travail sur une très très grosse image en utilisant
> l'utilitaire gmic hier soir, ce qui nécessitait énormément de mémoire
> (les 4go de ram plus 6 go de swap étaient occupés).
>
> Depuis, je ne parviens plus à me connecter en ssh sur la machine, j'ai
> l'erreur suivante :
>
> ssh_exchange_identification: read: Connection reset by peer
>
> Voici la sortie verbeuse de la commande ssh (j'ai occulté volontairement
> le host et l'ip) :
>
> > $ ssh -vvvv host
> > OpenSSH_5.9p1 Debian-1, OpenSSL 1.0.0e 6 Sep 2011
> > debug1: Reading configuration data /home/goldy/.ssh/config
> > debug1: /home/goldy/.ssh/config line 1: Applying options for host
> > debug1: Reading configuration data /etc/ssh/ssh_config
> > debug1: /etc/ssh/ssh_config line 19: Applying options for *
> > debug2: ssh_connect: needpriv 0
> > debug1: Connecting to host [11.11.11.11] port 443.
> > debug1: Connection established.
> > debug1: identity file /home/goldy/.ssh/id_rsa type -1
> > debug1: identity file /home/goldy/.ssh/id_rsa-cert type -1
> > debug3: Incorrect RSA1 identifier
> > debug3: Could not load "/home/goldy/.ssh/id_dsa" as a RSA1 public key
> > debug1: identity file /home/goldy/.ssh/id_dsa type 2
> > debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
> > debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
> > debug1: identity file /home/goldy/.ssh/id_dsa-cert type -1
> > debug1: identity file /home/goldy/.ssh/id_ecdsa type -1
> > debug1: identity file /home/goldy/.ssh/id_ecdsa-cert type -1
> > ssh_exchange_identification: read: Connection reset by peer
>
>
>
> Je ne peux donc pas savoir si le traitement est toujours en cours, si le
> serveur a planté, bref n'ayant pas un accès physique à la machine et
> étant dans l'incapacité de la rebooter, je suis un peu bloqué.
>
> Donc ma question sera simple, est-ce que cette erreur est effectivement
> dû à la consommation excessive de mémoire de mon processus ? Est-ce
> qu'il faut juste que j'attende patiemment que le processus se termine
> pour me reconnecter ? Ou est-ce qu'on peut considérer que le serveur à
> planté et que je doive donc me déplacer physiquement vers la machine
> pour la réparer ?
>
> Il me semblait que le noyaux était dans la capacité de tuer un processus
> qui mettait en danger la stabilité du système de part sa consommation de
> mémoire vive... il y a peut-être des conditions bien particulières à ça...
>
> (je regrette de pas avoir loué un gros cloud pour faire ce travail, je
> me doutait que le serveur aurait du mal avec cette tâche ><)
>
> Merci d'avance