Bonjour,
Suite à une modification de la configuration firewall de mon VPS (Centos 8), j'ai perdu l'accès ssh.
J'ai modifié la configuration firewall en créant un fichier .sh avec des commandes iptables, placé dans /etc/init.d/. J'ai exécuté manuellement ce fichier et manifestement mes instructions iptables étaient mauvaises.
J'ai donc eu besoin de lancer le VPS en mode rescue. J'ai monté le disque qui m'intéressait, j'ai retrouvé mon fichier de configuration et je l'ai édité (d'abord en supprimant son contenu, plus en laissant seulement "iptables -F").
J'ai ensuite relancé mon VPS en mode normal, directement depuis l'interface OVH (Boot > Redémarrer mon VPS), mais je n'arrive toujours pas à me connecter en ssh: j'ai un connection timed out (et non pas refused).
Je ne sais pas pourquoi je me retrouve avec un timeout à la connexion. Je n'ai pas de moyen de m'assurer que la configuration iptables est bonne, mais vu le timeout je pense que la réinitialisation a bien été faite. Mais du coup je ne vois pas d'où peut venir le problème.
Pour information si jamais ca peut aider:
* je n'arrive pas à mon connecter depuis la console KVM (je ne sais pas si ca a un lien, je n'avais jamais essayé)
* je n'utilise pas le port 22 pour le ssh
Quelqu'un aurait il une idée de ce que pourrait être la cause de mon problème ?
Merci pour le support
Bonjour,
Je ne sais pas si ça peut aider, mais as-tu essayé de lancer ta commande ssh en mode verbose ?
> ssh …@… -p… -v
ou
> ssh …@… -p… -vv
ou
> ssh …@… -p… -vvv
Ensuite, quand tu es en mode rescue, as tu été regarder ce que contiennent les logs (/var/log/auth.log par exemple ou autres) ?
Je sais que je ne t'apporte pas de solution, mais peut-être que ça pourra te mettre sur la piste…
Bonjour @LucP13
Merci pour les pistes.
Le mode verbose du ssh ne donne pas beaucoup d'informations supplémentaires:
* En essayant de me connecter via mon port ssh personnalisé je vois l'erreur suivante:
finish_connect - ERROR: async io completed with error: 10060, io:000001A2FE062B60
* Si j'essaye de me connecter via un autre port aléatoire que je n'ai pas configuré j'ai une erreur similaire:
finish_connect - ERROR: async io completed with error: 10060, io:000001C8149B66E0
* Si j'essaye de me connecter via le port 22 que j'ai changé j'ai:
finish_connect - ERROR: async io completed with error: 10061, io:0000021952181100
Je n'ai pas de auth.log dans /var/log. Je ne sais pas vraiment où trouver l'équivalent ailleurs, de ce que je vois sur des forums ca pourrait être dans /var/log/secure, mais le fichier n'existe pas dans mon cas.
Ce que j'ai tout de même trouvé:
* Dans /var/log/syslog:
> cloud-init[658]: ci-info: no authorized SSH keys fingerprints found for user debian.
mais je ne sais pas à quoi il se rapporte (je n'ai jamais essayé de me connecter en utilisant "debian" comme user).
* Avec la commande journalctl -u ssh je vois des logs mais a priori ca ne concerne que le mode rescue, pas mon VPS (je vois sshd[649]: Server listening on 0.0.0.0 port 22. alors que normalement je n'utilise pas ce port)
Pour information l'utilisation des ressources du VPS semble correcte d'après le tab "Monitoring" de l'interface manager OVH.
J'ai également essayé d'augmenter le timeout ssh en modifier /etc/ssh/sshd_config:
* ClientAliveInterval 60
* ClientAliveCountMax 3
(ces 2 lignes étaient commentées l'origine)
Mais le problème persiste: toujours une timeout en tentant de me connecter en ssh
As-tu un fail2ban ? si oui, il y a peut-être un truc ici : https://raspberrypi.stackexchange.com/questions/100343/cant-ssh-into-raspberry-pi-3b-from-windows-10
Cela me rappelle aussi que, de mémoire, il me semble que pour mettre iptables à blanc, il faut lancer :
>iptables -F
iptables -X
ou carrément :
>iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
Or dans ton premier post tu n'as fait que le "-F"…
Merci pour ton aide @LucP13 !
Oui j'ai un fail2ban.
Je ne sais pas comment vérifier si mon ip a été ban, mais en regardant dans /var/log/fail2ban.log aucun log n'indique un ban.
De plus, j'ai vérifié dans /etc/fail2ban/fail2ban.conf, mon ip devrait a priori être bien ignorée:
> ignoreip = 127.0.0.1/8 ::1 [mon_ipv4]/24
(l'ipv4 correspond à ce que je trouve sur https://www.whatismyip.com/fr/)
Effectivement il semblerait que iptables -F ne suffit pas pour réinitialiser la configuration iptables.
J'ai essayé depuis avec
> iptables -F
> iptables -X
> iptables -t nat -F
> iptables -t nat -X
> iptables -t mangle -F
> iptables -t mangle -X
> iptables -P INPUT ACCEPT
> iptables -P FORWARD ACCEPT
> iptables -P OUTPUT ACCEPT
mais sans succès.
Je ne sais plus trop ou chercher, mais malgré mes vérifications le problème vient probablement de mes règles firewall.
Centos 8 utilise apparemment un autre logiciel de gestion firewall: firewalld. Je ne sais pas comment/si il interagit avec iptables et si je peux avoir provoqué un conflit.
Je vois que j'ai une configuration ssh dans usr/lib/firewalld/ssh/services/ssh.xml. Cet xml contient:
>
> SSH
> Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.
>
>
Je ne sais pas si l'option est "enabled" mais je crois que le package "openssh-server" est installé (j'ai un fichier usr/lib/systemd/system/sshd.service).
Je doute que cette configuration soit prise en compte, car j'ai déjà réussi à mon connecter avec mon port ssh personnalisé, et je n'ai jamais changé ce xml. Mais peut être que les commandes iptables ont eu un impact à ce niveau ?
Quelqu'un d'expérimenté en règles firewall ou Centos aurait il des informations à ce sujet ?
Je suis toujours preneur d'autres pistes
Je me permet de relancer le sujet car je suis vraiment bloqué. Personne ne voit d'autres pistes pour résoudre le problème ? Merci
Selon https://linuxize.com/post/how-to-configure-and-manage-firewall-on-centos-8/ firewalld est le firewall par défaut de CentOS 8.
D'après ce que j'ai compris, des règles semblent être dans /etc/firewalld/services et les règles de base sont dans /usr/lib/firewalld/ssh/services/.xml (Cf. https://linuxize.com/post/how-to-configure-and-manage-firewall-on-centos-8/#creating-a-new-firewalld-service).
Quelques pistes :
regarde chacune des règles dans les répertoire ci-dessus pour déceler si qqch pourrait engendrer le pbme que tu rencontres,
* essaie de trouver ce qui lance le daemon peut-être dans /etc/init.d/ (je ne connais pas CentOS) et déplace le dans /root pour ne pas le perdre et ne pas le lancer au démarrage, puis reboot la machine
* encore une fois je ne connais pas CentOS, mais sous Debian, j'irais regarder dans tous les /etc/rc* pour vérifier qu'il n'y aurait pas qqch qui attirerait mon attention afin de désactiver le firewal
C'est tout ce qui me vient en tête pour le moment…