Forum d'entraide PHPFrance

Bonjour,

Je rencontre un souci qui me laisse dubitatif.
Après un reboot de serveur je suis dans l'incapacité de me reconnecter à ce dernier en mode SSH :
Network connection refused
En mode rescue j'arrive bien à me connecter, j'arrive à monter mon disque, accéder aux fichiers, les modifier s'il le faut mais rien n'y fait.

Comment relancer mes services ?
Comment savoir ce qui bloque ?
Sachant que je n'ai pas la main physiquement sur le serveur.

Merci de votre aide.

Mega

Bonjour

Je vois 3 possibilités :
- Problème de serveur SSH qui ne démarre pas,
- de serveur SSH mal configuré
- de firewall/iptables qui bloquerait la connexion au port 22 ?

Pour la config de SSH, regarde le contenu du fichier : /etc/ssh/sshd_config

Salut @rthur,

Merci à toi.

Comment savoir si le ssh démarre ou pas ?
Je n'ai pas la main en local sur cette machine...

Pour la conf je suis sur de moi, j'ai même replacé le fichier initial.

Pour le firewall idem, j'ai replacé le fichier initial et retiré le fichier de scripts.
Ce n'est p'tet pas suffisant... Comment savoir si le firewall est bien retiré en mode rescue ?

Mega

En mode rescue, tu n'es pas réellement sur ta machine ou plus exactement ce n'est pas ton disque que tu vois si tu accèdes aux fichiers. C'est analogue à un boot sur live CD.

Par contre tu peux monter tes partitions pour vérifier tes log ou modifier ta configuration. Tu peux également faire un chroot pour être dans un environnement proche de ta machine. Pour trouver ton disque, ls /dev/sd* ou en raid logiciel ls /dev/md*.

Pour ce qui est de ssh, la dernière version de Debian interdit la connexion de root par défaut. Peut être une surprise de ce genre suite à une mise à jour.
iptables provoque fréquemment des blocages après reboot à cause de règles mis manuellement en ligne de commande et non reportées dans le script de démarrage.

Edit : il arrive aussi que le boot soit très long à cause d'une vérification du disque.

Bonjour,

J'avais bien placé le curseur à "ON" pour le rootLogin.
Franchement je sèche, en mode rescue (j'ai pas KVM)
J'ai replacé le fichier firewall initial, rien n'y fait
Concernant iptables, je n'ai rien inséré à la mimine. Comment y accéder et faire un reset ?
A la base, dans /etc/init.d/ je n'avais pas de fichier firewall.
J'ai placé un fichier firewall, du classique avec un port différent.
J'ai essayé de supprimer le fichier firewall, remettre le port par défaut ou ouvrir tous les ports, rien n'y fait.
Connection refused.

Help, franchement je vois pas.

Mega

Bonjour,

Est-ce que tu as bien dans tes logs une notification de SSHD indiquant qu'il est lancé lors du démarrage de ton serveur ?
Tu dois trouver des lignes de ce genre dans ton auth.log, et bien entendu à la bonne date :
Cordialement

Salut Sékiltoyai et merci de te soucier également.
Je n'ai plus rien depuis le jour, la minute, la seconde où on a tenté de redémarrer.
Mon stagiaire a vu la key/pass phrase et a redémarré le serveur de façon intempestive, depuis... (ça a peut être aucun rapport)
Pas de connexion, pas de KVM, que du rescue...
J'ai à peu près tout tenté.
Avec ou sans firewall, avec les ports modifiés ou par défaut (port 22), tout m'est refusé.
fail2ban également.

Mega

Je n'ai plus rien depuis le jour, la minute, la seconde où on a tenté de redémarrer.

Si je comprends bien, ces éléments sont présents dans les logs jusqu'au jour du redémarrage et n'apparaissent plus depuis ? En clair, le fichier /var/log/auth.log n'a pas été modifié depuis la date du redémarrage ? Merci de vérifier avec un "ls -l" sur le fichier.

Est-ce le cas également pour le fichier /var/log/syslog ? Si des logs apparaissent, qu'indiquent-ils ?

Quel est l'OS et sa version exacte ? Y a-t-il eu une modification, une mise à jour notamment, avant le redémarrage ?

Cordialement

Salut,

C'est bien ça, rien depuis. j'arrive à me reconnecter en mode rescue mais c'est tout. Toute nouvelle connexion se conclue par un connection refused en ssh ou sftp.

Désolé pour ce pavé, voilà les extraits du syslog pour cette date (ci-dessous les dernières lignes de ce jour) l'OS c'est du debian7 x64
La seule modif faite c'est dans le php.ini, la directive allow_url_fopen passée de "off" à "on".
Le redémarrage était d'ailleurs pour prendre en compte cette modif mais après la passphrase (voulut être bypassée par le redémarrage), on a complètement perdu le signal... assez inédit pour moi.

Mega

La "suite" au dessus (trop de lignes de log)

Le redémarrage était d'ailleurs pour prendre en compte cette modif mais après la passphrase (voulut être bypassée par le redémarrage), on a complètement perdu le signal... assez inédit pour moi.

Qu'entends-tu exactement par "la passphrase (voulut être bypassée par le redémarrage)" ?

Cordialement

Une autre chose à tester, ce serait de tenter d'exécuter sshd depuis le système de rescue :
* Considérant que l'arborescence du système défaillant est dans /mnt/debian
* mount --bind /dev /mnt/debian/dev
* mount --bind /dev/pts /mnt/debian/dev/pts
* mount --bind /proc /mnt/debian/proc
* chroot /mnt/debian
* invoke-rc.d ssh start

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.

Cordialement

En fait. Il a voulu redémarrer, la pass phrase s'est affiché et n'ayant pas ce mot de passe, la panique ou je ne sais quoi, il a redémarré le serveur via une interface (équivalent reboot électrique)

Mega

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]

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 !