# 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:** 4

<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 25, 2019, 7:07 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/62 "2019-08-25T07:07:49Z")

</div>

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…

---

<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 25, 2019, 7:08 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/63 "2019-08-25T07:08:01Z")

</div>

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

---

<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 25, 2019, 7:11 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/64 "2019-08-25T07:11:01Z")

</div>

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

---

<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 25, 2019, 7:31 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/65 "2019-08-25T07:31:43Z")

</div>

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`

---

<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 25, 2019, 7:39 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/66 "2019-08-25T07:39:39Z")

</div>

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…

---

<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 25, 2019, 7:44 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/67 "2019-08-25T07:44:12Z")

</div>

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

---

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

</div>

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

---

<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 25, 2019, 7:57 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/69 "2019-08-25T07:57:21Z")

</div>

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 :

```auto
systed-shutdwdsce:Sce ntcnfiguration has changed

```

je ne peux rien pour toi 😉

---

<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 25, 2019, 8:09 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/70 "2019-08-25T08:09:25Z")

</div>

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…

---

<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 25, 2019, 8:16 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/71 "2019-08-25T08:16:42Z")

</div>

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…

---

<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 25, 2019, 8:34 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/72 "2019-08-25T08:34:14Z")

</div>

> [@anon70622873](#):
>
> Pour les logs, c’est en anglais pas en klingon, donc lisible et compréhensible par un être humain…

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 ☹

---

<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 25, 2019, 8:59 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/73 "2019-08-25T08:59:20Z")

</div>

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`

---

<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 25, 2019, 9:04 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/74 "2019-08-25T09:04:03Z")

</div>

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

---

<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 25, 2019, 9:07 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/75 "2019-08-25T09:07:27Z")

</div>

Pas normal, essaie :

`smartctl -a -d ata /dev/sda`

Sinon retour de :

`smartctl --scan`

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

---

<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 25, 2019, 9:13 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/76 "2019-08-25T09:13:57Z")

</div>

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*
> 
> ```

---

<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 25, 2019, 9:24 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/77 "2019-08-25T09:24:32Z")

</div>

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

```auto
sudo smartctl -a -d scsi /dev/sda

```

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

---

<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 25, 2019, 9:52 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/78 "2019-08-25T09:52:03Z")

</div>

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

---

<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 25, 2019, 10:41 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/79 "2019-08-25T10:41:16Z")

</div>

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](https://documentation.online.net/en/dedicated-server/rescue/diagnosis-defective-disk)

---

<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 25, 2019, 10:43 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/80 "2019-08-25T10:43:44Z")

</div>

> [@Vinz](#):
>
> La 1ere commande en scsi a fonctionné:

Pas vraiment

> [@Vinz](#):
>
> SMART support is: Unavailable - device lacks SMART capability.

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

```plaintext
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

```plaintext
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)

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Août 25, 2019, 11:08 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/81 "2019-08-25T11:08:00Z")

</div>

> [@Vinz](#):
>
> Alors j’ai essayé iLO avec 3 manières différentes mais sans succès:

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

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

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 …

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

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