En toute logique ce devrait rater parce que le port est déjà pris par une première instance de ssh mais ça permettra de savoir si le problème vient de l'initscript.

Ca fonctionne, j'ai un [ok]

Ok. Étonnant que le port ne pose pas de problème.

Le SSH du système rescue est sur quel port ? Et le SSH du système défaillant est supposé être sur quel port ?
Que donne un" ss -lpt | grep ssh" avant et après le démarrage de SSH depuis le système de secours ?

Cordialement

idem j'ai refait une batterie de tests dans les différents "rc" :
sudo ssh reload => ok
sudo iptables... => firewall ok
tous les tests sont passés. WTF !

Que fait le script de firewall ? Est ce un script custom ou bien est ce que ça vient d'un paquet debian ?

Quelles sont les règles installées une fois le script exécuté ? Utiliser les commandes "iptables -S" et "ip6tables -S".

J'ai vu dans les logs que le réseau utilisait un DHCP. Est ce que l'adresse utilisée pour se connecter est bien l'adresse attribuée par le DHCP ?

Cordialement

Bonjour et merci !

Port 22 pour le rescue. A la base j'avais changé le port pour 2222 en modifiant tout ce qui va bien côté firewall.

Voilà ce que donne ss -lpt |grep ssh :

Rescue
$sudo ss -lpt |grep ssh
LISTEN 0 128 *:ssh *:* users:(("sshd",1812,3))

Dans le mount
# ss -lpt |grep ssh
LISTEN 0 128 *:ssh *:*


Mon sshd_config ressemble à ça :
https://github.com/JoeKun/debian-config ... shd_config

Fichier firewall avec ouvertures sur les 2 ports dans le doute Sans KVM le iptables -s me renvoie les infos du mode rescue et non du serveur à proprement parler.
Côté DHCP, c'est fourni par le prestataire et c'est bien la même.

Voilà ce que donne ss -lpt |grep ssh :

Rescue
$sudo ss -lpt |grep ssh
LISTEN 0 128 *:ssh *:* users:(("sshd",1812,3))

Dans le mount
# ss -lpt |grep ssh
LISTEN 0 128 *:ssh *:*

Est-ce que c'est bien après avoir exécuté SSH dans le mount par "invoke-rc.d ssh start" ?
Parce que là je ne vois qu'un seul démon ssh, ce qui veut dire que l'initscript te dit "ok" mais ne démarre rien.

Mon sshd_config ressemble à ça :
https://github.com/JoeKun/debian-config ... shd_config

"Ressemble" ça veut dire qu'il y a des différences. C'est justement ces différences qui sont intéressantes !

Fichier firewall avec ouvertures sur les 2 ports dans le doute

Code : Tout sélectionner

!/bin/sh #Réinitialise les règles sudo iptables -t filter -F sudo iptables -t filter -X #sudo iptables -t filter -A INPUT -i lo -j ACCEPT #sudo iptables -t filter -A OUTPUT -o lo -j ACCEPT # ICMP (Ping) sudo iptables -t filter -A INPUT -p icmp -j ACCEPT sudo iptables -t filter -A OUTPUT -p icmp -j ACCEPT # SSH sudo iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT sudo iptables -t filter -A INPUT -p tcp --dport 2222 -j ACCEPT sudo iptables -t filter -A OUTPUT -p tcp --dport 2222 -j ACCEPT

Là je vois un problème, c'est que je ne vois pas où est fixée la politique par défaut ("iptables -P INPUT DROP" par exemple), sachant que s'il n'y a pas de politique par défaut, cela veut dire qu'elle est à ACCEPT et donc que ton fichier ne sert à rien puisque tout le trafic est accepté.
A moins que la politique par défaut soit fixée dans un autre script, et là un second problème arrive, c'est que tu autorises le trafic vers ton serveur SSH en entrée ("iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT") mais pas en sortie. Tes règles OUTPUT n'ont aucun effet sur le trafic de ton démon SSH, elles ne permettent que d'autoriser d'exécuter des connexions SSH depuis ton serveur vers d'autres machines.
Si le même script est en place depuis longtemps, je pencherais plutôt vers la première option, c'est à dire que tu ne filtres rien.

Sans KVM le iptables -s me renvoie les infos du mode rescue et non du serveur à proprement parler.

Evidemment, mais j'entendais que tu réexécutes l'initscript de ton firewall puis que tu en captures le résultat.

Cordialement

Re,

Voilà ce j'ai (re)fait.

J’ai lance manuellement le script firewall se trouvant dans : Voici le résultat alors qu’avant je n’avais rien.
Modification du script firewall : Je relance : resultat : Le ICMP a bien disparu tu vois.

Pour le ssh_config c'est le même fichier

J'en perds mon latin...

Donc ça confirme une chose, c'est que ton firewall ne filtre rien, car la politique par défaut est ACCEPT.
Tu peux donc totalement exclure le firewall de la liste des sources de problème (sauf si fail2ban est installé).

Il reste la question suivante :

Voilà ce que donne ss -lpt |grep ssh :

Rescue
$sudo ss -lpt |grep ssh
LISTEN 0 128 *:ssh *:* users:(("sshd",1812,3))

Dans le mount
# ss -lpt |grep ssh
LISTEN 0 128 *:ssh *:*

Est-ce que c'est bien après avoir exécuté SSH dans le mount par "invoke-rc.d ssh start" ?
Parce que là je ne vois qu'un seul démon ssh, ce qui veut dire que l'initscript te dit "ok" mais ne démarre rien.

Re,

J'ai repris la main sur le serveur apparemment le hostname posait problème, je dis bien apparemment car j'ai essayé de rechanger les valeurs pour reproduire l'erreur et je n'y suis pas arrivé, c'est incompréhensible !

Dans mon fichier hostname, à la base, j'avais un petit nom disgracieux de machine, elle avait été renommée par le domaine megadeth.fr (plus de gueule, non ?) au niveau de la console et du hostname donc. C'est revenu à la "normale"...

Sauf que maintenant j'ai un souci. quand je redémarre mon serveur et que je me connecte en ssh je suis en root@(none)

J'ai suivi ce "tuto" mais rien n'y fait :
http://www.ndlaprovidence.org/html/clar ... dReq=LINUX

Une idée ?

Merci pour vos posts qui m'ont beaucoup aidé.

Mega