# Erreur openssh-server après upgrade

**URL:** <https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781>\
**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:** 2

<div class="post-metadata">

**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, 12:40 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/21 "2019-08-23T12:40:33Z")

</div>

Je précisais que c’était un serveur dédié car il m’avait semblé que tu avais parlé de VM, mais effectivement c’est pas important.

Le support technique vient de me répondre que les disques sont en bon état.

Je ne sais pas quoi faire et la situation est plus que désagréable.

Là je peux me logguer en mode rescue, mais quoi vérifier exactement ?

J’ai monté ma partition et voici le contenu de fstab:

```nohighlight
turman@195-154-216-106:~$ sudo fdisk -l  
[sudo] password for turman:  
Disk /dev/loop0: 451,5 MiB, 473444352 bytes, 924696 sectors 
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 

Disk /dev/sda: 931,5 GiB, 1000171331584 bytes, 1953459632 sectors 
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disklabel type: dos 
Disk identifier: 0x000297bc 

Device Boot Start End Sectors Size Id Type 
/dev/sda1 63 385559 385497 188,2M 83 Linux 
/dev/sda2 385560 1951447679 1951062120 930,3G 83 Linux 
/dev/sda3 1951447680 1953439739 1992060 972,7M 82 Linux swap / Solaris 
turman@195-154-216-106:~$ sudo mount /dev/sda2 /mnt 
turman@195-154-216-106:~$ cat /mnt/etc/fstab  
proc /proc proc defaults 0 0 

/dev/disk/by-uuid/a8ac874e-2e31-4ae7-9ca2-4d62bd54ed75 / ext4 defaults,errors=remount-ro 0 1 
/dev/disk/by-uuid/54e0bfeb-4c89-4f26-a0eb-e0afde40706c /boot ext4 defaults 0 2 
/dev/disk/by-uuid/b989aa61-cf22-4287-98e9-e7a1bef031ef none swap sw 0 0

```

Si en mode “normal” le serveur n’est pas pingable, peut on quand même voir des logs pertinents (sur le boot en général et notamment sur le réseau) même en étant en mode “rescue” ? En fait je ne comprend pas ce qu’est exactement ce mode rescue, je ne sais même pas si le serveur est rebooté ou pas lorsqu’on a passe d’un mode à l’autre…

---

<div class="post-metadata">

**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, 12:58 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/23 "2019-08-23T12:58:52Z")

</div>

Voici le contenu du sshd\_config:

> ```
> turman@195-154-216-106:~$ cat /mnt/etc/ssh/sshd_config  
> # $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $ 
> 
> # This is the sshd server system-wide configuration file. See 
> # sshd_config(5) for more information. 
> 
> # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin 
> 
> # The strategy used for options in the default sshd_config shipped with 
> # OpenSSH is to specify options with their default value where 
> # possible, but leave them commented. Uncommented options override the 
> # default value. 
> 
> #Port 22 
> #AddressFamily any 
> #ListenAddress 0.0.0.0 
> #ListenAddress :: 
> 
> #HostKey /etc/ssh/ssh_host_rsa_key 
> #HostKey /etc/ssh/ssh_host_ecdsa_key 
> #HostKey /etc/ssh/ssh_host_ed25519_key 
> 
> # Ciphers and keying 
> #RekeyLimit default none 
> 
> # Logging 
> #SyslogFacility AUTH 
> #LogLevel INFO 
> 
> # Authentication: 
> 
> #LoginGraceTime 2m 
> #PermitRootLogin prohibit-password 
> #StrictModes yes 
> #MaxAuthTries 6 
> #MaxSessions 10 
> 
> #PubkeyAuthentication yes 
> 
> # Expect .ssh/authorized_keys2 to be disregarded by default in future. 
> #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 
> 
> #AuthorizedPrincipalsFile none 
> 
> #AuthorizedKeysCommand none 
> #AuthorizedKeysCommandUser nobody 
> 
> # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts 
> #HostbasedAuthentication no 
> # Change to yes if you don't trust ~/.ssh/known_hosts for 
> # HostbasedAuthentication 
> #IgnoreUserKnownHosts no 
> # Don't read the user's ~/.rhosts and ~/.shosts files 
> #IgnoreRhosts yes 
> 
> # To disable tunneled clear text passwords, change to no here! 
> #PasswordAuthentication yes 
> #PermitEmptyPasswords no 
> 
> # Change to yes to enable challenge-response passwords (beware issues with 
> # some PAM modules and threads) 
> ChallengeResponseAuthentication no 
> 
> # Kerberos options 
> #KerberosAuthentication no 
> #KerberosOrLocalPasswd yes 
> #KerberosTicketCleanup yes 
> #KerberosGetAFSToken no 
> 
> # GSSAPI options 
> #GSSAPIAuthentication no 
> #GSSAPICleanupCredentials yes 
> #GSSAPIStrictAcceptorCheck yes 
> #GSSAPIKeyExchange no 
> 
> # Set this to 'yes' to enable PAM authentication, account processing, 
> # and session processing. If this is enabled, PAM authentication will 
> # be allowed through the ChallengeResponseAuthentication and 
> # PasswordAuthentication. Depending on your PAM configuration, 
> # PAM authentication via ChallengeResponseAuthentication may bypass 
> # the setting of "PermitRootLogin without-password". 
> # If you just want the PAM account and session checks to run without 
> # PAM authentication, then enable this but set PasswordAuthentication 
> # and ChallengeResponseAuthentication to 'no'. 
> UsePAM yes 
> 
> #AllowAgentForwarding yes 
> #AllowTcpForwarding yes 
> #GatewayPorts no 
> X11Forwarding yes 
> #X11DisplayOffset 10 
> #X11UseLocalhost yes 
> #PermitTTY yes 
> PrintMotd no 
> #PrintLastLog yes 
> #TCPKeepAlive yes 
> #PermitUserEnvironment no 
> #Compression delayed 
> #ClientAliveInterval 0 
> #ClientAliveCountMax 3 
> #UseDNS no 
> #PidFile /var/run/sshd.pid 
> #MaxStartups 10:30:100 
> #PermitTunnel no 
> #ChrootDirectory none 
> #VersionAddendum none 
> 
> # no default banner path 
> #Banner none 
> 
> # Allow client to pass locale environment variables 
> AcceptEnv LANG LC_* 
> 
> # override default of no subsystems 
> Subsystem sftp /usr/lib/openssh/sftp-server 
> 
> # Example of overriding settings on a per-user basis 
> #Match User anoncvs 
> # X11Forwarding no 
> # AllowTcpForwarding no 
> # PermitTTY no 
> # ForceCommand cvs server
> 
> ```

En fait quasiment tout est commenté. Et d’ailleurs lors de l’upgrade, j’avais pris soin de regarder la différence avec mon fichier, et comme je voyais que c’était plus permissif (j’avais le strict mode activé) je m’étais vraiment dis que c’était plus sûr de prendre la config du mainteneur.

Mais je pense pas qu’il faille trop s’attarder sur la config SSH car là mon problème est que mon serveur n’est plus pingable en mode «&nbsp;normal&nbsp;». C’est donc certainement un problème de plus «&nbsp;bas niveau&nbsp;», au niveau du boot ou de la config réseau sans doute…

Ne comprenant pas le mode «&nbsp;rescue&nbsp;» (tout comme le mode «&nbsp;recovery&nbsp;» de Grub) je sais pas même pas si je peux avoir accès à des logs pertinents un fois passé dans ce mode…

---

<div class="post-metadata">

**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 23, 2019, 1:02 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/24 "2019-08-23T13:02:08Z")

</div>

> [@Vinz](#):
>
> je pense pas qu’il faille trop s’attarder sur la config SSH car là mon problème est que mon serveur n’est plus pingable en mode “normal”. C’est donc certainement un problème de plus “bas niveau”, au niveau du boot ou de la config réseau sans doute…

Alors je laisse le soin à d’autres pour t’aider.  
Je ne connais pas assez.

---

<div class="post-metadata">

**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, 1:04 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/25 "2019-08-23T13:04:26Z")

</div>

On n’est d’accord que pour connaitre le statut du service SSH je dois d’abord refaire le chroot (et remonter tous les pseudo systèmes de fichiers) ?

---

<div class="post-metadata">

**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 23, 2019, 1:13 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/26 "2019-08-23T13:13:20Z")

</div>

As-tu vérifié ce que je t’ai dit pour le pare-feu et fail2ban?  
Si l’assistance technique voit ton serveur (ping et HTTP) et pas toi c’est que le problème ne vient pas du serveur.  
Donnes-nous l’URL d’un service web que tu héberges ou ton Ip publique que l’on puisse voir si ton serveur répond.

---

<div class="post-metadata">

**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 23, 2019, 1:13 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/27 "2019-08-23T13:13:49Z")

</div>

Si il n’y avait que deux broutilles dans ton `sshd_config` à réparer,  
son contenu pourrait être bien passé en revue par @choops ou @PascalHambourg ou @anon70622873

J’ai cherché un bon tuto pour faire un chroot correct mais en vain ; je n’ai pas trouvé ☹  
C’est pas une chose si évidente à faire.

Je ne peux pas faire plus. désolé.  
Le mode urgence que tu utilises est différent du mode recovery d’une Debian ;  
Regarder le statut du service `ssh` est inutile avec ce mode urgence.

---

<div class="post-metadata">

**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, 1:22 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/28 "2019-08-23T13:22:10Z")

</div>

@anon44391915: merci quand même pour ton aide !

@Bruno: désolé j’avais pas relevé cette phrase mais non je pense pas que ça soit un problème de firewall puisque:

- hier avant l’upgrade tout marchait bien
- maintenant en mode “normal” le serveur n’est même plus pingable (et donc nmap ne donnera rien)
- en mode “rescue”, l’IP est la même, c’est pingable et je peux me connecter en SSH

Pour info l’IP du serveur est 195.154.216.106 et il tourne dessus plusieurs sites comme [www.flexygames.net](http://www.flexygames.net).

Actuellement le serveur est en mode “rescue” donc on peut le pinger et faire du SSH (pour le HTTP on arrive sur une page de maintenance d’Online).

Lorsqu’on est en mode “rescue” peut on quand même avoir accès aux logs du serveur lorsque celui celui a booté en mode “normal” ? Auquel cas on pourrait savoir ce qui bloque le démarrage en mode “normal”…

Edit: ah et aussi il ne faut pas se fier au fait que le monitoring d’Online disait que le serveur était pingable et atteignable en HTTP et SSH puisque d’après leurs propres dires leur monitoring n’est pas fonctionnel…

---

<div class="post-metadata">

**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 23, 2019, 1:24 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/29 "2019-08-23T13:24:10Z")

</div>

Si tu es en mode rescue avec un chroot vérifie le retour de :  
`iptables -L -n`  
Et donne :  
`cat /etc/network/interfaces`

Les logs sont dans /var/log si tu es chrooté ou dans /mnt/var/log si tu as juste monté la partition système.

---

<div class="post-metadata">

**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, 1:36 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/30 "2019-08-23T13:36:37Z")

</div>

Alors pour iptables:

```nohighlight
root@195-154-216-106:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination         

Chain FORWARD (policy ACCEPT)
target prot opt source destination         

Chain OUTPUT (policy ACCEPT)
target prot opt source destination   

```

Et pour les interfaces:

```nohighlight
root@195-154-216-106:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#auto eth0
#iface eth0 inet static
# address 88.190.34.106
# netmask 255.255.255.0
# network 88.190.34.0
# broadcast 88.190.34.255
# gateway 88.190.34.1

auto eth0 
iface eth0 inet static 
  address 195.154.216.106
  netmask 255.255.255.0 
  gateway 195.154.216.1 

auto eth0:0
iface eth0:0 inet static
  address 8.190.34.106
  netmask 255.255.255.255

```

Bref rien de choquant…

Et je vois pas pourquoi/comment mon `dist-upgrade` aurait pu casser la config réseau…

Ce qu’il faudrait c’est avoir les logs du démarrage du serveur lorsqu’il est en mode “normal”. Dans quel(s) fichier(s) devrais je regarder ?

---

<div class="post-metadata">

**Author:** ![Albert](https://www.debian-fr.org/user_avatar/www.debian-fr.org/albert/32/8474_2.png) [@Albert](https://www.debian-fr.org/u/Albert)\
**Post date:** [Août 23, 2019, 1:52 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/31 "2019-08-23T13:52:24Z")

</div>

Bonjour,  
Il y a la commande ‘’‘dmesg’’’, mais je ne suis pas sûr qu’elle fonctionne, ni que ça t’aide !

---

<div class="post-metadata">

**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, 2:00 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/32 "2019-08-23T14:00:03Z")

</div>

Alors si, dmesg fonctionne en mode “rescue” une fois le chgrooté, mais effectivement ça ne me parle pas trop…

Par contre il semblerait qu’avec KVM (?) je puisse voir ce qu’il se passe au boot en mode normal, je vais essayer…

---

<div class="post-metadata">

**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 23, 2019, 2:19 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/33 "2019-08-23T14:19:47Z")

</div>

> [@Vinz](#):
>
> Bref rien de choquant…

Si.  
`auto eth0:0` et ce qui suit

La configuration réseau est erronée ⇒ la machine démarre mais le réseau n’est jamais activé.

---

<div class="post-metadata">

**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, 2:24 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/34 "2019-08-23T14:24:29Z")

</div>

Ah mes interfaces seraient donc mal définies… et comment faire pour réparer ? 🙂

---

<div class="post-metadata">

**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 23, 2019, 2:27 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/35 "2019-08-23T14:27:48Z")

</div>

Tu vires tout ce bloc :

```auto
auto eth0:0
iface eth0:0 inet static
  address 8.190.34.106
  netmask 255.255.255.255

```

---

<div class="post-metadata">

**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, 2:33 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/36 "2019-08-23T14:33:13Z")

</div>

> [@Vinz](#):
>
> ```auto
> auto eth0
> iface eth0 inet static 
> address 195.154.216.106 
> netmask 255.255.255.0 
> gateway 195.154.216.1 
> 
> auto eth0:0 
> iface eth0:0 inet static 
> address 8.190.34.106 
> netmask 255.255.255.255
> 
> ```

De toute évidence votre lecture des notes de version pour la mise à jour vers Debian 10 n’a pas été suffisamment approfondie, et vous êtes tombé dans le piège maléfique des noms d’interface persistantes. Autrement dit, il faut dire au revoir aux interfaces nommées `eth0` ou `eth1`.  
Je suis moi-même tombé dans ce piège et après redémarrage le serveur n’est plus joignable (par deux interfaces distinctes) et je dois aller sur place pour réparer.

Donnez les retours de (depuis la console de secours)

```auto
basename -a $(echo /sys/class/net/*)
udevadm info /sys/class/net/eth0 | fgrep -i PATH
udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null

```

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

```auto
sudo fgrep -r eth0 /etc

```

et remplacer par le nom persistant.  
Avant de redémarrer un

```plaintext
sudo update-initramfs -u -k all

```

me semble pertinent.

Pour la nécessité du `chroot` je ne suis pas vraiment convaincu.  
Peut-on avoir les sorties (en mode de secours) de

```auto
mount | fgrep '/ '
df -hTx tmpfs
sudo blkid
lsblk --fs

```

et en comparant avec ce qu’il y a dans `/etc/fstab` (rescue et normal). Il me semble que les sorties des commandes ci-dessus devraient vous permettre de savoir si la racine du mode de secours est la même que celle du mode normal.

Cordialement,  
Regards,  
Mit freundlichen Grüßen,  
مع تحياتي الخالصة

* * *

F. Petitjean  
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »  
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

---

<div class="post-metadata">

**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, 2:43 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/37 "2019-08-23T14:43:42Z")

</div>

> [@anon70622873](#):
>
> ```auto
> auto eth0:0
> iface eth0:0 inet static
> address 8.190.34.106
> netmask 255.255.255.255
> 
> ```

Après avoir demandé conseil à l’hébergeur. Il se pourrait que ce soit un bon moyen de ne même plus avoir accès au mode de secours, on ne sait jamais.

* * *

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

---

<div class="post-metadata">

**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 23, 2019, 2:48 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/38 "2019-08-23T14:48:30Z")

</div>

L’hébergeur Online n’a pas d’adresses IP à Singapour…  
Quant au noms des interfaces, je doute fort que cela soit le problème.

---

<div class="post-metadata">

**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 23, 2019, 2:55 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/39 "2019-08-23T14:55:46Z")

</div>

> [@anon70622873](#):
>
> Quant au noms des interfaces, je doute fort que cela soit le problème.

[https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.fr.html#review-interface-names](https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.fr.html#review-interface-names)

---

<div class="post-metadata">

**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 23, 2019, 3:06 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/40 "2019-08-23T15:06:16Z")

</div>

Je connais les notes de publication. Certes, il y a un risque mais normalement cela ne devrait pas arriver lors d’une mise à niveau, d’autant que les hébergeur comme Scaleway ou OVH fournissent des versions légèrement personnalisées de Debian où les noms des interfaces sont fixées via des règles udev ou via systemd-networkd.  
Les commandes indiquées par [littlejohn75](https://www.debian-fr.org/u/littlejohn75) devraient permettre de s’en assurer.

C’est peut-être le problème mais avant il faut savoir si le serveur démarre avec un fichier /etc/network/interfaces propre.

---

<div class="post-metadata">

**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, 3:12 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/41 "2019-08-23T15:12:58Z")

</div>

> [@anon70622873](#):
>
> L’hébergeur Online n’a pas d’adresses IP à Singapour…

OK. Je n’avais pas fait le lien avec l’extrême orient.

> [@anon70622873](#):
>
> Quant au noms des interfaces, je doute fort que cela soit le problème.

Et mon serveur d’archivage qui a disparu du réseau suite à un redémarrage ? La piste du nom de l’interface est à creuser. Dans le mode de secours on passe par une voie non mise à jour. Par contre, avec le paquet `ifupdown` de Debian 10, on peut forcer le nom `eth0` dans une directive `auto` en donnant l’adresses MAC, je n’ai pas encore buster sur mon portable et ne peut donc pas donner la syntaxe exacte.

Cordialement,  
Regards,  
Mit freundlichen Grüßen,  
مع تحياتي الخالصة

* * *

F. Petitjean  
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »  
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

[Page précédente](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781.md?page=1)

[Page suivante](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781.md?page=3)