port 22 (SSH) fermé après un reboot

Bare Metal and VPS
1

Bonjour,
alors que j'étais connecté à mon VPS, en SSH, j'ai eu une erreur 500 sur un site hébergé sur ce VPS. Maladroitement j'ai cru à un bug temporaire et j'ai fait un "sudo reboot". Le VPS a bien rebooté, mais il y avait toujours l'erreur 500, mais surtout, le port 22 (pour le SSH) était fermé. Avec KVM j'ai pu réparer l'erreur 500, mais après un reboot en mode normal pas moyen de me connecter au serveur en SSH.
Son IP : 51.77.195.208
Debian 10

Sous KVM, le port est indiqué ouvert, donc je ne sais pas vraiment comment m'y prendre pour réparer. Un peu d'aide ? Merci

2

Salut,

Le service ssh est-il démarré ? :)

3

Bonjour,

En mode KVM, faites: service sshd status

Une piste: par hasard auriez-vous modifié /etc/ssh/sshd_config ?

Il suffit d'une erreur de syntaxe pour que le service (daemon) ne démarre pas au prochain reboot...

4

Avec KVM j'ai lancé un petit script de test :

./ssh_diagnostic.sh
==== 1. Statut du service SSH ====
enabled

==== 2. Ports en écoute ====
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 128 [::]:22 [::]:*

==== 3. Règles iptables ====
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

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

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

==== 4. Règles nftables ====
nftables non configuré

==== 5. UFW (si installé) ====
UFW non installé

==== 6. Fail2ban ====
Pas de ban détecté (ou fichier absent)

==== 7. Journal SSH ====
-- No entries --

==== 8. Services au démarrage ====
apache2.service enabled
apparmor.service enabled
autovt@.service enabled
cloud-config.service enabled
cloud-final.service enabled
cloud-init-local.service enabled
cloud-init.service enabled
containerd.service enabled
cron.service enabled
dbus-org.freedesktop.timesync1.service enabled
docker.service enabled
getty@.service enabled
inetd.service enabled
mysql.service enabled
networking.service enabled
ntp.service enabled
openbsd-inetd.service enabled
postfix.service enabled
rsyslog.service enabled
snapd.seeded.service enabled
snapd.service enabled
ssh.service enabled
sshd.service enabled
syslog.service enabled
systemd-timesyncd.service enabled
unscd.service enabled



Tout semble ok... mais une fois en mode normal, port 22 fermé...

Et pour répondre à fritz2cat, je n'ai pas modifié le fichier sshd_config

5

Salut,

Le service ssh est-il démarré ? :)

6

Bonjour,

En mode KVM, faites: service sshd status

Une piste: par hasard auriez-vous modifié /etc/ssh/sshd_config ?

Il suffit d'une erreur de syntaxe pour que le service (daemon) ne démarre pas au prochain reboot...

7

Avec KVM j'ai lancé un petit script de test :

./ssh_diagnostic.sh
==== 1. Statut du service SSH ====
enabled

==== 2. Ports en écoute ====
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 128 [::]:22 [::]:*

==== 3. Règles iptables ====
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

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

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

==== 4. Règles nftables ====
nftables non configuré

==== 5. UFW (si installé) ====
UFW non installé

==== 6. Fail2ban ====
Pas de ban détecté (ou fichier absent)

==== 7. Journal SSH ====
-- No entries --

==== 8. Services au démarrage ====
apache2.service enabled
apparmor.service enabled
autovt@.service enabled
cloud-config.service enabled
cloud-final.service enabled
cloud-init-local.service enabled
cloud-init.service enabled
containerd.service enabled
cron.service enabled
dbus-org.freedesktop.timesync1.service enabled
docker.service enabled
getty@.service enabled
inetd.service enabled
mysql.service enabled
networking.service enabled
ntp.service enabled
openbsd-inetd.service enabled
postfix.service enabled
rsyslog.service enabled
snapd.seeded.service enabled
snapd.service enabled
ssh.service enabled
sshd.service enabled
syslog.service enabled
systemd-timesyncd.service enabled
unscd.service enabled



Tout semble ok... mais une fois en mode normal, port 22 fermé...

Et pour répondre à fritz2cat, je n'ai pas modifié le fichier sshd_config

8

Tu peux nous donner :

cat /etc/ssh/sshd_config

netstat -anp | grep 22

9

cat /etc/ssh/sshd_config

UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
PermitRootLogin yes
Port 22
PasswordAuthentication yes

Je ne peux plus lancer de commande pour l'instant (pas d'accès à KVM), mais tout à l'heure" netstat -tuln | grep :22" donnait ceci :
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN

Merci encore pour l'aide !

10

De rien.

Dommage pour le netstat -anp

Car on voit bien qu'un process écoute sur le port 22 mais on ne sait pas lequel. Bon ça doit quand même être sshd...

Toujours est-il que quand je telnet ton ip :

telnet 51.77.x.x 22
Trying 51.77.x.x...
telnet: Unable to connect to remote host: Connexion refusée

Je sais que le script donne des infos mais donne nous :

iptables -L -n

stp

11

$ iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

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

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


12

Voici
$ netstat -anp | grep 22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 741/sshd: /usr/sbin
tcp 0 112 51.77.195.208:22 82.64.16.182:59474 ESTABLISHED 849/sshd: root@pts/
tcp6 0 0 :::22 :::* LISTEN 741/sshd: /usr/sbin

Mais je suis en train de changer de serveur, celui-ci sera formaté et résilié, tant pis.

13

Pour la culture, j'ai un début d'explication, le serveur a été piraté par un gugusse le 20 mars, par l'IP 195.201.84.118, accès SSH sans échec au préalable (donc mot de passe connu, comment, je sais pas), et a tapé un bon paquet de commandes avec ses gros doigts boudinés (beaucoup de fautes de frappe), dont l'installation de docker, ajout de users en masse, et exécution de .sh effacés ensuite. Je ne formate donc pas tout de suite, je le garde sous le coude pour continuer à investiguer.

14

Merci pour le retour :)