# Erreur openssh-server après upgrade **URL:** \ **Category:** Support Debian\ **Created:** [Mars 21, 2016, 1:31 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781 "2016-03-21T13:31:07Z")\ **Posts on this page:** 20\ **Page:** 3
**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\ **Post date:** [Août 23, 2019, 8:45 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/42 "2019-08-23T20:45:20Z")
Je suis en déplacement donc la situation n’est pas facile à gérer mais c’est rassurant de voir des gens aussi compétents qui peuvent m’aider. J’ai essayé de commenter dans `/etc/network/interfaces` l’interface `eth0:0` avec cette étrange adresse IP asiatique mais ça n’a rien changé, serveur toujours non pingable en mode normal. Plus tard j’aimerai bien comprendre le pourquoi de cette interface mais il faut maintenant tenter de changer le nom de l’interface. > [@littlejohn75](#): > > Donnez les retours de (depuis la console de secours) > … Voici donc ma sortie: ```plaintext root@195-154-216-106:~# basename -a $(echo /sys/class/net/*) eno1 enp2s0 lo root@195-154-216-106:~# ``` ```plaintext root@195-154-216-106:~# udevadm info /sys/class/net/eth0 | fgrep -i PATH Unknown device "/sys/class/net/eth0": No such device root@195-154-216-106:~# ``` ```plaintext root@195-154-216-106:~# udevadm test-builtin net_id /sys/class/net/eth0 2 > /dev/null root@195-154-216-106:~# ``` > [@littlejohn75](#): > > Le nom persistant est donné par `ID_NET_NAME_PATH` et du genre `enp3s0f0` . > Après, la documentation n’est pas des plus claire à propos du fichier > `/etc/udev/rules.d/70-persistent-net.rules` > Le mieux serait de le déplacer vers `$HOME` par exemple. > Donc > > ```plaintext > sudo fgrep -r eth0 /etc > > ``` Le `fgrep` me donne ça: ```plaintext root@195-154-216-106:~# fgrep -r eth0 /etc /etc/dhcp/dhclient.conf:# interface "eth0"; /etc/dhcp/dhclient.conf:# interface "eth0"; /etc/network/interfaces:#auto eth0 /etc/network/interfaces:#iface eth0 inet static /etc/network/interfaces:auto eth0 /etc/network/interfaces:iface eth0 inet static /etc/network/interfaces:#auto eth0:0 /etc/network/interfaces:#iface eth0:0 inet static /etc/network/interfaces~:#auto eth0 /etc/network/interfaces~:#iface eth0 inet static /etc/network/interfaces~:auto eth0 /etc/network/interfaces~:iface eth0 inet static /etc/network/interfaces~:auto eth0:0 /etc/network/interfaces~:iface eth0:0 inet static /etc/udev/rules.d/70-persistent-net.rules:SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="44:1e:a1:3b:21:f6", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" /etc/initramfs-tools/initramfs.conf:# Specify a specific network interface, like eth0 ``` J’imagine qu’il faut donc que je remplace toutes les occurences de **`eth0`** par **`enp2s0`**. Mais je n’ai pas compris ce que je devais déplacer dans mon home, le fichier `/etc/udev/rules.d/70-persistent-net.rules` afin qu’il soit ignoré ? Même s’il est corrigé avec `enp2s0` ? > [@littlejohn75](#): > > Dans le mode de secours on passe par une voie non mise à jour. Mais donc si je fais tout ça (avec « `update-initramfs -u -k all` » pour finir) n’y aurait il pas un risque de ne plus pouvoir accéder au serveur en mode rescue qui actuellement semble se convenir de l’ancien nommage d’interface ? Sinon sur les serveurs d’Online on peut visiblement utiliser iLO, cela pourrait peut-être aider.. Quoiqu’il en soit cette histoire de changement de nommage d’interface réseau fait très mal, ça plus mon souci initial de sshd on peut dire que ma migration est un cas d’école d’upgrade catastrophique (et c’est pas fini je sens). Merci, Vincent. ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Août 23, 2019, 11:40 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/43 "2019-08-23T23:40:00Z")
> [@Vinz](#): > > Voici donc ma sortie: > > ```plaintext > root@195-154-216-106:~# basename -a $(echo /sys/class/net/*) > eno1 > enp2s0 > lo > root@195-154-216-106:~# > > ``` Pas besoin d’être root. Je suppose que la console de secours donne un accès root avec un certain nombre de services non démarrés. Toujours est-il que nous avons des interfaces dont les noms sont à la mode. (pas ethX ). Nous avons donc deux interfaces, pour connaître leur état ( up ou down ) et la configuration IP associée ```plaintext for i in eno1 enp2s0 do ip address show dev $i done ``` et vous trouverez laquelle a pour adresse IPv4 195.154.216.106 Vous pouvez aussi vous rassurer en passant la commande `udevadm info /sys/class/net/` Vous avez la chance d’avoir dans l’arborescence `/etc` seulement un fichier qui fait référence à `eth0` (en supposant que c’est la bonne racine / qui est utilisée ). En éditant `/etc/network/interfaces` n’oubliez pas de supprimer la partie `eth0:0`à moins que l’adresse à Singapour (qui se termine par .36 ) soit celle de l’interface iLO (à demander à Online). > [@Vinz](#): > > le fichier > `/etc/udev/rules.d/70-persistent-net.rules` > afin qu’il soit ignoré ? Même s’il est corrigé avec `enp2s0` ? comment voulez-vous le corriger puisqu’il ne contient pas la chaîne `eth0` et qu’il n’existe peut-être pas ? Vérifiez son existence et son contenu. C’est à mon avis une source d’ennui potentiel. > [@Vinz](#): > > Sinon sur les serveurs d’Online on peut visiblement utiliser iLO, cela pourrait peut-être aider… Il se pourrait bien, que comme monsieur Jourdain vous utilisiez cette interface iLO sans le savoir dans le mode de secours. Et avec un peu de chance le nom de l’interface serait `eno1` Consultez le maître de philosophie des réseaux pour savoir ce qu’il en est exactement. ```plaintext systemctl status -l networking.service ``` En résumé - contacter Online - vérifier UUID du système de fichiers racine. - Modifier `/etc/network/interfaces` - Mettre à jour initramfs - Mettre un cierge à Saint Antoine et redémarrer Cordialement, Regards, Mit freundlichen Grüßen, مع تحياتي الخالصة * * * F. Petitjean Ingénieur civil du Génie Maritime. « Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! » Pierre Dac ---
**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\ **Post date:** [Août 24, 2019, 6:45 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/44 "2019-08-24T06:45:51Z")
> [@littlejohn75](#): > > comment voulez-vous le corriger puisqu’il ne contient pas la chaîne `eth0` et qu’il n’existe peut-être pas ? Vérifiez son existence et son contenu. C’est à mon avis une source d’ennui potentiel. Si si le fichier `/etc/udev/rules.d/70-persistent-net.rules` contient bien 2 lignes avec `eth0` et `eth1`): ```plaintext # This file was automatically generated by the /lib/udev/write_net_rules # program, run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single # line, and change only the value of the NAME= key. # PCI device 0x8086:0x10d3 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="44:1e:a1:3b:21:f7", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" # PCI device 0x8086:0x10d3 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="44:1e:a1:3b:21:f6", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" ``` Si je le « corrige » pas besoin de le déplacer ? ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Août 24, 2019, 7:18 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/45 "2019-08-24T07:18:02Z")
Étrange, tu as bien des règles udev qui forcent le nom des interfaces en eth0 et eth1, comme je le supposais. J’ai bien l’impression que les noms en01 et enp2s0 sont ceux employés par le système de secours (ce qui serait logique si tu travailles dans un environnement chrooté avec /sys monté en lien). AMHA, le problème vient d’ailleurs… Il faudrait examiner le syslog quand tuas démarré le serveur en mode « normal » ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Août 24, 2019, 8:37 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/46 "2019-08-24T08:37:04Z")
> [@Vinz](#): > > Si si le fichier `/etc/udev/rules.d/70-persistent-net.rules` contient bien 2 lignes avec `eth0` et `eth1` ): Faudra m’expliquer pourquoi la commande `fgrep` ne l’a pas trouvé. La seule explication plausible est que les systèmes de fichiers racine sont différents entre mode de secours et mode normal. On tourne en rond, cela peut durer longtemps. Essayez de noter toutes les infos permettant d’y voir plus clair sorties de ```plaintext df -hTx tmpfs lsblk --fs ip address show ``` Puis vous faites un tableau avec deux colonnes mode de secours et mode normal et des lignes avec UUID des périphériques bloc, nom et adresse MAC des interfaces réseau, … Comparez aussi avec les adresses MAC qui se trouvent dans `/etc/udev/rules.d/70-persistent-net.rules` DE toute façon vous aurez besoin de ces informations pour votre courriel à Online. Cordialement, Regards, Mit freundlichen Grüßen, مع تحياتي الخالصة * * * F. Petitjean Ingénieur civil du Génie Maritime. « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos) ---
**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\ **Post date:** [Août 24, 2019, 8:51 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/47 "2019-08-24T08:51:41Z")
@littlejohn75 Par correction. La commande `fgrep` a trouvé `70-persistent-net.rules` > [@Vinz](#): > > Le `fgrep` me donne ça: > > ```plaintext > ... > /etc/udev/rules.d/70-persistent-net.rules:SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="44:1e:a1:3b:21:f6", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" > ... > > ``` ---
**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\ **Post date:** [Août 24, 2019, 8:52 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/48 "2019-08-24T08:52:25Z")
> [@littlejohn75](#): > > Faudra m’expliquer pourquoi la commande `fgrep` ne l’a pas trouvé Si ce fichier était bien dan la sortie de fgrep postée plus haut ! ---
**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\ **Post date:** [Août 24, 2019, 9:11 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/49 "2019-08-24T09:11:22Z")
Nous sommes d’accord @Vinz : nos réponses se sont croisées. Il n’en reste pas moins qu’il te faut suivre les directives. Et une feuille et un crayon t’aideront bien. Ne confonds pas le mode urgence de ton serveur et le mode `chroot` sur ton vrai serveur. Ce dernier équivaut à peu de chose près à un mode normal. Les prises de notes sont à faire pour ces deux modes. Continue tes démarches et pose encore des questions si besoin. N’hésite-pas. Nous reviendrons sur ce `/etc/udev/rules.d/70-persistent-net.rules` Ce n’est peut-être pas le même en mode urgence et en mode `chroot`. > [@littlejohn75](#): > > (Car) les systèmes de fichiers racine [peuvent être] différents entre mode de secours et mode normal. Courage ! PS : Dans [le post](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/11) de @anon70622873 disant comment procéder au `chroot` et faute de mieux, je recommande simplement de préciser le Shell voulu : ```plaintext sudo chroot /mnt /bin/bash ``` ---
**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\ **Post date:** [Août 24, 2019, 8:21 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/50 "2019-08-24T20:21:00Z")
> [@littlejohn75](#): > > Essayez de noter toutes les infos permettant d’y voir plus clair > sorties de > > ```auto > df -hTx tmpfs > lsblk --fs > ip address show > > ``` En mode rescue sans chroot: ``` turman@195-154-216-106:~$ df -hTx tmpfs Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 1,9G 0 1,9G 0% /dev /dev/loop0 squashfs 485M 485M 0 100% /lib/live/mount/rootfs/img.current.squashfs overlay overlay 2,0G 193M 1,8G 10% / /dev/sda2 ext4 916G 705G 165G 82% /mnt turman@195-154-216-106:~$ lsblk --fs NAME FSTYPE LABEL UUID MOUNTPOINT loop0 squashfs /lib/live/mount/rootfs/img.current.squashfs sda ├─sda1 ext4 /boot 54e0bfeb-4c89-4f26-a0eb-e0afde40706c ├─sda2 ext4 / a8ac874e-2e31-4ae7-9ca2-4d62bd54ed75 /mnt └─sda3 swap b989aa61-cf22-4287-98e9-e7a1bef031ef [SWAP] turman@195-154-216-106:~$ ip address show 1: lo: 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 valid_lft forever preferred_lft forever 2: enp2s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 44:1e:a1:3b:21:f6 brd ff:ff:ff:ff:ff:ff inet 195.154.216.106/24 brd 195.154.216.255 scope global enp2s0 valid_lft forever preferred_lft forever inet6 fe80::461e:a1ff:fe3b:21f6/64 scope link valid_lft forever preferred_lft forever 3: eno1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 44:1e:a1:3b:21:f7 brd ff:ff:ff:ff:ff:ff ``` En mode rescue apres chroot: > ``` > turman@195-154-216-106:~$ sudo chroot /mnt /bin/bash > root@195-154-216-106:/$df -hTx tmpfs > Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur > /dev/sda2 ext4 916G 705G 165G 82% / > udev devtmpfs 1,9G 0 1,9G 0% /dev > root@195-154-216-106:/$lsblk --fs > NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT > loop0 squashfs > sda > ├─sda1 ext4 /boot 54e0bfeb-4c89-4f26-a0eb-e0afde40706c > ├─sda2 ext4 / a8ac874e-2e31-4ae7-9ca2-4d62bd54ed75 164,1G 77% / > └─sda3 swap b989aa61-cf22-4287-98e9-e7a1bef031ef [SWAP] > root@195-154-216-106:/$ip address show > 1: lo: 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 > valid_lft forever preferred_lft forever > 2: enp2s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 > link/ether 44:1e:a1:3b:21:f6 brd ff:ff:ff:ff:ff:ff > inet 195.154.216.106/24 brd 195.154.216.255 scope global enp2s0 > valid_lft forever preferred_lft forever > inet6 fe80::461e:a1ff:fe3b:21f6/64 scope link > valid_lft forever preferred_lft forever > 3: eno1: mtu 1500 qdisc noop state DOWN group default qlen 1000 > link/ether 44:1e:a1:3b:21:f7 brd ff:ff:ff:ff:ff:ff > > ``` ---
**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\ **Post date:** [Août 24, 2019, 8:42 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/51 "2019-08-24T20:42:05Z")
Les adresses MAC sont donc les mêmes et Online m’a confirmé que c’était bien `enp2s0` sans trop savoir ce qu’était `eno1`. Je vais donc renommer `eth0` en `enp2s0` juste dans `/etc/network/interfaces`. Le forçage de nom dans `70-persistent-net.rules` ne semblant pas fonctionner et à priori ça sert à rien de le renommer puisque le nom original devrait déjà être `enp2s0` si je comprend bien. Résultat dans quelques instants 🙂 ---
**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\ **Post date:** [Août 24, 2019, 8:47 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/52 "2019-08-24T20:47:55Z")
> [@Vinz](#): > > Le forçage de nom dans `70-persistent-net.rules` ne semblant pas fonctionner et à priori ça sert à rien de le renommer puisque le nom original devrait déjà être `enp2s0` si je comprend bien. Je viens de relire la release note il vaut mieux commenter ou renommer le fichier, je vais donc le faire, c’est d’ailleurs ce qu’avait préconisé [**littlejohn75**](https://www.debian-fr.org/u/littlejohn75), c’est plus clair maintenant 🙂 ---
**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\ **Post date:** [Août 24, 2019, 8:48 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/53 "2019-08-24T20:48:36Z")
Comment corriges-tu `eth0:0` ? > [@littlejohn75](#): > > ```plaintext > auto eth0:0 > iface eth0:0 inet static > > ``` Avec `enp2s0:0` ? > [@littlejohn75](#): > > Mettre à jour initramfs A bien été fait depuis le mode `chroot` ? ---
**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\ **Post date:** [Août 24, 2019, 9:18 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/54 "2019-08-24T21:18:16Z")
J’ai pas corrigé `eth0:0`, j’ai luste laissé commenté. Et oui `update-initramfs` a été executé une fois chrooté. Mais ça n’a pas marché, et plus embêtant le serveur est maintenant non pingable même en mode rescue, ce qui est assez gênant il faut bien l’avouer… ---
**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\ **Post date:** [Août 24, 2019, 9:21 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/55 "2019-08-24T21:21:27Z")
> [@Vinz](#): > > le serveur est maintenant non pingable même en mode rescue et en mode normal ? > [@Vinz](#): > > ça n’a pas marché Tu as voulu aller un peu vite ; désolé pour toi. Ils prennent des € chez online pour réinstaller une buster ou une stretch sur ton dédié ? Je n’ai pas vraiment d’idée de comment ça marche. J’espère que tu as des sauvegardes. ---
**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\ **Post date:** [Août 24, 2019, 9:34 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/56 "2019-08-24T21:34:52Z")
**Le ping répond @Vinz !** ```nohighlight ping 195.154.216.106 PING 195.154.216.106 (195.154.216.106) 56(84) bytes of data. 64 bytes from 195.154.216.106: icmp_seq=1 ttl=54 time=15.8 ms 64 bytes from 195.154.216.106: icmp_seq=2 ttl=54 time=16.1 ms 64 bytes from 195.154.216.106: icmp_seq=3 ttl=54 time=15.10 ms 64 bytes from 195.154.216.106: icmp_seq=4 ttl=54 time=16.3 ms ^C --- 195.154.216.106 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 7ms rtt min/avg/max/mdev = 15.824/16.041/16.277/0.230 ms ``` **Et le service SSH aussi :** ```nohighlight rem@n73sm ~ $ ssh 195.154.216.106 The authenticity of host '195.154.216.106 (195.154.216.106)' can't be established. ECDSA key fingerprint is SHA256:1EMcB40tOfAQVI1DrqA1w9pdigNrjlK3FpB/23W0JRg. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '195.154.216.106' (ECDSA) to the list of known hosts. rem@195.154.216.106's password: Permission denied, please try again. rem@195.154.216.106's password: Permission denied, please try again. rem@195.154.216.106's password: rem@195.154.216.106: Permission denied (publickey,password). rem@n73sm ~ $ ``` ---
**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\ **Post date:** [Août 24, 2019, 9:35 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/57 "2019-08-24T21:35:44Z")
En fait j’étais pas encore revenu en mode `rescue`, mais je peux encore m’y logguer, ouf ! Mais sinon oui le renommage de `eth0` n’a rien changé au mode normal, il doit y avoir (encore) autre chose comme le présentait Bruno… Il faut que je tente iLO ! Edit: décidément nos posts se croisent @anon44391915 ! ---
**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\ **Post date:** [Août 24, 2019, 9:43 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/58 "2019-08-24T21:43:36Z")
Je te conseillerais bien de désactiver le service `apache2` temporairement (en chroot) Puis voir si ce mode normal revient OK après un redémarrage. ```plaintext sudo systemctl stop apache2 sudo systemctl disable apache2 ``` > [@Vinz](#): > > le renommage de eth0 n’a rien changé au mode normal Qu’entends-tu par là ? J’ai du mal à me faire une idée. ---
**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\ **Post date:** [Août 24, 2019, 9:52 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/59 "2019-08-24T21:52:52Z")
Je voulais juste dire que ça n’a rien changé, en mode normal le serveur est toujours non pingable. Et comment diable le serveur Apache pourrait être responsable de la non pingabilité du serveur ? Cela me semble juste impossible… ---
**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\ **Post date:** [Août 24, 2019, 9:55 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/60 "2019-08-24T21:55:01Z")
Le service peut planter, je ne sais pas : c’est une piste facile à essayer. Je crois que la nuit porte conseil 🙂 ---
**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\ **Post date:** [Août 25, 2019, 7:03 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/61 "2019-08-25T07:03:17Z")
Alors j’ai essayé iLO avec 3 manières différentes mais sans succès: - console en Java (Linux et Windows) - console en OneClick (Windows) - via l’appli iLO mobile (Android) mais mon phone ne supporterai pas des connexions TLS fortes (!!) Quand ça ne veut pas ça ne veut pas… Sinon je réfléchis à une solution peu glorieuses qui serait de me louer un nouveau serveur. En fait ça fait longtemps que j’y songé car ma Dedibox date de 2012. Seulement lorsque j’avais comparé les offres il y a 2 ans j’avais préféré gardé ma vieille Dedibox à 35€ HT par mois car en plus d’avoir 4 GB de RAM et 1 To de disque elle a surtout des cores rapides même s’il n’y en a que 2. Lorsque j’avais testé les offre récentes il y avait certes plein de coeur (8 de mémoire) donc une puissance globale correcte mais des scores mauvais en mono-thread. Mais là je vois qu’il y a pour le même prix un serveur à base de Xeon (E3 1220 v2) 6 cores avec 16 GB de RAM et 2x1 To, ça pourrait m’intéresser. Mais ça serait quand même bien de comprendre le problème sur mon serveur actuel… [Page précédente](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781.md?page=2) [Page suivante](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781.md?page=4)