OVH Community, votre nouvel espace communautaire.

mon serveur est il mort et qui contacter?


guardian
07/01/2016, 10h14
Désolé Abazada, je ne peux toujours pas fournir l'IP pour le moment. Tant que je n'aurais pas retrouvé l'accès pour détruire tous mes fichiers, il existe toujours un risque de sécurité si le service devait se remettre à fonctionner.

L'IP ne vous servirait à rien sauf si vous êtes administrateurs réseaux chez OVH, vous la donner ne servira qu'à me faire courir des risques inutiles.

De toute façon j'ai pris ma décision, je ne peux pas rester chez un fournisseur qui n'assure ni continuité de service ni support en cas de panne. C'est trop risqué. Je préfère payer plus pour un service de qualité.

fritz2cat
07/01/2016, 09h48
@Abazada: on a perdu trop d'énergie pour ce gars qui refuse de collaborer. Qu'il aille polluer les forums des concurrents d'OVH.

Abazada
07/01/2016, 07h50
Encore une remarque Guardian: Je viens de relire les 4+ pages et tu ne donnes nulle part la moindre info qui permettrait d'identifier le serveur en question. OVH ne fait pas le support sur le forum, mais le support y intervient régulièrement pour aider... quand ils ont les infos.

Sans mettre en péril ton projet Top Secret, et donc divulguer ta précieuse IP,
tu aurais pu indiquer le nom de ton instance (le code hexadécimal)
et surtout le n° de ton ticket aurait été utile (et l'est toujours)

Si tu t'en vas, tu vas peut-être pouvoir nous donner enfin cette IP ? (celle du message #45 ?)
et vérifier que le serveur tourne (console VMC dans ManagerV6) afin que l'on teste son accès ?

Donc:
- IP ?
- Serveur On ? (normal ou rescue, peu importe)
- n° ticket ?

Nowwhat
07/01/2016, 07h35
Depuis ce matin, j'ai un reverse :
host 158.69.xx.178
178.xx.69.158.in-addr.arpa domain name pointer bhs-z2b10-a70.qc.ca
Et effectivement, whois 158.69.xx.178 donne un résultat aussi maintenant.

janus57
07/01/2016, 07h34
Bonjour,

le whois donne FR, mais c'est gérer par ARIN + reverse avec présence de BHS + le fait que il a d'autre serveur/sites en Amérique je pense effectivement que l'instance est à BHS.

Son IP + traceroute :
Code:
C:\Windows\system32>tracert 158.69.46.178

Détermination de l'itinéraire vers bhs-z2b10-a70.qc.ca [158.69.46.178]
avec un maximum de 30 sauts*:

  1     6 ms     3 ms     3 ms  livebox.home [192.168.1.1]
  2    25 ms    34 ms    25 ms  80.10.126.88
  3    26 ms    25 ms    26 ms  10.125.29.10
  4    28 ms    27 ms    28 ms  ae43-0.nrstr101.Schiltigheim.francetelecom.net [
193.252.160.90]
  5    34 ms    32 ms    33 ms  ae48-0.nridf301.Paris.francetelecom.net [193.251
.126.206]
  6    34 ms    34 ms    33 ms  ae44-0.noidf001.Paris.francetelecom.net [193.252
.99.102]
  7    33 ms    34 ms    34 ms  th2-1-a9.fr.eu [91.121.131.193]
  8    38 ms    37 ms    37 ms  rbx-g1-a9.fr.eu [213.251.130.52]
  9    41 ms    42 ms    50 ms  ldn-1-a9.uk.eu [91.121.128.87]
 10   114 ms   114 ms   113 ms  nwk-1-a9.nj.us [198.27.73.30]
 11   120 ms   121 ms   119 ms  bhs-g1-a9.qc.ca [198.27.73.205]
 12   120 ms   120 ms   120 ms  bhs-z2g1-a70.qc.ca [178.32.135.215]
 13   122 ms   123 ms   121 ms  bhs-z2b11-a70.qc.ca [158.69.46.244]
 14  bhs-z2b11-a70.qc.ca [158.69.46.244]  rapports*: Impossible de joindre l'hôt
e de destination.
Autre IP qui répond au ping + traceroute dans le même bloc :
Code:
Détermination de l'itinéraire vers 158.69.46.176 avec un maximum de 30 sauts.

  1     5 ms     4 ms     7 ms  livebox.home [192.168.1.1]
  2    27 ms    26 ms    25 ms  80.10.126.88
  3    26 ms    25 ms    24 ms  10.125.29.10
  4    40 ms    27 ms    30 ms  ae43-0.nrstr101.Schiltigheim.francetelecom.net [
193.252.160.90]
  5    32 ms    32 ms    32 ms  ae48-0.nridf301.Paris.francetelecom.net [193.251
.126.206]
  6    33 ms    33 ms    33 ms  ae44-0.noidf001.Paris.francetelecom.net [193.252
.99.102]
  7    33 ms    32 ms    33 ms  th2-1-a9.fr.eu [91.121.131.193]
  8    39 ms    36 ms    38 ms  rbx-g1-a9.fr.eu [213.251.130.52]
  9    44 ms    41 ms    41 ms  ldn-1-a9.uk.eu [91.121.128.87]
 10   113 ms   112 ms   113 ms  nwk-1-a9.nj.us [198.27.73.202]
 11   119 ms   118 ms   119 ms  bhs-g1-a9.qc.ca [198.27.73.205]
 12   118 ms   118 ms   118 ms  bhs-z2g1-a70.qc.ca [178.32.135.215]
 13   124 ms   119 ms   118 ms  bhs-z2b11-a70.qc.ca [158.69.46.244]
 14   121 ms   120 ms   120 ms  158.69.46.176

Itinéraire déterminé.
Vu que visiblement avec son IP cela s'arrête pile poil avant son instance perso je dirais que c'est bien un problème de config sur l’instance et non un problème de routage chez OVH, car si le problème de routage serait côté OVH cela n'irait sans doute pas sur le routeur voir l'hôte physique qui héberge l'instance (ce qui semble être le cas ici).

Et vu que cela ne répond pas au ping et vu que visiblement y a pas de ports qui répondent (au moment du test) je dirais qu'il est même pas en rescue, et encore sur les instance public cloud il me semble que dans le manager Horizon on a un accès à un genre de VNC/KVM pour un accès directe à l'instance ce qui permettrais de regarder directement dessus la config et surtout voir si elle arrive à contacter internet, et dans ce cas ce serait bien un problème de config si rien en input/output mais arrivé jusqu'au dernier routeur OVH.

Cordialement, janus57

guardian
07/01/2016, 07h21
Au secours, toujours rien côté support.

Bon c'est décidé, je plie bagage, content qu'OVH fonctionne pour certains, mais en ce qui me concerne, ça n'a été rien d'autre qu'un immense gaspillage.

Abazada
07/01/2016, 04h57
Citation Envoyé par Nowwhat
J'ai l'impression qu'on sort totalement du réseau d'OVH .....
ping 158.69.46.178
......
rien
Citation Envoyé par fritz2cat
OVH Canada. (BHS)
Hein? Non.
Le Whois me dit que 158.69.46.178 est FR. (RunAbove, Roubaix ?)

fritz2cat
06/01/2016, 23h38
Citation Envoyé par Nowwhat

8 158.69.61.44 (158.69.61.44) 1160.442 ms !H 1127.134 ms !H 1127.129 ms !H

J'ai l'impression qu'on sort totalement du réseau d'OVH .....

ping 158.69.46.178
......
rien

Bizarre.
OVH Canada. (BHS)

Nowwhat
06/01/2016, 23h24
Citation Envoyé par Abazada
Comment une IpV4 pourrait-elle ne pas "exister" ?
L'IP qu'il ma envoyer:
Rien route vers cet IP
host IP :.... not found: 3(NXDOMAIN) (reverse not found = possible, mais 'impossible' pour un IP d'OVH)

root@ns311465:~# traceroute IP
traceroute to IP (IP), 30 hops max, 60 byte packets
1 vss-3-6k.fr.eu (188.165.201.253) 0.391 ms 0.430 ms 0.549 ms
2 10.21.50.250 (10.21.50.250) 1.008 ms 1.046 ms 0.999 ms
3 * * *
4 10.21.51.18 (10.21.51.18) 80.825 ms 80.799 ms 80.803 ms
5 bhs-z2b11-a70.qc.ca (158.69.46.244) 80.910 ms 80.907 ms 80.937 ms
6 158.69.46.174 (158.69.46.174) 80.776 ms 81.135 ms 81.080 ms
7 158.69.61.44 (158.69.61.44) 81.093 ms 81.089 ms 81.084 ms
8 158.69.61.44 (158.69.61.44) 1160.442 ms !H 1127.134 ms !H 1127.129 ms !H

J'ai l'impression qu'on sort totalement du réseau d'OVH .....

ping 158.69.xx.178
......
rien

Bizarre.

Abazada
06/01/2016, 18h06
Citation Envoyé par Nowwhat
le IPv4 que tu m'as envoyé par mail n'existe même pas. Il n'y pas un serveur derrière ce IP .....
Comment une IpV4 pourrait-elle ne pas "exister" ?
Au pire elle pourrait faire partie d'une plage réservée : https://tools.ietf.org/html/rfc3330#section-3
Comment peux-tu savoir ce qu'il y a derrière ? Tu as testé tous les ports d'entrée possible ?

Guardian a indiqué que "le traceroute atteint le réseau d'OVH, mais pas l'IP de mon serveur"
ce qui indique bien une IP routable et à priori gérée par OVH.

Tout ce cirque aurait pu être évité si Guardian avait répondu
à au moins quelques une des questions indirectes sur son serveur et son IP...

fritz2cat
06/01/2016, 17h20
J'ai eu un disque qui commence à avoir des bad blocks.

Ticket incident ouvert à 16h19.
(avec les détails qu'il faut)

Disque remplacé à 17h07 par un nouveau.
Ce qui suit est assez rare
Code:
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   054    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0007   100   100   024    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       2
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   020    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       0
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       2
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       2
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       2
194 Temperature_Celsius     0x0002   206   206   000    Old_age   Always       -       29 (Min/Max 16/29)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0
Bravo OVH pour l'efficacité.
(il s'agit d'un kimsufi "ancien" -- donc doublement bravo)

Maintenant je m'en vais réinstaller tout, car c'est évidemment l'unique disque.

Nowwhat
06/01/2016, 16h53
Au moins, une chose est sur : le IPv4 que tu m'as envoyé par mail n'existe même pas. Il n'y pas un serveur derrière ce IP .....

Une autre possibilité : tu te connecte depuis un endroit 'douteux' et du coup, impossible de joindre ton serveur ..... Un bon VPN pourrait t'aider.

fritz2cat
06/01/2016, 14h49
Direction -> 31° 46′ 36″ Nord 35° 14′ 03″ Est

guardian
06/01/2016, 13h25
Il ne s'agit pas d'un problème de serveur mais d'IP et de routage. Le serveur tourne probablement mais n'est plus accessible.

J'ai déjà communiqué mon IP à un autre membre qui n'a pu que confirmer qu'elle n'était pas accessible.

Je suis vraiment ravi que pour vous, Messieurs, le support soit rapide comme l'éclair, mais en ce qui me concerne, toujours aucun support et j'ai bien déclaré l'accident.

Abazada
06/01/2016, 13h12
Rien ne dit (à part tes messages) que le serveur ne tourne pas correctement.
Alors un dernier essai pour aider, malgré ton roman sans aucune info technique :

- quelle version de PuTTY ? au moins 0.63 ?
- montre-nous ton traceroute , puisqu'il ne contient pas (n'accède pas) à ton IP top secrète...

Actuellement:
- ton serveur ping-t-il pour toi ?
- - si non, ping-t-il ailleurs ?
- - - en particulier, ping-t-il d'un autre serveur chez OVH ?
- si oui, que répond ton Apache ? (code?)
- - que répond-il aux autres ? par exemple : http://downforeveryoneorjustme.com/

Si rien ne répond,
- l'IP de ton serveur a-t-elle bien un reverse ? Est-ce bien un *.ip-*-*-*.eu ?
- que donne la Console VNC dans l'espace Cloud du ManagerV6 ? (taper Return sur l'écran noir)


Sinon pour les tickets OVH, à partir du moment où tu choisit "Déclarer un incident" en indiquant que le serveur n'est pas exploitable, j'ai eu un premier retour dans la journée, en général juste après quelques heures. Par contre si tu t'auto-réponds plusieurs fois ou ouvre plusieurs tickets analogue, je pense que ça te repousse dans le file d'attente...

guardian
06/01/2016, 12h45
Citation Envoyé par sich
Si ton serveur est accessible en rescue c'est qu'il y'a un problème dans ta config logicielle.
Si le serveur n'est pas dispo en rescue c'est autre chose. Bascule ton serveur en rescue pour commencer.

Dans tous tes posts je n'ai pas trop suivis si le serveur est up en rescue ou pas...
Le premier serveur était accessible en mode rescue, le second quant à lui non.

A noter que si en rescue le serveur fonctionne bien à ce moment là OVH n'est pas responsable de quoi que ce soit c'est à toi de trouver ce qui cloche.
Alors comment expliquez vous qu'une réinstallation complète depuis le panneau de contrôle n'ait rien changé?

Et des incidents sans réponse dans le support au bout d'une semaine sur la partie ovh ça serait assez exceptionnel... Perso en ce moment j'ai des réponses dans la journée.... Réponse précise et efficace.... J'ai peut être de la chance...
Expliquez moi votre secret, car de mon côté sur 10 tickets j'ai du avoir deux réponses, et chaque fois les "réponses" ne servaient strictement à rien. Il ne s'agissait même pas de réponses personnalisées mais de copier coller génériques.

Je pourrais accepter la lenteur du support si l’infrastructure d'ovh était fiable, mais j'ai systématiquement eu des problèmes d'accès le lendemain de mes commandes, et vous verrez sur le forum que je ne suis pas le seul. Le SLA sensé garantir le service à 99,99% n'a strictement servi à rien en ce qui me concerne. J'ai l'impression que ce n'est rien d'autre que du marketing.

Il s'agit probablement d'un problème grave dans le réseau d'ovh puisque l'IP qui m'a été attribuée n'est plus accessible, pour personne. Le forum ne pourra pas m'aider sur ce coup là, je veux juste dire à quel point je suis mécontent des prestations fournies par OVH. Si des professionnels viennent par ici je leur conseille d'aller voir ailleurs, OVH c'est la ruine assurée pour tout business. Dans mon cas heureusement que j'ai déjà un autre hébergeur à côté car si j'avais dû me fier à OVH, j'aurais subi d'énormes pertes.

fritz2cat
06/01/2016, 11h33
pfff #36 messages pour se plaindre et persister à ne donner aucune information qui pourrait permettre de faire avancer le schmilblick, c'est boulet.

sich
06/01/2016, 09h43
Si ton serveur est accessible en rescue c'est qu'il y'a un problème dans ta config logicielle.
Si le serveur n'est pas dispo en rescue c'est autre chose. Bascule ton serveur en rescue pour commencer.

Dans tous tes posts je n'ai pas trop suivis si le serveur est up en rescue ou pas...

A noter que si en rescue le serveur fonctionne bien à ce moment là OVH n'est pas responsable de quoi que ce soit c'est à toi de trouver ce qui cloche.

Et des incidents sans réponse dans le support au bout d'une semaine sur la partie ovh ça serait assez exceptionnel... Perso en ce moment j'ai des réponses dans la journée.... Réponse précise et efficace.... J'ai peut être de la chance...

guardian
06/01/2016, 09h20
Ça fait déjà plus d'une semaine que ça dure et toujours pas de réaction du support. J'ai vu sur d'autres sujets que des clients avaient pris deux mois de retard avec ce même problème! C'est vraiment très préoccupant....

A quoi sert ce fameux SLA de OVH si ils ne sont pas capables de détecter quand un serveur est hors service ? Je n'y comprends rien.

Par contre le compteur pour la facture n'est pas bloqué lui...

guardian
04/01/2016, 11h32
Citation Envoyé par Abazada
Quelques pistes:
- Qu'as-tu installé comme outils qui tourne en Cron ?
- Quel usage fais-tu de tes Vps? (peut-être quelque chose qu'OVBH assimilerait à une attaque?)
- Le tracert/traceroute va-t-il jusqu'à ton serveur quand il est "bloqué" ?

Sinon:
- Apache ne fait pas partie du "Debian de base". C'est un soft optionnel.
- Apache peut fonctionner comme il faut mais être rendu muet par un firewall par exemple
En absence d'accès Ssh, la lecture des logs sous rescue peut te dire ce qu'il en était.
1. aucun cron lancé par moi
2. installation d'un lampp et envoi de fichiers sources pour un site internet
3. le traceroute atteint le réseau d'OVH, mais pas l'IP de mon serveur

pour le moment je n'ai même pas accès au mode rescue, erreur réseau connexion refusée

Abazada
04/01/2016, 11h17
Citation Envoyé par guardian
A chaque fois ça a cessé de fonctionner après 24h.
Quelques pistes:
- Qu'as-tu installé comme outils qui tourne en Cron ?
- Quel usage fais-tu de tes Vps? (peut-être quelque chose qu'OVBH assimilerait à une attaque?)
- Le tracert/traceroute va-t-il jusqu'à ton serveur quand il est "bloqué" ?

Sinon:
- Apache ne fait pas partie du "Debian de base". C'est un soft optionnel.
- Apache peut fonctionner comme il faut mais être rendu muet par un firewall par exemple
En absence d'accès Ssh, la lecture des logs sous rescue peut te dire ce qu'il en était.

guardian
04/01/2016, 11h16
Citation Envoyé par Nowwhat
Jai l'impression que ton IP 1xx.xxx.xxx.xx8 n'existe même pas.
Je viens de vérifier sur mon panneau de contrôle, c'est bien l'IP qui m'est indiquée dessus.
Elle fonctionnait parfaitement le premier jour, puis pouf, plus rien.

Nowwhat
04/01/2016, 11h08
Jai l'impression que ton IP 1xx.xxx.xxx.xx8 n'existe même pas.

guardian
04/01/2016, 10h44
Citation Envoyé par Nowwhat
Moi : ***
C'est noté je vais vous envoyer ça. Vous pouvez retirer votre adresse si vous voulez.

Nowwhat
04/01/2016, 10h39
Moi : postmaster[b]@[b]nowwhat.ovh

guardian
04/01/2016, 10h34
Citation Envoyé par Abazada
Ok. Fais la manip: réinstalle un vps; vérifie qu'il tourne; ne touche à rien et reviens dans 24h.
On parie quoi qu'il tournera encore ?

Que tu le veuilles ou non, le problème vient - à 99.999% - de ce que tu as ajouté/supprimé/modifié sur le serveur,
mais ça seul toi le sais puisque tu ne nous dis rien.
Si ce que j'ai installé est le problème, alors comment expliquez vous que la réinstallation complète de l'OS n'ait rien résolu? Ce que vous dites ne me parait pas logique.

Comment le sais-tu ? vu que tu dis ne plus pouvoir te connecter Ssh.
Si Apache est tombé (peu probable), que dit le log d'erreur ?
Je n'ai pas accès au log d'erreur puisque je n'ai pas accès au serveur. Et je le sais car l'IP est devenue injoignable par le protocole http, depuis n'importe quel ordinateur.

Il n'y a pas besoin de "correctifs de sécurité" sur un Debian 8 de base (sauf cas très particuliers et rares)
Et pour apache? Il n'y a pas de correctifs de sécurité?

Mon intuition irait vers un Fail2Ban (ou similaire) mal installé/configuré et qui te bloque l'accès, voire le bloque à tout le monde !
Possible mais ça ne se passe pas au niveau de mon serveur car même une réinstallation complète de l'OS via le panneau de contrôle ne change rien.

Citation Envoyé par fritz2cat
Non ce n'est pas assez clair.

T'inquiète, dès qu'un serveur est allumé avec une IP publique, il y a des scans incessants venant des 4 coins du monde sur tous les services ouverts, à la recherche de failles, de mots de passe triviaux, des URL en unicode, des tests d'open-relay SMTP, et j'en passe des meilleures.

Un timeout ça peut provenir de n'importe lequel des noeuds par lesquels passe ton traceroute (tiens publie-le celui-là stp), ça peut être un firewall configuré à la sauce "oops j'ai mangé la clé", voire même de ton firewall windows chez toi à la maison.
12 *.*.*.* rapports : Impossible de joindre l'hôte de destination.

Ma configuration personnelle n'a rien à voir dans ce problème puisque après avoir commandé un nouveau serveur l'accès ssh fonctionnait . A chaque fois ça a cessé de fonctionner après 24h.

Puisque tu as l'air parano et demi, à moins que ton business ne soit dans la parfaite illégalité, je ne vois pas de raison de ne vouloir rien dévoiler.
Évitons les attaques personnelles Monsieur. Ce n'est vraiment pas très sérieux. Conduisez vous en adulte.

fritz2cat
04/01/2016, 09h11
Citation Envoyé par guardian
timeout, ça me parait assez clair
Non ce n'est pas assez clair.

T'inquiète, dès qu'un serveur est allumé avec une IP publique, il y a des scans incessants venant des 4 coins du monde sur tous les services ouverts, à la recherche de failles, de mots de passe triviaux, des URL en unicode, des tests d'open-relay SMTP, et j'en passe des meilleures.

Un timeout ça peut provenir de n'importe lequel des noeuds par lesquels passe ton traceroute (tiens publie-le celui-là stp), ça peut être un firewall configuré à la sauce "oops j'ai mangé la clé", voire même de ton firewall windows chez toi à la maison.

Puisque tu as l'air parano et demi, à moins que ton business ne soit dans la parfaite illégalité, je ne vois pas de raison de ne vouloir rien dévoiler.

Abazada
04/01/2016, 09h07
Citation Envoyé par guardian
Il est parfaitement normal que je ne décolère pas quand j'achète des serveurs pour que 24h après ils deviennent inaccessibles.
Ok. Fais la manip: réinstalle un vps; vérifie qu'il tourne; ne touche à rien et reviens dans 24h.
On parie quoi qu'il tournera encore ?

Que tu le veuilles ou non, le problème vient - à 99.999% - de ce que tu as ajouté/supprimé/modifié sur le serveur,
mais ça seul toi le sais puisque tu ne nous dis rien.

Citation Envoyé par guardian
De plus Apache qui était installé et lancé ne fonctionne plus
Comment le sais-tu ? vu que tu dis ne plus pouvoir te connecter Ssh.
Si Apache est tombé (peu probable), que dit le log d'erreur ?

Citation Envoyé par guardian
je n'ai pas appliqué tous les correctifs de sécurité et si le serveur revenait en ligne, il y aurait un risque potentiel de sécurité
Il n'y a pas besoin de "correctifs de sécurité" sur un Debian 8 de base (sauf cas très particuliers et rares)


Mon intuition irait vers un Fail2Ban (ou similaire) mal installé/configuré et qui te bloque l'accès, voire le bloque à tout le monde !

guardian
04/01/2016, 08h32
Ce n'est pas une histoire de serveur caché, je n'ai pas appliqué tous les correctifs de sécurité et si le serveur revenait en ligne, il y aurait un risque potentiel de sécurité que je préfère éviter.

Je peux vous communiquer l'IP par mail si vous voulez bien me donner une adresse de contact.

Cordialement

Nowwhat
04/01/2016, 08h20
Citation Envoyé par guardian
...
je ne peux pas poster l'IP publiquement pour des raisons de sécurité
Ok .... planquer ton serveur sur le net ... pourquoi pas (sache que ton IP n'est pas un secret, les Russes, Chinois, tout l'US et n’oublie pas les moins gentils en Europe ne considère pas ton IP comme secret ..... ils sont déjà dessus depuis le début).

Si, par hasard, t'as 3,60 € quelque part, lou temporairement un VPS, puis communique son IP.
Fait tes tests, on t'as assiste.
Dès l'erreur trouvé, applique la solution sur ton serveur 'caché', puis débarrasse toi de ton test-VPS.

guardian
04/01/2016, 07h37
timeout, ça me parait assez clair

je ne peux pas poster l'IP publiquement pour des raisons de sécurité

fritz2cat
04/01/2016, 07h16
Pourrions-nous avoir quelque chose d'utile ? Une adresse IP, un nom de serveur, un message d'erreur ?

Parce qu'à la fin c'est juste du babillage dans cette conversation, et ça me pousse à croire dans une défaillance générale d'un interface chaise clavier, à moins d'une erreur dans la couche 8 OSI.

guardian
04/01/2016, 06h47
Bonjour Janus,

J'ai déjà essayé sans vpn, même chose, timeout

De plus apache qui était installé et lancé ne fonctionne plus, l'IP n'est plus accessible via http.

En ce qui me concerne, OVH ça ne fonctionne pas du tout. Je veux bien croire que vous n'avez aucun problème mais ça ne s'applique pas à moi.

Cordialement

janus57
03/01/2016, 16h27
Bonjour,

vous passer par un VPN je suppose ?

Si oui faite attention car certains utilisent des VPN/tor/autre pour s'amuser à lancer des (D)DoS/tentative hack (etc…) (déjà vécu) et le VAC OVH fait pas dans le détails pour savoir si c'est ou non un VPN qui attaque son réseau il bloque tout simplement.

Comme l'a dit @Abazada perso moi non plus j'ai jamais eu de VPS/instance Public Cloud en rade chez OVH, les seule fois ou je pouvais plus y accéder c'est tout simplement parce que j'avais mal config une sécurité qui m'a auto-banni.

Un petit tour dans le manager horizon pour avoir un accès genre KVM à la VM et hop j'ai sortie mon IP de la liste, corriger mon erreur et fait en sorte que cela ne se reproduit plus.

De plus vous ne donnez aucun détails, pas un petit fichier de log, pas de connexion ssh en mode verbose (-vvv ou activation des logs session sous putty), pas d'ip pour contrôler (même si vous voulez pas la donner c'est les 3/4 du temps le plus simple) nous même, rien

Cordialement, janus57

guardian
03/01/2016, 15h33
Citation Envoyé par Abazada
où tu te contentes d'indiquer "ça marche pô" ne servent à rien si tu n'indiques pas les messages d'erreur
Citation Envoyé par guardian
impossible de me connecter à la console ssh (timeout)
Il est parfaitement normal que je ne décolère pas quand j'achète des serveurs pour que 24h après ils deviennent inaccessibles. La dernière fois, même après une réinstallation complète je ne pouvais plus du tout y accéder sauf en mode rescue. Il y a définitivement qqch qui ne va pas chez ovh si on ne peut pas accéder à un serveur qui a subi une réinstallation complète.

A chaque fois je perds de l'argent et un temps fou à tout réinstaller, et comment imaginer qu'un manque de fiabilité pareil soit viable pour la production quand le support derrière est extrêmement lent. C'est la mort assurée pour n'importe quel professionnel.

Abazada
03/01/2016, 10h28
Bonjour Guardian,

Sérieusement, j'ai hésité avant de répondre, mais à voir tes problèmes précédents (comment passer root? comment monter un disk? ...) ce dont tu as besoin d'abord, c'est de lire un bon bouquin style "Debian pour les nulls"...

Tous tes messages où tu te contentes d'indiquer "ça marche pô" ne servent à rien si tu n'indiques pas les messages d'erreur et ce que tu as fait pour parvenir à ce résultat. Les Vps ne se cassent pas tout seuls

Enfin, je trouve fatigantes tes critiques incessantes envers les VPS et l'infrastructure OVH.
- Comment vos services peuvent à ce point manquer de fiabilité?
- Qui peut faire tourner un business sérieux sur une infrastructure pareille?
- Ce qui est sûr c'est que ce n'est pas viable pour la production.

etc.

Pour information, je n'ai plus un seul serveur dédié chez OVH. J'ai tout basculé sur des VPS, principalement des Instances VPS-SSD 1 et 2.
Ca tourne comme un charme et les performances n'ont absolument plus rien à voir avec celles des VPS des générations précédentes
Pas viable pour la production ? Ben voyons

Si maintenant tu veux nous donner un peu plus de détails, peut-être pourra-t-on t'aider, mais en attendant je ne vois rien dans ma boule de cristal

Bonne Année 2016 sur Vps OVH

guardian
03/01/2016, 07h56
ça y est ça recommence, nouveau serveur, nouvelle IP, hier ça fonctionnait aujourd'hui ça ne fonctionne plus
impossible de me connecter à la console ssh (timeout), et apache qui a été installé ne tourne plus

Mais à quoi ça rime, qu'est ce que c'est que ce cirque? Comment vos services peuvent à ce point manquer de fiabilité? Qu'on m'explique, je suis perdu là.... Qui peut faire tourner un business sérieux sur une infrastructure pareille?

guardian
31/12/2015, 18h19
Tout le monde ne souhaite pas forcément publier l'ip de son serveur, et je n'ai pas accès à la messagerie privée du forum.
admin est bien le nom défini par ovh pour la connexion ssh, root ne fonctionne pas
les logs que je vous donne sont les seuls que j'ai puisque je n'ai accès à rien du tout hors mode rescue
debian 8 n'a rien changé à mon problème

toujours aucune nouvelle du ticket, je suis pas vraiment étonné, j'aurai une réponse dans une semaine et ça sera probablement à côté de la plaque

là je crois que je vais annuler tous les paiments et toutes les autorisations de paiement puis recommander un autre serveur
je perds en temps fou à chaque fois, je commence à me demander si ovh est vraiment une solution viable pour la production

janus57
31/12/2015, 17h45
Bonjour,

attention sur les public cloud (la dernière fois que j'ai testé) on peu pas se connecter directement en root et en plus il y a sudo.

Cordialement, janus57

Nowwhat
31/12/2015, 17h10
Citation Envoyé par guardian
...
Les ip font bien partie de mon réseau vpn, j'ignore ce que tu veux dire par rescue actif, j'ai posté tout le contenu du log auquel j'ai eu accès en mode rescue.
La, à 11:24:25 :
Dec 31 11:24:03 vm sshd[1820]: Server listening on 0.0.0.0 port 22.
Dec 31 11:24:03 vm sshd[1820]: Server listening on :: port 22.
Dec 31 11:24:25 vm sshd[1853]: Accepted publickey for admin from x.x.x.x port 57779 ssh2
Dec 31 11:24:25 vm sshd[1853]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Dec 31 11:24:46 vm sshd[1864]: Accepted publickey for admin from x.x.x.x port 57783 ssh2
Dec 31 11:24:46 vm sshd[1864]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Dec 31 11:24:46 vm sshd[1866]: subsystem request for sftp by user admin
on trouve bien un accès 'admin' (pas root ? - Debian utilise 'root' comme accès après installation) .
A ce moment, ton serveur été en mode rescue, ou mode 'normal' ?

Inutile de lister des logs avec des tentatives d'accès quand ton serveur fonctionne en mode rescue - t'as dit que ça fonctionne, donc le logs ne sont pas ntéressant à ce moment.

janus57
31/12/2015, 16h59
Bonjour,

Debian7 ?

Perso déjà je partirais sur un bon petit Debian8 le dernier en date avec quelques années de support devant lui.

Ensuite c'est quoi l'IP de votre VPS ?
Car si nous on peu arriver à faire une tentative de connexion c'est que vous avez modifié quelques chose sur le VPS ou fait quelque chose sur votre PC qui vous bloque au niveau SSH.

Cordialement, janus57

guardian
31/12/2015, 16h31
Merci Nowwhat, j'apprécie ton aide même si je dois avouer que je ne comprends pas grand chose.

Les ip font bien partie de mon réseau vpn, j'ignore ce que tu veux dire par rescue actif, j'ai posté tout le contenu du log auquel j'ai eu accès en mode rescue.

Je ne sais pas si fail2ban est inclu ou non, j'ai restauré l'OS debian 7 via le panneau de contrôle ce qui devrait avoir pour effet de restaurer les fichiers et paramètres par défaut auxquels je pouvais accéder sans problème. Il y a forcément un problème du côté d'OVH.

Il faut espérer que le staff OVH m'aide là, livrer une base non fonctionnelle et aucun support, ce n'est pas possible.

Nowwhat
31/12/2015, 14h21
Citation Envoyé par guardian
J'ai changé mon IP et j'ai toujours le même problème.
J'ai pensé aussi à un filtre IP imposé par OVH mais dans ce cas pourquoi j'aurais accès au serveur en mode rescue avec la même IP?
OVH ne filtre pas .... (quoi que si: la protection DDOS existe, mais je pense que t'es pas visé par lui)
En mode rescue, ce n'est pas ton 'kernel' qui démarre, mais un autre. C'est n'est pas "ton paramétrage" (entre autre dans le /etc/....) qui est utilisé pour le démarrage, mais le /etc fournie par le kernel de OVH.

Par contre :
Code:
Dec 31 11:24:03 vm sshd[1820]: Server listening on 0.0.0.0 port 22.
Dec 31 11:24:03 vm sshd[1820]: Server listening on :: port 22.
Dec 31 11:24:25 vm sshd[1853]: Accepted publickey for admin from x.x.x.x port 57779 ssh2
Dec 31 11:24:25 vm sshd[1853]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Dec 31 11:24:46 vm sshd[1864]: Accepted publickey for admin from x.x.x.x port 57783 ssh2
Dec 31 11:24:46 vm sshd[1864]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Dec 31 11:24:46 vm sshd[1866]: subsystem request for sftp by user admin
Mode rescue actif, ou non ?

Qui est x.x.x.x ? Toi ?
T'as eu donc accès.
Mode rescue alors, ou pas ?


Dec 31 12:41:43 vps sshd[1752]: Server listening on 0.0.0.0 port 22.
Dec 31 12:41:43 vps sshd[1752]: Server listening on :: port 22.
Dec 31 12:42:40 vps sshd[1783]: reverse mapping checking getaddrinfo for * [y.y.y.y] failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 31 12:42:46 vps sshd[1783]: Accepted publickey for admin from y.y.y.y port 59044 ssh2
Dec 31 12:42:46 vps sshd[1783]: pam_unix(sshd:session): session opened for user admin by (uid=0)

Dec 31 12:43:10 vps sshd[1781]: fatal: Read from socket failed: Connection reset by peer [preauth]

Qui est y.y.y.y ??
Toi ?
T'a eu accès ?! il me semble oui, car "Accepted publickey for admin from y.y.y.y port 59044 ssh2"

Mode rescue ou pas ?^( j’espère pas que ce n'est pas toi, un IP sans reverse, ça le fait bien en Russie ou Chine, ou chez ceux qui pensent qu'on se cacher sur le net )
=> T'as utilisé quoi pour changer ton IP ? Un VPN ? (si oui, bravo .... )

T'as fail2ban actif sur ton serveur (lui, il va probablement mordre dès qu'il trouve un "POSSIBLE BREAK-IN ATTEMPT") ? Si oui, désactive-le pour le moment.

Chaque fois, on voit bien que le service ssh démarre ....

guardian
31/12/2015, 13h54
Citation Envoyé par Nowwhat
T'as testé à partir d'un autre PC, et surtout; à partir d'un autre IP ?
J'ai changé mon IP et j'ai toujours le même problème.
J'ai pensé aussi à un filtre IP imposé par OVH mais dans ce cas pourquoi j'aurais accès au serveur en mode rescue avec la même IP?

guardian
31/12/2015, 13h48
Code:
Dec 31 11:24:01 vm useradd[1765]: new group: name=admin, GID=1000
Dec 31 11:24:01 vm useradd[1765]: new user: name=admin, UID=1000, GID=1000, home=/home/admin, shell=/bin/bash
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to group 'adm'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to group 'dialout'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to group 'cdrom'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to group 'floppy'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to group 'audio'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to group 'dip'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to group 'video'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to group 'plugdev'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to shadow group 'adm'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to shadow group 'dialout'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to shadow group 'cdrom'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to shadow group 'floppy'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to shadow group 'audio'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to shadow group 'dip'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to shadow group 'video'
Dec 31 11:24:01 vm useradd[1765]: add 'admin' to shadow group 'plugdev'
Dec 31 11:24:03 vm sshd[1820]: Server listening on 0.0.0.0 port 22.
Dec 31 11:24:03 vm sshd[1820]: Server listening on :: port 22.
Dec 31 11:24:25 vm sshd[1853]: Accepted publickey for admin from x.x.x.x port 57779 ssh2
Dec 31 11:24:25 vm sshd[1853]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Dec 31 11:24:46 vm sshd[1864]: Accepted publickey for admin from x.x.x.x port 57783 ssh2
Dec 31 11:24:46 vm sshd[1864]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Dec 31 11:24:46 vm sshd[1866]: subsystem request for sftp by user admin
Dec 31 12:41:43 vps sshd[1752]: Server listening on 0.0.0.0 port 22.
Dec 31 12:41:43 vps sshd[1752]: Server listening on :: port 22.
Dec 31 12:42:40 vps sshd[1783]: reverse mapping checking getaddrinfo for * [y.y.y.y] failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 31 12:42:46 vps sshd[1783]: Accepted publickey for admin from y.y.y.y port 59044 ssh2
Dec 31 12:42:46 vps sshd[1783]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Dec 31 12:43:10 vps sshd[1781]: fatal: Read from socket failed: Connection reset by peer [preauth]

Nowwhat
31/12/2015, 13h29
mon serveur est il mort et qui contacter?
puis;
Je viens de réinstaller complètement au cas où j'aurais commis une erreur et bien non toujours impossible de me connecter, sauf en mode rescue.
"Installer un OS" ou "réussir connecter en mode rescue" ne peut correspondre avec "serveur mort".

admin@**:/$ /var/log/auth.log
-bash: /var/log/auth.log: Permission denied
Effectivement, t'as un soucis la.
Tu essaie d'exécuter /var/log/auth.log ? [ ]
bash te dit à juste titre qu'il n'a pas le droit.
On ne peut pas 'exécuter' /var/log/auth.log, il faut le 'lire' (afficher).

T'as testé avec
Code:
cat /var/log/auth.log
?

Possible que tout nous fournisse l'IP ?
Ça arrive trop souvent que l'admin arrive à bannir son propre IP (parafue chargé au démarrage et tout le monde sauf l'admin à accès).
T'as testé à partir d'un autre PC, et surtout; à partir d'un autre IP ?

guardian
31/12/2015, 12h51
Si même après réinstallation complète de l'OS, l'accès ssh reste HS, ce n'est pas de mon côté qu'il y a problème.
Un intervention du staff serait vraiment appréciée.

guardian
31/12/2015, 12h45
Citation Envoyé par sich
Ouvre un ticket auprès du support ça sera + efficace...
ovh a ignoré quasiment systématiquement tous mes tickets, si vous savez comment obtenir une réponse à un ticket, je veux bien connaitre la recette

J'aimerais bien vous montrer les logs mais en mode rescue, je n'ai accès à peu près à rien!

Code:
admin@**:/$ /var/log/auth.log
-bash: /var/log/auth.log: Permission denied
Janus oui j'utilise bien la clé, autrement je ne pourrais pas y accéder en mode rescue. La seule erreur que putty fournit c'est "connexion timeout", pourtant j'ai tenté un ping sur l'IP est j'obtiens 0% de perte.

janus57
31/12/2015, 11h29
Bonjour,

avant de contacter le support OVH c'est quoi votre message d'erreur ? IP de votre serveur ?

Vous utilisez bien votre clé SSH que vous avez entré dans le manager cloud ?

Cordialement, janus57

Nowwhat
31/12/2015, 11h28
Commençons par la vraie début :
Ton NIC ?
Ton OS installé ?
La version de Putty (si t'as un PC) que tu utilise ?
T'as accès en mode rescue ?!!! Donc c'est très facile de basculer le service ssh en mode 'debug', redémarrer le serveur en mode 'normal', faire un essaie de connexion, puis redémarrer en mode rescue et voir dans le log de ssh pourquoi et comment ....

J'aimerais bien qu'on me dise ce qui s'est passé....
C'est possible dès que tu nous montre les logs - PERSONNE à accès à ton serveur, même pas OVH.

sich
31/12/2015, 11h17
Ouvre un ticket auprès du support ça sera + efficace...

guardian
31/12/2015, 11h05
Franchement il y a qqch qui ne tourne pas rond du côté de chez OVH, comment l'accès ssh peut il être non fonctionnel même après une réinstallation complète?

guardian
31/12/2015, 10h21
Bonjour,

Moins de 24h après la livraison de mon serveur, impossible de m'y connecter par ssh. Pourquoi l'accès ne fonctionne plus?

Je viens de réinstaller complètement au cas où j'aurais commis une erreur et bien non toujours impossible de me connecter, sauf en mode rescue.

J'aimerais bien qu'on me dise ce qui s'est passé....

Cordialement