Problème d'accès SSH suite à la migration 12 - 13

[ciupici]

Bonjour,

Je me permets de vous solliciter car je galère depuis pas mal de temps suite à la MAJ que j'ai fait de Debian 12 vers 13.
La MAJ s'est bien passée, le système est bien sur Debian 13. Mais depuis la MAJ, je n'arrive plus à accéder à mon serveur en SSH.

Je n'ai pas modifié mon sshd_config, openssh est bien installé (je l'ai même réinstallé), ma clé SSH est toujours la même.
Lorsque je me connecte, j'ai un timeout comme si la machine n'est pas accessible.

J'arrive à y accéder via un rescue system et au Chroot. Le service semble bien installé et lancé mais je ne peux vérifier avec systemctl car celui-ci ne fonctionne pas en Chroot.
Auriez-vous des pistes ou des idées pour résoudre cela ?

Merci bien
Cordialement

[piratebab]

Bonjour, il faut déja regarder si le service ssh est en écoute. Soit en local avec netstat , soit à distance avec nmap.
Dans to client ssh active le mode verbeux pour avoir plus d'infos.
Est ce que tu essaie de te connecter en root ? par défaut c'est interdit, l'upgrade a peut étre écrasé ta config présédente
L' Étape d'après sera de sortir la grosse artillerie avec wireshark

[ciupici]

Bonjour,
Merci pour le retour.
Quand je suis en chroot, il fonctionne bien le service SSH mais je ne sais pas si c'est celui du serveur ou celui du rescue system. Et quand je redemarre impossible quand même de m'y connecter.
Avec le ssh -vvt je n'ai rien de plus, il tente de se connecter puis me fait un timeout. Pareil si on tente un ping.
La connection se fait avec un compte utilisateur (la connection root est interdite).

[piratebab]

Est ce qu'un nmap sur un poste client voit le service SSH en écoute sur le serveur ?

[DebDynamiX]

Les identifiants de l'interface reseaux ont changé pour Debian 13.
De plus, Il faut regarder quelles interfaces sont présentes au boot car on dirait que Debian perd apparement le reseau quand il demarre.

Fais:

Code : Tout sélectionner

su -

Renvoi nous le résultat de:

Code : Tout sélectionner

ip a
sshd -t

Ca pourra nous aider à voir plus clair.

[ciupici]

Bonjour,

Merci, voici le retour d'ip a :
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 8a:d6:07:4f:89:79 brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 16:35:a2:03:6b:52 brd ff:ff:ff:ff:ff:ff
4: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32
link/ether 32:34:a4:fd:77:6b brd ff:ff:ff:ff:ff:ff
5: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32
link/ether 82:e3:eb:79:47:30 brd ff:ff:ff:ff:ff:ff
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:22:4d:ad:6f:2e brd ff:ff:ff:ff:ff:ff
altname eno0
altname enp1s0
inet 37.XXX.XXX.XXX/24 brd 37.187.110.255 scope global dynamic eth0
valid_lft 86049sec preferred_lft 86049sec
inet6 2001:XXX.XXX.XXX/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::XXX.XXX.XXX/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
7: teql0: <NOARP> mtu 1500 qdisc noop state DOWN group default qlen 100
link/void
8: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
9: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000
link/gre 0.0.0.0 brd 0.0.0.0
10: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
11: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
12: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
13: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
link/tunnel6 :: brd :: permaddr e690bd1f::

J'ai juste anonymisée l'IPV4 et 6.
sshd -t renvoie rien du tout.

Bonne journée

[ciupici]

@piratebab en chroot ss -tlnp | grep :22 me renvoie :
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=7255,fd=3))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=7255,fd=4))

[ciupici]

et le log du service :

Feb 12 12:12:12 ns sshd-session[86770]: Connection closed by authenticating user root 10.0.2.4 port 50630 [preauth]
Feb 12 12:28:17 ns systemd[1]: Listening on sshd-unix-local.socket - OpenSSH Server Socket (systemd-ssh-generator, AF_UNIX Local).
Feb 12 12:28:18 ns systemd[1]: sshd-keygen.service - Generate sshd host keys on first boot was skipped because of an unmet condition check (ConditionFirstBoot=yes).
Feb 12 12:28:18 ns systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
Feb 12 12:28:19 ns sshd[591]: Server listening on 0.0.0.0 port 22.
Feb 12 12:28:19 ns sshd[591]: Server listening on :: port 22.
Feb 12 12:28:19 ns systemd[1]: Started ssh.service - OpenBSD Secure Shell server.

Je ne sais pas à quoi correspondent la preauth (peut-être un service d'OVH comme c'est un dédié chez eux).
Il a l'air de fonctionné mais quand je fais une connexion j'ai un timeout

[ciupici]

J'ai redémarré le serveur et là pas de réponse au ping ni en SSH

[DebDynamiX]

D'apres tes renvois ton Debian a démarré en mode initramfs de secours Debian. Le problème n'est pas SSH, mais le boot qui échoue lors d'une erreur critique rencontrée dans le boot, Debian bascule automatiquement sur un mini‑kernel de secours.

La preuve:

Code : Tout sélectionner

Server listening on 0.0.0.0 port 22.
Server listening on :: port 22.

SSH demarre sans problème.
De plus, ce qui me fait penser à ça:

Code : Tout sélectionner

inet6 2001:XXX.XXX.XXX/128 scope global

et d'autres choses entre autres


Renvoi nous :

Code : Tout sélectionner

dmesg -T | less
systemctl --failed
journalctl -xb

Juste histoire de clarifier si je me trompe ou pas.

[ciupici]

Mais n'est-ce pas parce que je suis sur le rescue-os ?

On le voit dans le dmesg -T | less

Code : Tout sélectionner

[Thu Mar  5 16:14:17 2026] Linux version 6.1.51-mod-std (root@determined-but-gallant-gauss) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #3992717 S
MP PREEMPT_DYNAMIC Mon Sep  1 13:08:15 UTC 2025
[Thu Mar  5 16:14:17 2026] Command line: BOOTMAC=00:22:4d:ad:6f:2e rdinit=/sbin/init console=tty0 ramdisk_size=51200 load_ramdisk=1 panic=10 net.ifnames=0 rootfstype=ramfs s
ystemd.gpt_auto=0 DATASOURCE=https://releases.mirrors.ovh.net/12.1.2_rescue-customer_prod/public.ovh.rescue.flavors/fr/rescue-customer METADATA=https://baremetal.eu.ovhapis.
com/1.0/metadata-api 

Kernel command line: BOOTMAC=00:22:4d:ad:6f:2e rdinit=/sbin/init console=tty0 ramdisk_size=51200 load_ramdisk=1 panic=10 net.ifnames=0 rootfstype=ramfs systemd.gpt_auto=0 DATASOURCE=https://releases.mirrors.ovh.net/12.1.2_rescue-customer_prod/public.ovh.rescue.flavors/fr/rescue-customer METADATA=https://baremetal.eu.ovhapis.com/1.0/metadata-api $
[Thu Mar  5 16:14:17 2026] ignoring the deprecated load_ramdisk= option
[Thu Mar  5 16:14:17 2026] Unknown kernel command line parameters "BOOTMAC=00:22:4d:ad:6f:2e DATASOURCE=https://releases.mirrors.ovh.net/12.1.2_rescue-customer_prod/public.ovh.rescue.flavors/fr/rescue-customer METADATA=https://baremetal.eu.ovhapis.com/1.0/metadata-api 

[Thu Mar  5 16:14:22 2026] Freeing unused kernel image (text/rodata gap) memory: 2044K
[Thu Mar  5 16:14:22 2026] Freeing unused kernel image (rodata/data gap) memory: 100K
[Thu Mar  5 16:14:22 2026] Run /sbin/init as init process
[Thu Mar  5 16:14:22 2026]   with arguments:
[Thu Mar  5 16:14:22 2026]     /sbin/init
[Thu Mar  5 16:14:22 2026]   with environment:
[Thu Mar  5 16:14:22 2026]     HOME=/
[Thu Mar  5 16:14:22 2026]     TERM=linux
[Thu Mar  5 16:14:22 2026]     BOOTMAC=00:22:4d:ad:6f:2e
[Thu Mar  5 16:14:22 2026]     DATASOURCE=https://releases.mirrors.ovh.net/12.1.2_rescue-customer_prod/public.ovh.rescue.flavors/fr/rescue-customer
[Thu Mar  5 16:14:22 2026]     METADATA=https://baremetal.eu.ovhapis.com/1.0/metadata-api
[Thu Mar  5 16:14:22 2026]     
[Thu Mar  5 16:14:22 2026] systemd[1]: systemd 252.38-1~deb12u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
[Thu Mar  5 16:14:22 2026] systemd[1]: Detected architecture x86-64.
[Thu Mar  5 16:14:22 2026] systemd[1]: Hostname set to <rescue.ovh.net>.
[Thu Mar  5 16:14:22 2026] 8021q: adding VLAN 0 to HW filter on device eth0
[Thu Mar  5 16:14:24 2026] e1000e 0000:01:00.0 eth0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[Thu Mar  5 16:14:24 2026] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[Thu Mar  5 16:14:25 2026] random: crng init done
[Thu Mar  5 16:14:26 2026] systemd[1]: Queued start job for default target multi-user.target.
[Thu Mar  5 16:14:26 2026] systemd[1]: Created slice system-getty.slice - Slice /system/getty.
[Thu Mar  5 16:14:26 2026] systemd[1]: Created slice system-modprobe.slice - Slice /system/modprobe.
[Thu Mar  5 16:14:26 2026] systemd[1]: Created slice user.slice - User and Session Slice.
[Thu Mar  5 16:14:26 2026] systemd[1]: Started systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch.
[Thu Mar  5 16:14:26 2026] systemd[1]: Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch.
[Thu Mar  5 16:14:26 2026] systemd[1]: Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point.
[Thu Mar  5 16:14:26 2026] systemd[1]: Reached target cryptsetup.target - Local Encrypted Volumes.
[Thu Mar  5 16:14:26 2026] systemd[1]: Reached target integritysetup.target - Local Integrity Protected Volumes.
[Thu Mar  5 16:14:26 2026] systemd[1]: Reached target paths.target - Path Units.
[Thu Mar  5 16:14:26 2026] systemd[1]: Reached target remote-fs.target - Remote File Systems.
[Thu Mar  5 16:14:26 2026] systemd[1]: Reached target slices.target - Slice Units.
[Thu Mar  5 16:14:26 2026] systemd[1]: Reached target swap.target - Swaps.
[Thu Mar  5 16:14:26 2026] systemd[1]: Reached target veritysetup.target - Local Verity Protected Volumes.
[Thu Mar  5 16:14:26 2026] systemd[1]: Listening on dm-event.socket - Device-mapper event daemon FIFOs.
[Thu Mar  5 16:14:26 2026] systemd[1]: Listening on lvm2-lvmpolld.socket - LVM2 poll daemon socket.
[Thu Mar  5 16:14:26 2026] systemd[1]: Listening on systemd-initctl.socket - initctl Compatibility Named Pipe.
[Thu Mar  5 16:14:26 2026] systemd[1]: systemd-journald-audit.socket - Journal Audit Socket was skipped because of an unmet condition check (ConditionSecurity=audit).
[Thu Mar  5 16:14:26 2026] systemd[1]: Listening on systemd-journald-dev-log.socket - Journal Socket (/dev/log).
[Thu Mar  5 16:14:26 2026] systemd[1]: Listening on systemd-journald.socket - Journal Socket.
[Thu Mar  5 16:14:26 2026] systemd[1]: Listening on systemd-udevd-control.socket - udev Control Socket.
[Thu Mar  5 16:14:26 2026] systemd[1]: Listening on systemd-udevd-kernel.socket - udev Kernel Socket.
[Thu Mar  5 16:14:26 2026] systemd[1]: Mounting dev-hugepages.mount - Huge Pages File System...
[Thu Mar  5 16:14:26 2026] systemd[1]: Mounting dev-mqueue.mount - POSIX Message Queue File System...
[Thu Mar  5 16:14:26 2026] systemd[1]: sys-kernel-debug.mount - Kernel Debug File System was skipped because of a

Code : Tout sélectionner

 systemctl --failed
Running in chroot, ignoring command 'list-units'
root@rescue12-customer-eu:/# journalctl -xb
-- No entries --

[DebDynamiX]

Exactement !

Code : Tout sélectionner

rootfstype=ramfs

le confirme et de plus le rescue charge ses propres drivers:

Code : Tout sélectionner

e1000e ... eth0: NIC Link is Up

Je ne connais pas OVH, ce n’est pas très connu chez moi (Je suis Américain et Canadien).

Verifie si tu n'as pas enclanché le mode "rescue" par hasard chez OVH.

Puis, renvoi nous:

Code : Tout sélectionner

ip link

Cela va nous faire un point de départ

[piratebab]

Chez OVH, il faut modifier le netboot
https://www.malekal.com/comment-demarre ... en-rescue/
Si ça ne démarre pas en mode normal, repasse en mode rescue, et regarde l'historique des logs pour voir ce qui bloque le démarrage du mode normal

[ciupici]

Merci pour vos retours mais je suis obligé de passer par le mode rescue pour avoir accès au serveur via le chroot. Dès que je reviens sur un boot sur le disque dur, le serveur n'est plus accessible.

[DebDynamiX]

Envoi nous ce que Debian dit pour "ip link" meme si tu es en mode rescue. Je pense avoir une idée de ce qu'il se passe. Comme je te l'ai précisé au debut, les affectations des noms de réseaux sont surement differentes entre GRUB/systemd+udev (donc dans /etc/network/interfaces surement devoir changer les affectations). D'ou le fait de connaitre le discovery de Debian via "ip link" nous permettra de fixer ton problème.

[ciupici]

Merci et désolé pour le délai, voici le retour :

Code : Tout sélectionner

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 8a:d6:07:4f:89:79 brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 16:35:a2:03:6b:52 brd ff:ff:ff:ff:ff:ff
4: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
    link/ether 96:64:90:d6:23:6b brd ff:ff:ff:ff:ff:ff
5: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
    link/ether d6:5b:32:e8:93:52 brd ff:ff:ff:ff:ff:ff
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:22:4d:ad:6f:2e brd ff:ff:ff:ff:ff:ff
    altname eno0
    altname enp1s0
7: teql0: <NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 100
    link/void 
8: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
9: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/gre 0.0.0.0 brd 0.0.0.0
10: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
11: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
12: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
13: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/tunnel6 :: brd :: permaddr 4641:c330:f865::

[DebDynamiX]

En résumé, ton renvoi de "ip link" dit que j'avais tout faux. Car les adresses MAC correspondent, SSH fonctionne, les drivers sont chargés, les affectations sont correctes. Donc, il se peu que la séquence de boot d'OVH contourne le GRUB de ton Debian et met en place son kernel, qui n’est pas cohérent avec l’initramfs généré par Debian, ce qui provoque une rupture de la chaîne de boot et empêche systemd d’initialiser correctement le système.

Donc, verifie dans l'interface d'OVH que tu n'es pas en mode "Netboot", si oui, passe en "Boot from Hard drive". Je ne connais pas OVH, quelque chose dans ce genre.

Ensuite fais:

Code : Tout sélectionner

su -
apt install --reinstall linux-image-$(uname -r)
apt install --reinstall grub-pc

Apres l'installation pour reconstruir initramfs, fais:

Code : Tout sélectionner

update-initramfs -c -k all

Verification:

Code : Tout sélectionner

ls -lh /boot

Tu peux nous faire son renvoi si tu le veux, pour te dire si c'est okay.

-----
Si ton probleme perciste, car il peut survenir d’autres couches du boot. alors fait nous le renvoie du contenu de "/boot/grub/grub.cfg", "/etc/fstab/" et aussi la sortie:

Code : Tout sélectionner

su -
blkid

[ciupici]

C'est bizarre quand je veux reinstaller l'image j'ai l'erreur :

Code : Tout sélectionner

Error: Unable to locate package linux-image-6.1.51-mod-std
Error: Couldn't find any package by glob 'linux-image-6.1.51-mod-std'

[ciupici]

D'ailleurs, il me dit The currently running kernel version is 6.1.51-mod-std which is not the │
│ expected kernel version 6.12.73+deb13-amd64.
Mais je crois que je n'arrive pas à redemarrer correctement le serveur et donc il ne charge pas le bon noyau.

[ciupici]

Voici la commande pour voir le boot :

-rw-r--r-- 1 root root 83 May 22 2025 System.map-6.1.0-37-amd64
-rw-r--r-- 1 root root 83 Nov 5 14:56 System.map-6.12.57+deb13-amd64
-rw-r--r-- 1 root root 83 Dec 30 19:37 System.map-6.12.63+deb13-amd64
-rw-r--r-- 1 root root 83 Feb 17 05:47 System.map-6.12.73+deb13-amd64
-rw-r--r-- 1 root root 254K May 22 2025 config-6.1.0-37-amd64
-rw-r--r-- 1 root root 277K Nov 5 14:56 config-6.12.57+deb13-amd64
-rw-r--r-- 1 root root 277K Dec 30 19:37 config-6.12.63+deb13-amd64
-rw-r--r-- 1 root root 277K Feb 17 05:47 config-6.12.73+deb13-amd64
drwxr-xr-x 2 root root 4.0K Oct 4 2024 efi
drwxr-xr-x 6 root root 4.0K Mar 9 17:02 grub
-rw-r--r-- 1 root root 27M Mar 9 16:58 initrd.img-6.1.0-37-amd64
-rw-r--r-- 1 root root 54M Mar 9 16:59 initrd.img-6.12.57+deb13-amd64
-rw-r--r-- 1 root root 54M Mar 9 17:00 initrd.img-6.12.63+deb13-amd64
-rw-r--r-- 1 root root 54M Mar 9 17:00 initrd.img-6.12.73+deb13-amd64
drwx------ 2 root root 16K Nov 1 2024 lost+found
-rw-r--r-- 1 root root 7.9M May 22 2025 vmlinuz-6.1.0-37-amd64
-rw-r--r-- 1 root root 12M Nov 5 14:56 vmlinuz-6.12.57+deb13-amd64
-rw-r--r-- 1 root root 12M Dec 30 19:37 vmlinuz-6.12.63+deb13-amd64
-rw-r--r-- 1 root root 12M Feb 17 05:47 vmlinuz-6.12.73+deb13-amd64