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…
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…
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.
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.
@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…
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 ?
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
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)
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.
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)
