[RESOLU]ssh: connect to host XXX port 22: Connection refused

WolwX Février 21, 2016, 12:04am #1

Bonjour messieurs

Je viens à vous avec un bug des plus ennuyeux …

Après quelques petites tâches de modif Kernel sur mon serveur dédié, je me suis tourné vers un reboot machine, et paf …

Je n’ai plus accès au SSH de ma machine !

Assez ennuyant pour un serveur dédié …

Concernant ce que j’ai fait peu avant le reboot précédent le bug son des manips de fichiers script lancé automatiquement toutes les 5 min (un script adaptant le nice et renice de chaque user), ainsi qu’une désactivation au boot de exim4 …
Pour le reste je vois pas trop

Donc voici ce que j’ai cherché de mon coté, sans trouver la solution :

Vérification du poste client OK
connexion sur d’autre dédié en SSH fonctionnel

Vérification réseaux de la machine dédié non répondante OK
ping ok et passage en mode “rescue” fonctionnel avec accès SSH …

Je suis donc passé en SSH sur un mode rescue, et j’ai jeté un oeil dans les logs aussi bien que dans la config ssh.

Dans les logs, après le reboot, plus de trace de SSH :s
Même pas une trace de scan comme on en à toujours des tonnes

Coté config du ssh, j’ai vérifié le fichier etc/ssh/sshd_config en prenant le soin de décommenter les lignes listen pour le coup

Autre piste je suis passé voir si le lancement automatique semblait ce faire, mais de ce coté je pêche un peu beaucoup, donc outre avoir vérifier l’existence du fichier ssh dans etc/init.d et dans etc/rc0.d …

Alors me voilà, à m’en remettre à messieurs les gourous de Debian ^^

Help pleaseeeeeeeeeeeeeee

Copie ssh refusé

fran.b Février 21, 2016, 12:04am #2

Que dit le ficher daemon.log?

WolwX Février 21, 2016, 12:04am #3

Nov 17 10:26:14 n1-SerVerS ntpd[1704]: adjusting local clock by 0.202927s Nov 17 11:33:48 n1-SerVerS ntpd[1704]: adjusting local clock by 0.174187s Nov 17 11:44:00 n1-SerVerS ntpd[1704]: adjusting local clock by 0.286294s Nov 17 11:48:13 n1-SerVerS ntpd[1704]: adjusting local clock by 0.219258s Nov 17 11:50:48 n1-SerVerS ntpd[1704]: adjusting local clock by 0.200050s Nov 17 11:51:48 n1-SerVerS ntpd[1704]: adjusting local clock by 0.179538s Nov 17 12:06:53 n1-SerVerS init: Switching to runlevel: 6 Nov 17 12:07:00 n1-SerVerS rpc.statd[1721]: Caught signal 15, un-registering and exiting. Nov 17 12:07:01 n1-SerVerS ntpd[1704]: Terminating

C’est grave docteur ?

PascalHambourg Février 21, 2016, 12:04am #4

Les logs de sshd sont plutôt envoyés dans dans auth.log. Je n’en ai jamais vus dans daemon.log.
Quid des autres services réseau ?

WolwX Février 21, 2016, 12:04am #5

[quote=“PascalHambourg”]Les logs de sshd sont plutôt envoyés dans dans auth.log. Je n’en ai jamais vus dans daemon.log.
Quid des autres services réseau ?[/quote]

coté auth.log =>

Nov 17 11:45:01 n1-SerVerS CRON[17725]: pam_unix(cron:session): session opened $ Nov 17 11:45:01 n1-SerVerS CRON[17724]: pam_unix(cron:session): session opened $ Nov 17 11:45:01 n1-SerVerS CRON[17724]: pam_unix(cron:session): session closed $ Nov 17 11:45:01 n1-SerVerS CRON[17725]: pam_unix(cron:session): session closed $ Nov 17 11:50:01 n1-SerVerS CRON[17795]: pam_unix(cron:session): session opened $ Nov 17 11:50:01 n1-SerVerS CRON[17794]: pam_unix(cron:session): session opened $ Nov 17 11:50:01 n1-SerVerS CRON[17795]: pam_unix(cron:session): session closed $ Nov 17 11:50:01 n1-SerVerS CRON[17794]: pam_unix(cron:session): session closed $ Nov 17 11:55:01 n1-SerVerS CRON[17866]: pam_unix(cron:session): session opened $ Nov 17 11:55:01 n1-SerVerS CRON[17865]: pam_unix(cron:session): session opened $ Nov 17 11:55:02 n1-SerVerS CRON[17866]: pam_unix(cron:session): session closed $ Nov 17 11:55:02 n1-SerVerS CRON[17865]: pam_unix(cron:session): session closed $ Nov 17 12:00:01 n1-SerVerS CRON[17935]: pam_unix(cron:session): session opened $ Nov 17 12:00:01 n1-SerVerS CRON[17936]: pam_unix(cron:session): session opened $ Nov 17 12:00:01 n1-SerVerS CRON[17937]: pam_unix(cron:session): session opened $ Nov 17 12:00:01 n1-SerVerS CRON[17937]: pam_unix(cron:session): session closed $ Nov 17 12:00:01 n1-SerVerS CRON[17936]: pam_unix(cron:session): session closed $ Nov 17 12:00:01 n1-SerVerS CRON[17935]: pam_unix(cron:session): session closed $ Nov 17 12:05:01 n1-SerVerS CRON[18012]: pam_unix(cron:session): session opened $ Nov 17 12:05:01 n1-SerVerS CRON[18011]: pam_unix(cron:session): session opened $ Nov 17 12:05:01 n1-SerVerS CRON[18012]: pam_unix(cron:session): session closed $ Nov 17 12:05:02 n1-SerVerS CRON[18011]: pam_unix(cron:session): session closed $

Visiblement c’est le blackout sur la machine :s

Elle répond au ping mais l’OS ne semble pas ce charger …

En effet j’ai relancer un reboot simple et laisser pendant plus d’une heure, et on voit clairement que rien ne ce passe sur la machine depuis ce dernier reboot de 12h05 …

Encore plus flagrant avec le syslog =>

Nov 17 11:30:01 n1-SerVerS /USR/SBIN/CRON[17504]: (root) CMD (/home/n1-SerVe$ Nov 17 11:33:48 n1-SerVerS ntpd[1704]: adjusting local clock by 0.174187s Nov 17 11:35:01 n1-SerVerS /USR/SBIN/CRON[17578]: (root) CMD (wget http://ma$ Nov 17 11:35:01 n1-SerVerS /USR/SBIN/CRON[17580]: (root) CMD (/home/n1-SerVe$ Nov 17 11:39:01 n1-SerVerS /USR/SBIN/CRON[17645]: (root) CMD ( [ -x /usr/li$ Nov 17 11:40:01 n1-SerVerS /USR/SBIN/CRON[17655]: (root) CMD (wget http://ma$ Nov 17 11:40:01 n1-SerVerS /USR/SBIN/CRON[17658]: (root) CMD (/home/n1-SerVe$ Nov 17 11:44:00 n1-SerVerS ntpd[1704]: adjusting local clock by 0.286294s Nov 17 11:45:01 n1-SerVerS /USR/SBIN/CRON[17727]: (root) CMD (wget http://ma$ Nov 17 11:45:01 n1-SerVerS /USR/SBIN/CRON[17729]: (root) CMD (/home/n1-SerVe$ Nov 17 11:48:13 n1-SerVerS ntpd[1704]: adjusting local clock by 0.219258s Nov 17 11:50:01 n1-SerVerS /USR/SBIN/CRON[17797]: (root) CMD (wget http://ma$ Nov 17 11:50:01 n1-SerVerS /USR/SBIN/CRON[17799]: (root) CMD (/home/n1-SerVe$ Nov 17 11:50:48 n1-SerVerS ntpd[1704]: adjusting local clock by 0.200050s Nov 17 11:51:48 n1-SerVerS ntpd[1704]: adjusting local clock by 0.179538s Nov 17 11:53:19 n1-SerVerS kernel: [62018.336889] UDP: short packet: From 79$ Nov 17 11:55:01 n1-SerVerS /USR/SBIN/CRON[17868]: (root) CMD (wget http://ma$ Nov 17 11:55:01 n1-SerVerS /USR/SBIN/CRON[17870]: (root) CMD (/home/n1-SerVe$ Nov 17 12:00:01 n1-SerVerS /USR/SBIN/CRON[17939]: (root) CMD (/home/n1-SerVe$ Nov 17 12:00:01 n1-SerVerS /USR/SBIN/CRON[17941]: (root) CMD (wget http://ma$ Nov 17 12:00:01 n1-SerVerS /USR/SBIN/CRON[17940]: (root) CMD (rm cron.php.*;$ Nov 17 12:05:01 n1-SerVerS /USR/SBIN/CRON[18014]: (root) CMD (wget http://ma$ Nov 17 12:05:01 n1-SerVerS /USR/SBIN/CRON[18016]: (root) CMD (/home/n1-SerVe$ Nov 17 12:06:53 n1-SerVerS shutdown[18063]: shutting down for system reboot Nov 17 12:06:53 n1-SerVerS init: Switching to runlevel: 6 Nov 17 12:07:00 n1-SerVerS rpc.statd[1721]: Caught signal 15, un-registering$ Nov 17 12:07:01 n1-SerVerS ntpd[1704]: Terminating

J’ai un soucis ailleurs aie aie aie

Sachant que j’ai manipuler le kernel, ça peut venir de là …

Je regarde ça de plus prêt et je vous tiens au courant

PascalHambourg Février 21, 2016, 12:04am #6

C’est la première chose à vérifier, en redémarrant sur l’ancien noyau. (Tu l’as bien gardé, n’est-ce pas ?)
Comme la machine répond au ping, cela signifie que le démarrage arrive au moins à l’activation du réseau. Peut-être /usr ou autre qui ne se monte pas, s’il est sur un sytème de fichiers séparé de la racine, ou bien le runlevel 2 qui ne s’enclenche pas.

fran.b Février 21, 2016, 12:04am #7

Pascal: je pensais à un message d’erreur dans le lancement de ssh.

Est ce qu’un telnet sur le port 22 te renvoit une banière SSH genre?

[quote]Escape character is ‘^]’.
SSH-1.99-OpenSSH_4.3p2 Debian
[/quote]

Sinon il faut voir du coté des règles iptables ou bien du coté du fichier sshd_config du serveur ou même si le binaire est accessible…

[edit: hum, ça a l’air d’être la dernière possibilité…]

WolwX Février 21, 2016, 12:04am #8

[quote=“PascalHambourg”]C’est la première chose à vérifier, en redémarrant sur l’ancien noyau. (Tu l’as bien gardé, n’est-ce pas ?)
Comme la machine répond au ping, cela signifie que le démarrage arrive au moins à l’activation du réseau. Peut-être /usr ou autre qui ne se monte pas, s’il est sur un sytème de fichiers séparé de la racine, ou bien le runlevel 2 qui ne s’enclenche pas.[/quote]

Justement j’ai pensé au SSH car lors de mes précédentes manipulation de Kernel (en fait je renseigné simplement un autre kernel de boot), lorsque ça ne fonctionné pas, je n’avais carrément pas de ping …

Sur ce coup le ping répondait bien, j’ai donc pris le temps de tester en remettant le kernel d’origine mais sans succès …

Enfin après énième vérification, je me suis décider à nettoyer le menu.lst afin d’y laisser seulement le kernel adéquat, et paf … tout remarche !

Désolé pour la fausse alerte, et en tout cas, merci encore à vous deux qui êtes vraiment des piliers de ce forum, et même je dirais des piliers très solide

PascalHambourg Février 21, 2016, 12:04am #9

D’après ce que j’ai constaté, même ces messages sont dans auth.log.

Est-ce que tu n’aurais simplement pas mis par défaut une entrée de démarrage en mode single ? Cela expliquerait les symptômes : configuration du réseau mais pas de services ni de logs démarrés.

fran.b Février 21, 2016, 12:04am #10

D’après ce que j’ai constaté, même ces messages sont dans auth.log.[/quote]

Exact, même pour les erreurs critiques:

[quote]Nov 17 18:39:48 totoche sshd[16119]: error: Bind to port 25 on 0.0.0.0 failed: Address already in use.
[/quote]

C’est étonnant et illogique, j’aurais vu ça dans le syslog ou daemon.log plutôt.