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
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
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
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).
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).
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).
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).
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).
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).
> 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);
> 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);
> 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.
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.
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.
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.
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.
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.
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...
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...
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...
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...
On Thu, 20 Oct 2011 11:02:49 +0200
Goldy<goldy@goldenfish.info> 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...
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...
à 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...
À 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...
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:)
On Thu, 20 Oct 2011 15:54:51 +0200
Goldy<goldy@goldenfish.info> 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:)
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:)