Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian ssh_exchange_identification: read: Connection reset by peer

ssh_exchange_identification: read: Connection reset by peer

30 réponses
Avatar
Goldy
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

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4E9EC7D3.2050205@goldenfish.info
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Goldy
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




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Yves F. Barbier
On Thu, 20 Oct 2011 00:03:20 +0200
Goldy wrote:

...
Il n'empêche que ce comportement du réseau est très bizarr e... 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).



Ca y ressemble pourtant (ou bien à du DPI intrusif); tu devrais plut ôt passer
par qq chose comme stunnel en mode 3, CàD avec certificat client oblig atoire;
c'est infiniment plus dur à casser (et utiliser qq chose du genre Lava RND pour
générer des suites de nombres vraiment aléatoires).

Maintenant, tout dépend de la confiance qu'on peut porter au team de d ev
openssh... si tant est qu'on puisse leur accorder quelque confiance que
ce soit (cf: l'erreur corrigée il y a 3 ans sans piper un mot ni une l igne
dans le changelog, plus diverses autres "petites" alertes n'augurant rien
de bon).

--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Erwan David
On Thu, Oct 20, 2011 at 12:03:20AM CEST, Goldy said:
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).



J'ai un problème un peu similaire avec un IDS intégré à un firewall
checkpoint au boulot et ssh à partir de openssh 5.8

L'IDS prend les messages d'openssh pour une attaque contre certaibns
serveurs buggués des années 90 et fait un reset brutal de la
connexion.

On repère ça au fait que le paquet RST revient avbec un TTL différent
des autres paquets de la connexion ssh...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Yves Rutschle
On Thu, Oct 20, 2011 at 02:18:18AM +0200, Jean-Yves F. Barbier wrote:
> 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).

Ca y ressemble pourtant (ou bien à du DPI intrusif);



Ne pas mettre sur le compte de la malice ce qui peut être
expliqué par l'incompétence :-)

Sur un réseau 3G, il y a de fortes chances pour que tu
passes également par un NAT; il "suffit" que le NAT commence
par accepter la connexion entrante avant d'initier la
connexion sortante pour expliquer le comportement.

Est-ce que c'est fait exprès, et pourquoi, je n'en sais rien.

Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Yves F. Barbier
On Thu, 20 Oct 2011 08:34:05 +0200
Yves Rutschle wrote:

Ne pas mettre sur le compte de la malice ce qui peut être
expliqué par l'incompétence :-)

Sur un réseau 3G, il y a de fortes chances pour que tu
passes également par un NAT; il "suffit" que le NAT commence
par accepter la connexion entrante avant d'initier la
connexion sortante pour expliquer le comportement.

Est-ce que c'est fait exprès, et pourquoi, je n'en sais rien.



Oui, tu as raison; surtout que la plupart des OPs sous-traitent
l'exploitation du réseau à des boîtes pas toujours vraiment
compétentes (sfr, il y a qq années: 2-3j pour recevoir un SMS);
ou bien débordées par les changements incessants imposés par un
marketing dinausoresque..

Pour le NAT aussi, je m'en suis aperçu en montant un accès VPN
(tjrs sfr), il a fallu ruser et passer par un port "standard"
(443) sinon on était bloqué (même en non-privilégià ©s).

C'est souvent involontaire puis voulu: involontaire parce que c'est
le prestataire qui décide souvent de la marche à suivre, et voulu
parce c'est tellement tentant d'essayer de te vendre un accès VPN
à presque €20 par mois que ça doit en faire baver les act ionnaires
(quoique certains bavent naturellement:)

--
"Do not meddle in the affairs of wizards, for you are crunchy and good
with ketchup."

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Goldy
Le 20/10/2011 08:34, Yves Rutschle a écrit :
On Thu, Oct 20, 2011 at 02:18:18AM +0200, Jean-Yves F. Barbier wrote:
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).



Ca y ressemble pourtant (ou bien à du DPI intrusif);



Ne pas mettre sur le compte de la malice ce qui peut être
expliqué par l'incompétence :-)

Sur un réseau 3G, il y a de fortes chances pour que tu
passes également par un NAT; il "suffit" que le NAT commence
par accepter la connexion entrante avant d'initier la
connexion sortante pour expliquer le comportement.

Est-ce que c'est fait exprès, et pourquoi, je n'en sais rien.

Y.




Effectivement, ce n'est pas la première fois que je remarque des
comportements bizarres du réseau mobile de bouygues télécom (pour ne pas
le citer).

Dans le cas présent, on constate visiblement que le réseau réponds que
n'importe quel port de n'importe quel serveur (même down) est ouvert si
on scan une ip avec nmap par exemple, donc dans le cas présent, je pense
plus effectivement à un comportement de NAT.

À une époque, le réseau limitait artificiellement ce qui pouvait
transiter, et donc avait la très bonne idée de modifier les paquets http
pour que tout les fichiers excédants 21mo (si mes souvenirs sont exacts)
fassent croire au navigateur qu'il ne faisait que 21mo... (ce qui en
résultait des fichiers incomplets une fois téléchargés) j'avais relaté
ce comportement à divers endroits et personne ne semblait trouver ça
particulièrement scandaleux... alors qu'on nous fait des discours sur la
neutralité des réseaux, il semblerait qu'on ai tous acquis le fait que
les réseaux mobiles sont des réseaux définitivement à part...


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Yves F. Barbier
On Thu, 20 Oct 2011 11:02:49 +0200
Goldy wrote:

...
neutralité des réseaux, il semblerait qu'on ai tous acquis le f ait que
les réseaux mobiles sont des réseaux définitivement à part...



La solution est pourtant simple et vient de Coluche: "Et dire qu'il
suffirait qu'on ne l'achète pas pour que ça ne se vende pas" <;-p

Si les gens avaient un poil de corporatisme, ils se passeraient le mot
et interrompraient leurs abonnements cellulaires.

Pour avoir une idée de ce que ça peut donner, il suffit de 'gader ce qui
s'est passé aux USA dans les années 60 avec le veau aux hormones: les
associations de consommateurs on décrétées un "stop-conso" e t en 6-8
semaines les ventes ont chûtées de 80%; incidemment, les producte urs
ont cessé toute adjonction d'hormones dans l'élevage des veaux en
moins de 16 semaines au total...

--
Hear about...
the plastic surgeon who hung himself?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Goldy
Le 20/10/2011 13:54, Jean-Yves F. Barbier a écrit :
On Thu, 20 Oct 2011 11:02:49 +0200
Goldy wrote:

...
neutralité des réseaux, il semblerait qu'on ai tous acquis le fait que
les réseaux mobiles sont des réseaux définitivement à part...



La solution est pourtant simple et vient de Coluche: "Et dire qu'il
suffirait qu'on ne l'achète pas pour que ça ne se vende pas"<;-p

Si les gens avaient un poil de corporatisme, ils se passeraient le mot
et interrompraient leurs abonnements cellulaires.

Pour avoir une idée de ce que ça peut donner, il suffit de 'gader ce qui
s'est passé aux USA dans les années 60 avec le veau aux hormones: les
associations de consommateurs on décrétées un "stop-conso" et en 6-8
semaines les ventes ont chûtées de 80%; incidemment, les producteurs
ont cessé toute adjonction d'hormones dans l'élevage des veaux en
moins de 16 semaines au total...




À la différence que les gens ne sont pas captifs du veaux pour leur
nourriture, les individus le sont pour leur accès internet
malheureusement...

Sinon il semblerait finalement que ce comportement ait une utilité au
final, cela semble permettre de conserver la connexion pendant un
certain temps lorsque le terminal est coupé du réseau, j'ai pu reprendre
une session ssh sans me loguer à nouveau alors que ma connexion avait
été interrompue.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Yves F. Barbier
On Thu, 20 Oct 2011 15:54:51 +0200
Goldy wrote:

...
À la différence que les gens ne sont pas captifs du veaux pour leur
nourriture, les individus le sont pour leur accès internet
malheureusement...



Un accès 3G n'est pas vraiment un accès vital, et je ne parle pas de
s'en passer ad-vitam eternam; crois bien que seulement 2 mois à -80%
accéléreraient sensiblement (doux euphémisme) une saine rà ©flexion
chez les providers.
Si tu ne me crois pas, mets toi 30 secondes à leur place (ou imagine
que ton salaire chûte de 80% parce que tu refuses un compromis
raisonnable & win-win:)

--
I have the simplest tastes. I am always satisfied with the best.
-- Oscar Wilde

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Goldy
Le 20/10/2011 16:23, Jean-Yves F. Barbier a écrit :
On Thu, 20 Oct 2011 15:54:51 +0200
Goldy wrote:

...
À la différence que les gens ne sont pas captifs du veaux pour leur
nourriture, les individus le sont pour leur accès internet
malheureusement...



Un accès 3G n'est pas vraiment un accès vital, et je ne parle pas de
s'en passer ad-vitam eternam; crois bien que seulement 2 mois à -80%
accéléreraient sensiblement (doux euphémisme) une saine réflexion
chez les providers.
Si tu ne me crois pas, mets toi 30 secondes à leur place (ou imagine
que ton salaire chûte de 80% parce que tu refuses un compromis
raisonnable& win-win:)




Sans rentrer dans un débat, ça reste quand même quelque chose de
compliqué à mettre en place pour beaucoup de gens, ne serait-ce que
parce que la plupart ont des engagements sur des forfaits où toute
modification réengage le titulaire. Les opérateurs se sont blindés
contre la concurrence en rendant leurs clients captif de leurs offres,
donc globalement aujourd'hui boycotter l'accès mobile est quelque chose
qui en soit n'est pas vraiment réalisable à une échelle comparable à
l'exemple que tu donnais.

Mais je suis d'accord avec toi, le soucis étant que là, on ne peut tout
simplement pas nécessairement se passer d'un accès internet mobile
lorsque par exemple on est en déplacement (ce qui est mon cas en ce
moment même), et qu'il n'y a aucun moyen pour moi d'obtenir internet
autrement, et que de toute façon, même si je ne le l'utilisais pas, je
serais quand même facturé pour le service. Par contre si je ne voulais
pas manger de veaux, je pourrais très bien acheter des carottes à la
place, la démarche serait bien plus simple, raison pour laquelle elle a
pu avoir lieu à grande échelle alors que pour un accès internet mobile,
une mobilisation similaire resterait anecdotique.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
1 2 3