Network error : connexion refused
Fermé
cocodu67...
Messages postés
3153
Date d'inscription
jeudi 28 janvier 2010
Statut
Membre
Dernière intervention
4 avril 2024
-
Modifié le 29 oct. 2018 à 18:42
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 1 nov. 2018 à 15:35
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 1 nov. 2018 à 15:35
A voir également:
- Network error occurred traduction
- Network error ✓ - Forum Réseaux sociaux
- Network error iptv - Forum Réseaux sociaux
- Fan error lenovo ✓ - Forum Refroidissement
- Efi pxe network ✓ - Forum Windows 10
- Cmos checksum error ✓ - Forum Carte-mère/mémoire
1 réponse
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
30 oct. 2018 à 10:09
30 oct. 2018 à 10:09
Bonjour,
Tu peux vérifier côté client les ports qui sont ouverts avec
Exemple : lance cette commande depuis le client et remplace localhost par l'IP ou le FQDN de ton serveur.
Si le port 22 est ouvert en mode "rescue" mais pas en mode "normal", deux explications sont possibles :
- soit le serveur ssh n'est pas lancé en mode "normal" (plantage ? -- mais dans ce cas, pourquoi marcherait il en mode "rescue")
- soit le port 22 est bloqué côté serveur (puisqu'en mode "rescue" ça marche), ce qui signifierait que le pare-feu n'est pas lancé en mode "rescue".
Dans ce cas, il faut que débloque ce port. Si ufw est installé tu peux utiliser ça, sinon cf iptables.
Bonne chance
Tu peux vérifier côté client les ports qui sont ouverts avec
nmap. Tu pourras ainsi comparer s'il y a une différence de comportement entre le mode "normal" et le mode "rescue".
Exemple : lance cette commande depuis le client et remplace localhost par l'IP ou le FQDN de ton serveur.
(mando@silk) (~) $ nmap localhost
Starting Nmap 7.70 ( https://nmap.org ) at 2018-10-30 10:05 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000057s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 995 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
111/tcp open rpcbind
631/tcp open ipp
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
Si le port 22 est ouvert en mode "rescue" mais pas en mode "normal", deux explications sont possibles :
- soit le serveur ssh n'est pas lancé en mode "normal" (plantage ? -- mais dans ce cas, pourquoi marcherait il en mode "rescue")
- soit le port 22 est bloqué côté serveur (puisqu'en mode "rescue" ça marche), ce qui signifierait que le pare-feu n'est pas lancé en mode "rescue".
Dans ce cas, il faut que débloque ce port. Si ufw est installé tu peux utiliser ça, sinon cf iptables.
sudo iptables -A INPUT -p tcp -i eth0 --dport ssh -j ACCEPT
Bonne chance
Modifié le 30 oct. 2018 à 13:38
Mon ticket chez Online avait été transféré chez un technicien et d'après ce que vous montrez là il a fait un nmap justement car il m'a montré les ports et à côté du 21 et 22 c'était marqué "closed".
En mode rescue bien sûr c'est ouvert, mais pas en mode normal.
Il m'avait parlé de monter les partitions sur le mode rescue de façon à modifier, j'imagine, les règles IPTABLES en place lors du redémarrage, et il m'aurait alors suffit de redémarrer et ça aurait été réglé. Sauf que je ne sais pas faire, et même si j'avais accès aux partitions, je ne sais pas régler les règles en place au démarrage ...
Du coup j'ai réinstallé et pour le moment ça a l'air d'aller.
Mais je ne comprend vraiment pas comment ça puisse être possible que je m'y connecte via SSH et FTP, que je transfère des fichiers et bases de données, que tout va bien, que je relance même le serveur plusieurs fois en me déconnectant donc du FTP et SSH, qu'une fois rallumé tout va bien, que je m'y reconnecte 2-3 jours après pour vérifier un truc, que tout va bien, que je me déconnecte, et que quelque jours après les ports 21 et 22 soient fermés ... ça n'a aucun sens.
Et je crains vraiment que le problème survienne à nouveau ...
1 nov. 2018 à 15:35
Ce que je te recommande, c'est de bien spécifier dans ta configuration que le port 22 doit rester ouvert.
Et je t'invite aussi vivement à faire des authentification avec une clé ssh et n'autoriser que ce genre d'authentification pour réduire les risques d'intrusion.
https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-2
Bonne chance