SSH possible uniquement après redémarrage

Demande d'aide : c'est ici.
Répondre
kp666
Messages : 8
Inscription : 17 févr. 2025, 21:07
Status : Hors-ligne

Bonjour,

J'ai installé une VM Debian Bookworm chez Infomaniak, dans leur offre Public Cloud. Tout s'est bien passé, mais je rencontre un problème pour la première fois et je n'arrive pas à le résoudre.

Le souci, c'est que je peux me connecter en SSH uniquement pendant environ deux minutes après le démarrage du serveur. Après ça, je n'arrive plus à me connecter et j'ai un "connection timeout". Je ne trouve rien dans les logs, et j'ai déjà essayé plusieurs trucs :
  • J'ai désactivé les règles iptables sans succès.
  • Pas d’erreurs dans dmesg.
  • J'ai vérifié les valeurs de MaxSessions et MaxStartups.
  • Le service sshd fonctionne bien.
  • Le serveur n'est pas surchargé.
Si quelqu'un a déjà eu ce genre de problème ou a une idée de ce que je pourrais vérifier, je suis preneur !

Merci d'avance !
Avatar de l’utilisateur
piratebab
Site Admin
Site Admin
Messages : 5852
Inscription : 24 avr. 2016, 18:41
Localisation : sud ouest
Status : En ligne

Bonjour,
vérifie si le port SSH est bien accessible.
Depuis ta machine client avec un nmap sur l'ip de ton serveur.
Si tu as un autre accés à ton serveur (interface du fournisseur de cloud ?), tu peux regarder les ports ouverts avec

Code : Tout sélectionner

 netstat –tulnp
Le port ssh doit étre en LISTEN

C'est peut étre infomaniac qui bloque le port ssh, essaie de mettre ssh sur un autre port
kp666
Messages : 8
Inscription : 17 févr. 2025, 21:07
Status : Hors-ligne

Bonjour, merci de la réponse, je test demain ou après demain et ferai un retour. Encore merci et bonne fin de journée
kp666
Messages : 8
Inscription : 17 févr. 2025, 21:07
Status : Hors-ligne

Bonjour, j'ai toujours les mêmes problèmes. J'arrive à me connecter en ssh sur localhost sans problème (depuis le serveur sur le même serveur).

nmap après redémarrage du serveur :

Code : Tout sélectionner

PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 52 OpenSSH 9.2p1 Debian 2+deb12u5 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
nmap après quelques minutes ou après première session ssh ouverte :

Code : Tout sélectionner

PORT   STATE    SERVICE REASON      VERSION
22/tcp filtered ssh     no-response
iptables :

Code : Tout sélectionner

Chain INPUT (policy DROP 95 packets, 20520 bytes)
 pkts bytes target     prot opt in     out     source               destination
 2079  168K f2b-sshd   tcp  --  any    any     anywhere             anywhere             multiport dports ssh
    3   180 ACCEPT     all  --  lo     any     anywhere             anywhere
 2122  419K ACCEPT     all  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED
  101  5930 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:ssh
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp spt:domain
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp spt:domain
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp spt:ntp

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DROP 6 packets, 260 bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   180 ACCEPT     all  --  any    lo      anywhere             anywhere
 2197  493K ACCEPT     all  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED
    1  1228 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp spt:ssh
   11   768 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:domain
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:domain
    9   684 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:ntp
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:http
    1    60 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:https
Ce qui est à noter c'est que lorsque mon problème commence, je ne perds pas la session ssh active, je ne peux juste plus en ouvrir de nouvelles.

netstat

Code : Tout sélectionner

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      423/systemd-resolve
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      502/sshd: /usr/sbin
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      833/exim4
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      423/systemd-resolve
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      518/postgres
tcp        0      0 127.0.0.54:53           0.0.0.0:*               LISTEN      423/systemd-resolve
tcp6       0      0 :::5355                 :::*                    LISTEN      423/systemd-resolve
tcp6       0      0 :::22                   :::*                    LISTEN      502/sshd: /usr/sbin
tcp6       0      0 ::1:5432                :::*                    LISTEN      518/postgres
tcp6       0      0 ::1:25                  :::*                    LISTEN      833/exim4
udp        0      0 127.0.0.54:53           0.0.0.0:*                           423/systemd-resolve
udp        0      0 127.0.0.53:53           0.0.0.0:*                           423/systemd-resolve
udp        0      0 *****:68       0.0.0.0:*                           445/systemd-network
udp        0      0 10.62.3.213:68          0.0.0.0:*                           445/systemd-network
udp        0      0 0.0.0.0:5355            0.0.0.0:*                           423/systemd-resolve
udp6    1792      0 **** :::*                                445/systemd-network
udp6       0      0 :::5355                 :::*                                423/systemd-resolve

je ne vois qu'un problème avec le pare-feu de infomaniak de possible, voici les règles utilisées :

Image

je vais ouvrir un ticket chez infomaniak à ce sujet. J'ai d'autres serveurs chez eux et je n'ai pas ce problème.

Merci pour tout

a bientôt
Vous ne pouvez pas consulter les pièces jointes insérées à ce message.
kp666
Messages : 8
Inscription : 17 févr. 2025, 21:07
Status : Hors-ligne

je viens de modifier les règles du firewall infomaniak pour tout autoriser et cela ne change rien :(
Avatar de l’utilisateur
franb
Membre
Membre
Messages : 137
Inscription : 04 nov. 2017, 09:41
Status : Hors-ligne

Hum, peux tu sortir la totalité des commandes

Code : Tout sélectionner

# iptables-save
# netstat -tpln
(je soupconne une merdouille coté fail2ban)
Avatar de l’utilisateur
piratebab
Site Admin
Site Admin
Messages : 5852
Inscription : 24 avr. 2016, 18:41
Localisation : sud ouest
Status : En ligne

Regarde aussi le fichier de config de ssh pour voir si un timeout n'est pas configuré
kp666
Messages : 8
Inscription : 17 févr. 2025, 21:07
Status : Hors-ligne

Bonjour,

merci encore à vous :

Code : Tout sélectionner

iptables-save
# Generated by iptables-save v1.8.9 (nf_tables) on Mon Feb 24 10:45:12 2025
*filter
:INPUT DROP [45:6728]
:FORWARD DROP [0:0]
:OUTPUT DROP [6:260]
:f2b-sshd - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --sport 53 -j ACCEPT
-A INPUT -p udp -m udp --sport 123 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 123 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A f2b-sshd -s 96.78.175.36/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN
COMMIT
# Completed on Mon Feb 24 10:45:12 2025
L'ip fail2ban n'est pas la mienne.

Code : Tout sélectionner

 netstat -tpln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      526/postgres
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      828/exim4
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      894/sshd: /usr/sbin
tcp        0      0 127.0.0.54:53           0.0.0.0:*               LISTEN      421/systemd-resolve
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      421/systemd-resolve
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      421/systemd-resolve
tcp6       0      0 ::1:25                  :::*                    LISTEN      828/exim4
tcp6       0      0 ::1:5432                :::*                    LISTEN      526/postgres
tcp6       0      0 :::5355                 :::*                    LISTEN      421/systemd-resolve

Code : Tout sélectionner

 grep -rin timeout /etc/ssh
/etc/ssh/ssh_config:34:#   ConnectTimeout 0
je pense à un problème réseau car le ping me donne ceci :

Code : Tout sélectionner

ping ****

Envoi d’une requête 'Ping'  **** avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de **** : octets=32 temps=27 ms TTL=52

Statistiques Ping pour ****:
    Paquets : envoyés = 4, reçus = 1, perdus = 3 (perte 75%),
Durée approximative des boucles en millisecondes :
    Minimum = 27ms, Maximum = 27ms, Moyenne = 27ms

Cordialement,

mickaël
kp666
Messages : 8
Inscription : 17 févr. 2025, 21:07
Status : Hors-ligne

Re,

j'ai 3 interface réseaux, la loopback, l'ip publique et un réseau privé accessible depuis le vpn. Lorsque j'essaie ssh depuis le VPN, cela fonctionne à merveille. Le problème est que je ne peux pas donner accès aux VPN aux utilisateurs concernés. C'est donc un problème réseau.
Avatar de l’utilisateur
franb
Membre
Membre
Messages : 137
Inscription : 04 nov. 2017, 09:41
Status : Hors-ligne

Hum, que donne route -n, je soupconne un route par defaut vers le VPN
kp666
Messages : 8
Inscription : 17 févr. 2025, 21:07
Status : Hors-ligne

franb a écrit : 24 févr. 2025, 13:22 Hum, que donne route -n, je soupconne un route par defaut vers le VPN
depuis ma machine (Windows) ou depuis le serveur ?
kp666
Messages : 8
Inscription : 17 févr. 2025, 21:07
Status : Hors-ligne

Problème résolu ! J'avais ajouté un second réseau privé pour permettre au serveur de communiquer avec les autres machines, mais je n'aurais pas dû, car cela a créé des conflits avec SSH. Comme ce réseau ne m'était finalement pas nécessaire, je l'ai supprimé.

Merci à vous pour votre aide et bonne fin de journée
Répondre