Erreur openssh-server après upgrade

Support Debian
#62

Pour info j’ai envoyé les détails de cette étrange interface eth0:0 avec l’IP asiatique à Online, ils ne savent donc pas ce que c’est et supposent une éventuelle attaque:

Effectivement, le fait que cette IP soit inscrite dans le fichier est assez étrange. Êtes-vous certain que personne d’autre que vous n’a accédé au serveur par le passé ?
C’est peut-être une tentative de backdoor de votre serveur par un attaquant malveillant.
Autrement je n’ai malheureusement aucune idée de ce que pourrait faire cette IP dans le fichier, puisque nous ne l’avons pas rajouté non plus de notre côté.

J’ai envie de dire que c’est une raison de plus pour passer sur un nouveau serveur…

#63

Je te l’ai dit, il faut regarder le syslog (dans /var/log/syslog). Il y a quelque chose qui bloque le démarrage, ou au moins la mise en réseau, de ton serveur. À ce stade, seuls les logs permettront d’identifier le point de blocage.

Edit: je reviens sur la configuration étrange/erronée du fichier /etc/network/interfaces on y voyait en commentaire :

#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

puis plus loin une interface virtuelle à l’ancienne mode :

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

Le fichier a été modifié, par Vinz ou une autre personne avec une IP qui n’a rien à y faire. Vu la similarité des deux adresses on peut penser que la seconde ( 8.190.34.106 ⇒Singapour) résulte d’une faute de frappe en voulant recopier la première (88.190.34.106⇒freebox fibre optique). la stupidité et l’inutilité de la chose ne suggère pas une attaque mais bien une erreur de manipulation de quelqu’un qui à les droits root sur ce serveur.
Maintenant, si tu as le moindre doute sur le fait que ce serveur ait été compromis, mieux vaut refaire une installation complète et restaurer les données à partir des sauvegardes.

#64

Hmm voici mon syslog qui me semble très court et très obscur:

root@195-154-216-106:/$cat /var/log/syslog
Aug 23 00:00:45 fatmike kernel: [1562697.178 ytm[] eoddTeAah TPSre.2tm[] ortt.evc:Scedd
Aug 23 00:04:38 fatmike kernel: 35291.114 ytm[] eodn.<28>[156269611.158483] systemd[1]: systed-shutdwdsce:Sce ntcnfiguration has changed while unit has been runnn,n pnsce iedsrpo et h oktui sntfntoa ni etre.35291.050 ytm[] eodn.<28>[156269612.160272] systemd[1]: systemd-shutdownd.socket: Socket unit configuration has changed while unit has been running, no open socket file descriptor left. The socket unit is not functional until restarted.
Aug 23 00:09:01 fatmike kernel: 3[5295.055 ytm[] eodn.<30>[156269875.649689] systemd[1]: Starting Cean ppssinfls.
Aug 23 00:09:01 fatmike kernel: 25297.189 ytm[88] hssinla.evc:Fie ocnetsdu otejunlsce,inrn:Cneto eue
Aug 23 00:09:01 fatmike kernel: [156297.395 ytm[] hssinla.evc:Scedd
Aug 23 00:09:01 fatmike kernel: 36685811]ssed1:SatdCenppssinfls
Aug 23 00:39:01 fatmike kernel: 317.912 ytm[] trigCenppssinfls.
Aug 23 01:09:01 fatmike kernel: nh eso ie.<0>[15237.539 ytm[] trigCenppssinfls.
Aug 23 03:41:46 fatmike kernel: 367642]ssed1:crbtsrie ucee.<0>[156282637.751]ssed1:SatdCrbt
Aug 23 04:09:01 fatmike kernel: 26822082]ssed411:ppesocensrie aldt onc tott h ora okt goig oncinrfsd<30>[156284272.140717] systemd[1]: phpsessionclean.service: Succeeded.
Aug 23 05:05:35 fatmike kernel: 
Aug 23 05:05:35 fatmike kernel: 16864991]ssed1:rnue-01mut ucee.ossinsoe anhhle xtdwt nnw euncd 
Aug 23 05:39:01 fatmike kernel: y1:Satn la h eso ie..<28>[156289670.716800] systemd[47259]: phpsessionclean.service: Failed to connect stdout to the journal socket, ignoring: Connection refused
Aug 23 05:39:01 fatmike kernel: d1:SatdCenppssinfls
Aug 23 06:39:01 fatmike kernel: 0[5217.274 ytm[] tre la h eso ie. gDiyatugaeadcenatvte..12979]sstm[88] p-al-prd.evc:Fie ocnetsdu otejunlsce, goig oncinrfsdmyugaesrie ucee.<30>[156292423.627266] systemd[1]: Started Daily apt upgrade and clean actvitie.m] trigCenppssinfls.
Aug 23 06:39:01 fatmike kernel: evc:Scedd
Aug 23 07:09:01 fatmike kernel: <0[5256.480 ytm[] hssinla.evc:Scedd
Aug 23 07:39:01 fatmike kernel: 36988850]ssed1:Satn la h eso ie..<28>[156296868.917586] systemd[50036]: phpsessionclean.service: Failed to connect stdout to the journal socket, ignoring: Connection refused
Aug 23 08:09:01 fatmike kernel: 293 ytm[00] hssinla.evc:Fie ocnetsdu otejunlsce,inrn:Cneto eue
Aug 23 08:39:01 fatmike kernel: [156298668.7245 ytm[] tre la h eso ie.y] trigCenppssinfls.
Aug 23 09:09:01 fatmike kernel: [16027683] sytm[] hssinla.evc:Scedd
Aug 23 09:09:01 fatmike kernel: [1563027695] tre la s
Aug 23 09:39:01 fatmike kernel: 36.494 ytm[] trigCenppssinfls.
Aug 23 09:39:01 fatmike kernel: 3ssed1:SatdCenppssinfls
Aug 23 10:09:01 fatmike kernel: ttrigCenppssinfls.
Aug 23 10:09:02 fatmike kernel: ]SatdCenppssinfls
Aug 23 10:39:01 fatmike kernel: 36066014]ssed1:Satn la h eso ie..<28>[156307666.267480] systemd[54472]: phpsessionclean.servc:Fie ocnetsdu otejunlsce,inrn:Cneto eue
Aug 23 11:09:02 fatmike kernel: ed1:SatdCenppssinfls
Aug 23 11:39:01 fatmike kernel: [5403]ssed1:SatdCenppssinfls
#65

C’est bien le syslog que tu vois dans l’environnement chrooté ?
C’est totalement anormal tout ces caractères qui semblent insérés dans les lignes des logs…Ça ressemble à un fichier corrompu.
Je te suggère de sortir de l’environnement chrooté et de démonter la partition système. Puis de vérifier tes partitions avec fsck, exemple :
fsck -f -y /dev/sda1

#66

Oui c’était après le chroot mais je pense que c’est justes les caractères de formatage, j’ai corrigé mon post en faisant un coller avec Ctrl+Shift+V, et ça passe mieux là !

Sinon Online a déjà vérifié les disques et c’était ok pour eux…

#67

Les logs sont toujours aussi anormaux.
Vérifie quand même tes systèmes de fichiers avec fsck (je doute que l’assistance technique l’ai fait…).

#68

Qu’est ce qui est anormal exactement ?

Sinon voici les sorties de fsck sur sda1 et surtout sur sda2:

turman@195-154-216-106:~$ sudo fsck -f -y /dev/sda1
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
/boot: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (147595, counted=103259).
Fix? yes

Free inodes count wrong (47965, counted=47961).
Fix? yes


/boot: ***** FILE SYSTEM WAS MODIFIED *****
/boot: 231/48192 files (0.9% non-contiguous), 89489/192748 blocks
turman@195-154-216-106:~$ sudo fsck -f -y /dev/sda2
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
Pass 1: Checking inodes, blocks, and sizes
Inode 36703143 extent tree (at level 1) could be shorter.  Fix? yes

Inode 36703267 extent tree (at level 1) could be shorter.  Fix? yes

Inode 36706103 extent tree (at level 1) could be shorter.  Fix? yes

Inode 36707629 extent tree (at level 1) could be shorter.  Fix? yes

Inode 36708320 extent tree (at level 1) could be shorter.  Fix? yes

Inode 36708437 extent tree (at level 1) could be shorter.  Fix? yes

Inode 36709351 extent tree (at level 1) could be shorter.  Fix? yes

Inode 36832529 extent tree (at level 1) could be shorter.  Fix? yes

Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/: ***** FILE SYSTEM WAS MODIFIED *****
/: 2116603/60973056 files (1.8% non-contiguous), 188665339/243882765 blocks
#69

Ta partition sda1 contenait bien des erreurs qui ont été corrigés par fsck
Tu dois aussi vérifier sda2 de la même manière !

Que donne ensuite un redémarrage en mode normal ?

Si tu ne vois pas ce qui est anormal dans une ligne comme celle-ci :

systed-shutdwdsce:Sce ntcnfiguration has changed

je ne peux rien pour toi :wink:

#70

Je peux difficilement dire que je trouve ça “anormal” car je ne comprend rien à cette ligne, tout comme les autres d’ailleurs…

J’avais déjà lancé fsck sur les 2 partitions, c’est sda2 et pas sda1 qui a été corrigé. Edit: ah non c’est les 2 !

Je tente le mode normal…

#71

Oui, pardon j’avais lu trop rapidement. Le fsck a bien été fait sur les deux partitions et elles contenaient des erreurs toutes les deux.

Quoiqu’en dise l’assistance cela vaudra le coup de contrôler le disque avec smartctl

Pour les logs, c’est en anglais pas en klingon, donc lisible et compréhensible par un être humain…

#72

On ne peut quand même pas dire que cette ligne soit de l’anglais de Shakespeare:

Aug 23 00:04:38 fatmike kernel: 35291.114 ytm[] eodn.<28>[156269611.158483] systemd[1]: systed-shutdwdsce:Sce ntcnfiguration has changed while unit has been runnn,n pnsce iedsrpo et h oktui sntfntoa ni etre.35291.050 ytm[] eodn.<28>[156269612.160272] systemd[1]: systemd-shutdownd.socket: Socket unit configuration has changed while unit has been running, no open socket file descriptor left. The socket unit is not functional until restarted.

Je suis désolé mais je n’y comprend rien de rien !

Pour smartctl quelle commande exacte devrais je lancer ?

Sinon je suis revenu en mode rescue pour voir comment avait évolué le syslog:

turman@195-154-216-106:~$ sudo cat /mnt/var/log/syslog
Aug 23 00:00:45 fatmike kernel: [1562697.178 ytm[] eoddTeAah TPSre.2tm[] ortt.evc:Scedd
Aug 23 00:04:38 fatmike kernel: 35291.114 ytm[] eodn.<28>[156269611.158483] systemd[1]: systed-shutdwdsce:Sce ntcnfiguration has changed while unit has been runnn,n pnsce iedsrpo et h oktui sntfntoa ni etre.35291.050 ytm[] eodn.<28>[156269612.160272] systemd[1]: systemd-shutdownd.socket: Socket unit configuration has changed while unit has been running, no open socket file descriptor left. The socket unit is not functional until restarted.
Aug 23 00:09:01 fatmike kernel: 3[5295.055 ytm[] eodn.<30>[156269875.649689] systemd[1]: Starting Cean ppssinfls.
Aug 23 00:09:01 fatmike kernel: 25297.189 ytm[88] hssinla.evc:Fie ocnetsdu otejunlsce,inrn:Cneto eue
Aug 23 00:09:01 fatmike kernel: [156297.395 ytm[] hssinla.evc:Scedd
Aug 23 00:09:01 fatmike kernel: 36685811]ssed1:SatdCenppssinfls
Aug 23 00:39:01 fatmike kernel: 317.912 ytm[] trigCenppssinfls.
Aug 23 01:09:01 fatmike kernel: nh eso ie.<0>[15237.539 ytm[] trigCenppssinfls.
Aug 23 03:41:46 fatmike kernel: 367642]ssed1:crbtsrie ucee.<0>[156282637.751]ssed1:SatdCrbt
Aug 23 04:09:01 fatmike kernel: 26822082]ssed411:ppesocensrie aldt onc tott h ora okt goig oncinrfsd<30>[156284272.140717] systemd[1]: phpsessionclean.service: Succeeded.
Aug 23 05:05:35 fatmike kernel: 
Aug 23 05:05:35 fatmike kernel: 16864991]ssed1:rnue-01mut ucee.ossinsoe anhhle xtdwt nnw euncd 
Aug 23 05:39:01 fatmike kernel: y1:Satn la h eso ie..<28>[156289670.716800] systemd[47259]: phpsessionclean.service: Failed to connect stdout to the journal socket, ignoring: Connection refused
Aug 23 05:39:01 fatmike kernel: d1:SatdCenppssinfls
Aug 23 06:39:01 fatmike kernel: 0[5217.274 ytm[] tre la h eso ie. gDiyatugaeadcenatvte..12979]sstm[88] p-al-prd.evc:Fie ocnetsdu otejunlsce, goig oncinrfsdmyugaesrie ucee.<30>[156292423.627266] systemd[1]: Started Daily apt upgrade and clean actvitie.m] trigCenppssinfls.
Aug 23 06:39:01 fatmike kernel: evc:Scedd
Aug 23 07:09:01 fatmike kernel: <0[5256.480 ytm[] hssinla.evc:Scedd
Aug 23 07:39:01 fatmike kernel: 36988850]ssed1:Satn la h eso ie..<28>[156296868.917586] systemd[50036]: phpsessionclean.service: Failed to connect stdout to the journal socket, ignoring: Connection refused
Aug 23 08:09:01 fatmike kernel: 293 ytm[00] hssinla.evc:Fie ocnetsdu otejunlsce,inrn:Cneto eue
Aug 23 08:39:01 fatmike kernel: [156298668.7245 ytm[] tre la h eso ie.y] trigCenppssinfls.
Aug 23 09:09:01 fatmike kernel: [16027683] sytm[] hssinla.evc:Scedd
Aug 23 09:09:01 fatmike kernel: [1563027695] tre la s
Aug 23 09:39:01 fatmike kernel: 36.494 ytm[] trigCenppssinfls.
Aug 23 09:39:01 fatmike kernel: 3ssed1:SatdCenppssinfls
Aug 23 10:09:01 fatmike kernel: ttrigCenppssinfls.
Aug 23 10:09:02 fatmike kernel: ]SatdCenppssinfls
Aug 23 10:39:01 fatmike kernel: 36066014]ssed1:Satn la h eso ie..<28>[156307666.267480] systemd[54472]: phpsessionclean.servc:Fie ocnetsdu otejunlsce,inrn:Cneto eue
Aug 23 11:09:02 fatmike kernel: ed1:SatdCenppssinfls
Aug 23 11:39:01 fatmike kernel: [5403]ssed1:SatdCenppssinfls

Pas d’évolution… mais j’avais pas fait attention que ces logs concernaient seulement le 23/08 et rien pour hier et aujourd’hui… je suis perdu :frowning:

#73

Je te montre justement que tes logs sont illisibles car le fichier est corrompu :
systed-shutdwdsce:Sce ntcnfiguration
au lieu de quelque chose comme :
systemd-shutdownd.socket: Socket unit configuration

Sinon tu peux aussi regarder /var/log/messages (en mode rescue chrooté)

Si ton serveur n’a pas redémarré en mode normal après la correction des systèmes de fichiers et si la commande smartctl est disponible en mode rescue :
smartctl -a /dev/sda

#74

Il manque des arguments:

turman@195-154-216-106:~$ smartctl -a /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.15.0-22-generic] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

/dev/sda: requires option '-d cciss,N'
Please specify device type with the -d option.

Use smartctl -h to get a usage summary
#75

Pas normal, essaie :

smartctl -a -d ata /dev/sda

Sinon retour de :

smartctl --scan

Et attention, il faut être root pour utiliser smartctl.

#76

Voici la sortie (avec sudo et sans chroot):

turman@195-154-216-106:~$ sudo smartctl -a -d ata /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.15.0-22-generic] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

Read Device Identity failed: Inappropriate ioctl for device

A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
turman@195-154-216-106:~$ sudo smartctl --scan
# scan_smart_devices: glob(3) aborted matching pattern /dev/discs/disc*
#77

Sûrement une particularité du mode rescue qui n’a pas de /dev/discs
Essaie :

sudo smartctl -a -d scsi /dev/sda

ou
sudo smartctl -a -d sat /dev/sda

#78

La 1ere commande en scsi a fonctionné:

turman@195-154-216-106:~$ sudo smartctl -a -d scsi /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.15.0-22-generic] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HP
Product:              LOGICAL VOLUME
Revision:             5.12
User Capacity:        1 000 171 331 584 bytes [1,00 TB]
Logical block size:   512 bytes
Rotation Rate:        15000 rpm
Logical Unit id:      0x600508b1001c0d14d74713b1ea75631e
Serial number:        PACCRCN810D1QSA
Device type:          disk
Local Time is:        Sun Aug 25 11:50:31 2019 CEST
SMART support is:     Unavailable - device lacks SMART capability.

=== START OF READ SMART DATA SECTION ===
Current Drive Temperature:     0 C
Drive Trip Temperature:        0 C

Error Counter logging not supported

Device does not support Self Test logging
turman@195-154-216-106:~$ sudo smartctl -a -d sat /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.15.0-22-generic] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

Read Device Identity failed: scsi error unsupported scsi opcode

A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
#79

Je ne comprends pas le retour de la commande smartctl (RAID matériel ?)
Il faut voir s’il n’y a pas une procédure particulière en fonction du type de serveur :
https://documentation.online.net/en/dedicated-server/rescue/diagnosis-defective-disk

#80

Pas vraiment

De toute évidence votre serveur dédié est un HP (Proliant ou autre ). Les systèmes HP sont équipés d’un port iLO et le plus souvent d’un contrôleur de disque évolué (smartarray ) qui gère le RAID et qui est donc capable de présenter à l’OS un seul disque /dev/sda alors qu’il peut y avoir plusieurs disques physiques dans une grappe RAID qui aggrège ces disques.
Le pilote pour ces contrôleurs smartarray s’appelait cciss et maintenant hpsa. Mais la notation cciss a été conservée pour smartctl .
Pour gérer le RAID depuis l’OS, HP fournissait un utilitaire en ligne de commande nommé hpacucli et maintenant sous un autre nom qui m"échappe (1)
Tentez

sudo hpacucli ctl all show sconfig [details]

Pour obtenir le détail des disques physiques et logiques attaché au contrôleur RAID.
Pour smartctl commecez par obtenir les infos

sudo smartctl  -d 'cciss,0'  --info /dev/sda

et notez le numéro de série, puis avec -d cciss,1 faites de même (pas de risque)
Une fois que vous avez trouvé les disques physiques sous-jacents, vous pourrez obtenir les attributs SMART avec l’option --all.

Note
(1) C’est un sujet d’irritation pour moi, cette manie de modifier les noms sans raison tecnique. Visitez le site HP Entrepris.

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
#81

Attention les KVM/ILO,IPMI/IRADC nécessite l’utilisation d’une version complétement outdate en générale de java test avec la version 7 de java.

En suite pour l’utilisation de java il faux autoriser son utilisation par l’IP de l’ILO/IPMI etc (voir dans sécurité après être rentré dans la conf de la console java sur le système).

Si il n’y avait que ça récemment j’ai travaillé sur du dell, du hp, du supermicro et du quanta server (aucune majuscule et c’est voulu il n’y a aucun respect à avoir pour ces entreprises), c’est une honte de travailler sous linux et de devoir utilisé à 99% des binaires aussi obscures que le trou du c… (même l’odeur est là) avec des outils bien souvent pas à jour et pas toujours très stable …

Les serveurs sont chouettes mais alors le software …