ssh_exchange_identification: read: Connection reset by peer
Le
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
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
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 :
--
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/
Goldy
...
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/
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/
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/
Yves Rutschle
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/
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/
Goldy
...
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/
À 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/
Goldy
...
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/
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/