SSH Access denied durant installation dédié

Support Debian
#1

Bonjour a toutes et tous,

Je suis en train de préparer mon premier serveur dédié (digicube) sans passer par un panel.
Mes connaissances du monde gnu/linux et réseau sont relativement moyennes.

J’ai donc un serveur nu avec Debian squeeze auquel j’ai rajouté apache2+ssl/mysql+phpmyadmin/php5.
J’ai installé IPTables/Fail2ban/Rkhunter/suhosin pour sécuriser un minimum.
J’ai désactivé les démons portmap et nfs.
J’ai installé webmin.
Je venais de paramétrer mes hôtes virtuels et comme c’était tard dans la nuit je suis allé me couché en ayant lancé un soft reboot.
Le lendemain en essayant de me connecter (avec putty) via ssh j’ai un beau acces denied (aussi bien sur le root que je comptais désactiver a la fin de mes installs que sur mon user principal).
J’ai essayé via connexion ssh depuis mon portable sous ubuntu, pareil.

Le ssh -vv indique aucune anomalie en dehors de permission denied (l’authentification est par mot de passe).

Je ne comprends pas trop d’où viendrait le problème car lors de l’installation de fail2ban j’avais testé le fonctionnement avant de l’intégrer au init.d

J’ai redémarré en mode rescue (trinity rescue kit chez digicube) mais je suis un peu perdu pour désactiver fail2ban dans ce mode (update-rc.d n’est pas reconnu dans ce mode).
J’ai également voulu voir les logs mais le dossier de log n’est pas accessible (visible mais pas atteignable).

A noter que l’accès a webmin n’est pas fonctionnel alors que son installation n’a renvoyé aucune erreur.

Avez-vous des idées sur l’origine du problème et sur comme désactiver les scripts dans init.d en mode rescue ?

Merci d’avance !

#2

Bonjour,

c’est un peu délicat de t’aider sur un serveur dédié, quels sont tes accès (ssh,ftp,…) exactement ?

Comment (par quel protocole) peux-tu te connecter à ta machine avec le “rescue kit” ? (je n’ai pas compris ce point)

(Peux-être s’agit-il juste d’un ftp ou sftp sur le disque de la machine?)

Après pour désactiver dans le init.d ,si tu es root avec un accès ssh, un moyen violent de faire serait de supprimer les droits d’exécution sur /etc/init.d/fail2ban

il y a probablement des façons plus débianesque de faire mais je ne les connais pas.

de mon point de vue il est difficile de t’aider sans connaitre exactement ce que te permet la prestation digicube (en l’état actuel)

#3

"c’est un peu délicat de t’aider sur un serveur dédié, quels sont tes accès (ssh,ftp,…) exactement ?"
Je peux me connecter uniquement par ssh.

"Comment (par quel protocole) peux-tu te connecter à ta machine avec le “rescue kit” ? (je n’ai pas compris ce point)"
Connexion par ssh mais sur un environnement réduit monté en RAM (par exemple les disques ne sont pas montés, les commandes sont limitées, voir la définition de trinity ici: trinityhome.org/Home/index.php?c … &locale=en ).

"Après pour désactiver dans le init.d ,si tu es root avec un accès ssh, un moyen violent de faire serait de supprimer les droits d’exécution sur /etc/init.d/fail2ban
chmod -x /etc/init.d/fail2ban"
Je n’y ai pas pensé, en espérant que sous le rescue mode je puisse le faire.

Je vais tenter cela, en espérant que c’est fail2ban qui provoque cela, si vous pensez a un autre élément n’hésitez pas !

Merci.

#4

Bon j’ai bien fait le chmod -x sur fail2ban (et la coloration syntaxique me montre bien qu’il n’est plus exécutable) … mais après reboot, même punition :frowning:

D’autres idées à explorer ?

#5

si j’ai bien compris tu as un accès à ta machine par une sorte de LiveCD ,

pour accéder aux logs tu peux consulter la fstab qui est dans /etc/fstab

et avec un peu de chance tu auras une ligne genre

il t’es alors peut etre possible de monter /dev/sdxx à un point de montage comme /mnt

ce qui devrait te donner accès aux fichiers de logs dans /mnt

Le but de la manoeuvre est d’accéder au fichier auth.log et autres pour mieux comprendre pourquoi tu ne peux plus te connecter avec ton user

une autre piste serait de consulter la configuration ssh, je ne suis pas un expert mais aller voir dans /etc/ssh/sshd_config est peut-être une piste

#6

Bon pas accès aux logs, le cat ne me fourni pas de /etc/fstab avec l’accès au /var/log …

Question de noob en fs unix, si j’ai lors d’un ls le dossier log qui apparait sur fond rouge et avec un arobase attaché (log@) cela veut dire quoi ?

J’ai regardé du coté du sshd_config, et là …

trk ssh # ls ls: cannot access sshd_config: Input/output error moduli sshd_config ssh_host_dsa_key.pub ssh_host_rsa_key.pub ssh_config ssh_host_dsa_key ssh_host_rsa_key trk ssh # ls -ls ls: cannot access sshd_config: Input/output error total 148 128 -rw-r--r-- 1 root root 125749 2010-12-27 11:30 moduli 4 -rw-r--r-- 1 root root 1669 2010-12-27 11:30 ssh_config ? -????????? ? ? ? ? ? sshd_config 4 -rw------- 1 root root 672 2012-12-13 15:42 ssh_host_dsa_key 4 -rw-r--r-- 1 root root 604 2012-12-13 15:42 ssh_host_dsa_key.pub 4 -rw------- 1 root root 1679 2012-12-13 15:42 ssh_host_rsa_key 4 -rw-r--r-- 1 root root 396 2012-12-13 15:42 ssh_host_rsa_key.pub trk ssh #

Je pense que c’est pas bon :frowning: …
La session précédente je l’avais déjà ouvert pourtant.

Je vais le recréer a la mano et voir ce qui ce passe.
Mais je n’arrive pas a le supprimer ! comment faire ?

#7

Hello,

A mon avis ton “mode rescue” te fait démarrer ton serveur sur un noyau linux stocké en réseau. Il te faut donc monter ton disque dur local sur le système de fichiers de ce linux de secours. Je t’invite à lire la documentation d’OVH à ce sujet au chapitre “Rescue en SSH”.

#8

Merci, mais j’ai monté mes fs via mountallfs -l qui me monte /dev/sda1 et /dev/sda2 dans /sda1 et /sda2. A noter que le mode rescue d’OVH ne semble pas être le mien (je suis chez digicube).

Donc j’ai continué dans la voie sshd_config … mais ca empire …

Pas de apt dispo en mode rescue donc pas possible de refaire l’install d’openssh pour réinitialier tout cela.
Du coup j’ai renommé /ssh en /ssh2, recrée un /ssh et copié tout depuis /ssh2 sauf le fichier corrompu, puis recréé un sshd_config standard.
Soft reboot.

… puis plus rien, ping sur serveur mort.

Je vais me reconnecter en mode rescue dessus mais je ne sais pas quoi faire …

#9

Ton système de fichiers semble corrompu, fais un fsck des partitions

#10

Oui j’ai un problème sur le fichier sshd_config, c’est clair, mais impossible de corriger le fs.
Fsck me renvoie … rien

trk ssh2 # fsck -A -C -V fsck 1.41.9 (22-Aug-2009) Checking all file systems.

Ca sent la réinstallation brute de debian non ?

#11

[quote=“incal”]Oui j’ai un problème sur le fichier sshd_config, c’est clair, mais impossible de corriger le fs.
Fsck me renvoie … rien

trk ssh2 # fsck -A -C -V fsck 1.41.9 (22-Aug-2009) Checking all file systems.

Ca sent la réinstallation brute de debian non ?[/quote]

Je tente un badblocks /dev/sda2 …

#12

Fais un fsck -p -y -c /dev/sd???

sur la partition où il y a un souci. Tu as le temps de prendre un café.

#13

Badblocks n’a rien donné et …

trk ~ # fsck -p -y -c /dev/sda2 fsck 1.41.9 (22-Aug-2009) fsck: fsck.mdraid: not found fsck: Error 2 while executing fsck.mdraid for /dev/sda2

snif … je sens que je suis mort … ce qui est rageant c’est de ne pas comprendre la source du problème.

#14

Ton système est en raid??? Que donne

fdisk -l

et comment est agencé ton système de fichiers?

#15

Oui sensé être en raid 1.

Bon je met résolu sans que le soit … j’ai fait la réinsall Debian dessus …

Merci de vos aides.