Erreur openssh-server après upgrade

Support Debian
#21

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:

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…

#23

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 “normal”. C’est donc certainement un problème de plus “bas niveau”, au niveau du boot ou de la config réseau sans doute…

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

#24

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

#25

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) ?

#26

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.

#27

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é :frowning:
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.

#28

@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.

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…

#29

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.

#30

Alors pour iptables:

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:

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 ?

#31

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

#32

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…

#33

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é.

#34

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

#35

Tu vires tout ce bloc :

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

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)

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

sudo fgrep -r eth0 /etc

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

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

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)

1 J'aime
#37

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)

1 J'aime
#38

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.

#39

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

#40

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 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.

#41

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

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)