Erreur openssh-server après upgrade

Je rencontre un problème depuis la mise à jour de mon serveur dédié OVH, le service ssh et en particulier openssh-server refuse de démarrer

Mon serveur tourne sous Debian Wheezy,

Linux version 3.10.23-xxxx-std-ipv6-64 (kernel@kernel.ovh.net) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Tue Mar 18 14:48:24 CET 2014 

Ssh version : OpenSSH_7.2p2 Debian-1, OpenSSL 1.0.2g

Voici ce que me retourne un : systemctl status ssh.service

● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since lun. 2016-03-21 13:19:32 CET; 9min ago
  Process: 16913 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255)
 Main PID: 16913 (code=exited, status=255)
  
mars 21 13:19:32 last-mohicans.net systemd[1]: Starting OpenBSD Secure Shell server..
mars 21 13:19:32 last-mohicans.net systemd[1]: ssh.service: Main process exited, code
mars 21 13:19:32 last-mohicans.net systemd[1]: Failed to start OpenBSD Secure Shells
mars 21 13:19:32 last-mohicans.net systemd[1]: ssh.service: Unit

entered failed statelines 1-10

J’ai eu beau faire un apt-get purge, autoclean, autoremove, reinstall etc rien n’y fait, j’ai également l’erreur lors de l’install ou lors d’un dpkg-reconfigure.

Help me please !

journalctl -xn peut être?

Il serait aussi intéressant de regarder le syslog je pense que openssh doit dire ce qui ne lui va pas

J’ai enfin réussi a résoudre mon problème et je vais expliquer comment.
Tout d’abord, je précise que le journalctl -xn n’a rien donné de plus que le systemctl status ssh.service.

La solution a été en fait de désinstaller complètement openssh-server et openssh-client, supprimer les dossier /etc/ssh, et tuer tous les proscessus ssh présent sur le serveur, sans quoi si il reste ne serait-ce qu’un processus alors la réinstallation via l’apt ou la reconfiguration via dpkg- reconfigure échouera systématiquement.

Le problème c’est qu’ici il s’agit d’un serveur dédié hébergé chez OVH, et que désinstaller openssh client/server reviens à couper l’accès au dédié.
Il m’a fallut passer par là et par le mode rescue pour pouvoir me connecter au serveur.
En mode rescue (dispo pour tous les serveur OVH / Kimsufi) il faut monter les partitions système et ensuite se chrooter dans l’une d’elle pour ensuite réinstaller openssh client/server.
La manip de connexion / montage de partition et chrootage est dispo sur le site d’OVH.
Une fois chrooté a votre partition système il vous suffit d’utiliser apt-get pour faire une réinstallation propre d’openssh.

Voilà c’était pas compliqué mais il m’a fallut me risquer à couper la connexion ssh et à passer en mode rescue, chose que je n’avais jamais fait avant.

Si ça peut aider quelqu’un …

Bonne journée a tous !

Hello,

3 ans après je me retrouve avec le même problème !

Suite à un upgrade vers Debian 10 sur mon serveur chez Online.net le paquet openssh-server n’arrive à se configurer.

root@fatmike:~# apt-get install -f 
Lecture des listes de paquets... Fait 
Construction de l'arbre des dépendances        
Lecture des informations d'état... Fait 
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour. 
2 partiellement installés ou enlevés. 
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés. 
Paramétrage de openssh-server (1:7.9p1-10) ... 
rescue-ssh.target is a disabled or a static unit, not starting it. 
Job for ssh.service failed because the control process exited with error code. 
See "systemctl status ssh.service" and "journalctl -xe" for details. 
invoke-rc.d: initscript ssh, action "restart" failed. 
● ssh.service - OpenBSD Secure Shell server 
  Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) 
  Active: failed (Result: exit-code) since Thu 2019-08-22 23:59:45 CEST; 89ms ago 
    Docs: man:sshd(8) 
          man:sshd_config(5) 
 Process: 37444 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS) 
 Process: 37445 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255/EXCEPTION) 
Main PID: 37445 (code=exited, status=255/EXCEPTION) 
dpkg: erreur de traitement du paquet openssh-server (--configure) : 
installed openssh-server package post-installation script subprocess returned error exit status 1 
dpkg: des problèmes de dépendances empêchent la configuration de ssh : 
ssh dépend de openssh-server (>= 1:7.9p1-10) ; cependant : 
Le paquet openssh-server n'est pas encore configuré. 

dpkg: erreur de traitement du paquet ssh (--configure) : 
problèmes de dépendances - laissé non configuré 
Des erreurs ont été rencontrées pendant l'exécution : 
openssh-server 
ssh 
E: Sub-process /usr/bin/dpkg returned an error code (1)

J’ai ensuite fait un remove de openssh-server et openssh-client et maintenant si je retente d’installer openssh-server j’ai plus que ça:

root@fatmike:~# apt-get install openssh-server            
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances        
Lecture des informations d'état... Fait
openssh-server est déjà la version la plus récente (1:7.9p1-10).
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
1 partiellement installés ou enlevés.
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n]  
Paramétrage de openssh-server (1:7.9p1-10) ...
Not replacing deleted config file /etc/ssh/sshd_config
dpkg: erreur de traitement du paquet openssh-server (--configure) :
installed openssh-server package post-installation script subprocess returned error exit status 1
Des erreurs ont été rencontrées pendant l'exécution :
openssh-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

Je vous cache pas que j’ai un peu peur de couper le serveur SSH comme a osé le faire Doremus :thinking:

Quelqu’un aurait une suggestion ?

C’est quand même plus que problématique d’avoir un souci avec son serveur SSH sur un serveur distant.

En tout cas là je ne peux même plus me connecter, j’ai juste une connexion SSH encore actives depuis mon laptop en sachant que Bouygues va certainement me faire une petite déconnexion dans les prochaines heures…

Merci pour votre aide, Vincent.

Bonjour,
Le paramétrage du paquet openssh-server échoue car le fichier de configuration du serveur a été supprimé manuellement :

Tu peux essayer de récréer ce fichier avec la bonne configuration et tenter à nouveau :
apt-get install -f
Sinon il faut purger le paquet puis ré-installler :

apt purge openssh-server

apt install openssh-server

Bonjour,

Oui en fait j’avais aussi supprimé le répertoire /etc/ssh en plus du remove du paquet. J’aurais pu faire un purge directement mais à priori j’étais dans le même état que si j’avais fait un “apt purge openssh-server” ? En tout cas l’install d’openssh-server ne passait toujours pas…

Doremus laissait entendre que le process d’upgrade de SSHD foirait cause du fait qu’il y ait des anciens process sshd qui tournaient. Mais c’est quand même dingue puisque la quasi totalité des serveurs qui font l’upgrade à Debian 10 doivent avoir des processes SSHD qui tournent.

Et évidemment cette nuit ma connexion SSH a été coupée, je ne peux donc plus me connecter.
Je viens de créer un ticket à Online pour leur demander de l’aide. Au pire je tenterai un mode rescue mais clairement je ne suis pas à l’aise.

Merci, Vincent.

Non. La preuve le paquet refuse de se configurer car le dossier a été supprimé manuellement.

Le fait qu’un service soit actif n’empêche pas sa mise un niveau. Il faudra simplement le relancer après.
Je pense plutôt que cela a « foiré » à cause d’une directive erronée dans la configuration (ou non compatible avec la nouvelle version). D’où l’importance de lire les notes de publication et très attentivement les messages dans la console lors d’une mise à niveau.

Lors de l’upgrade de sshd j’avais justement choisi d’écraser ma conf par celle du mainteneur et de ne pas conserver ma version ! C’est donc vraiment étonnant…

Bon quoiqu’il en soit je suis maintenant obligé de tenter le mode rescue d’online.net puisque dès que j’essaye de me connecter en SSH j’ai: ssh_exchange_identification: read: Connection reset by peer.

Comme je n’ai jamais fait ce genre de procédure j’aurais besoin d’avoir un peu d’aide.

D’après cette page d’online.net l’idée serait de rebooter avec un OS sur la réseau. Il n’y a pas de Debian mais j’imagine qu’il vaut mieux que je prenne Ubuntu.

Mais que devrais je faire concrètement ?

  1. d’abord un chroot ?
  2. apt-get update
  3. apt-get purge openssh-server
  4. apt-get install openssh-server

Merci, Vincent.

En fait je n’ai jamais fait de chroot, d’où ma crainte…

Si je suis cette page il semblerait que je doive monter pas mal de chose avant de faire le chroot: /dev et /proc et aussi /run et /sys ?

Je ne connais pas la procédure particulière pour les serveurs Online. Mais en général il faut :

  • identifier la partition système avec fdisk -l ou parted -l;
  • monter cette partition, par exemple /dev/sda1 sur /mnt :
    mount /dev/sda1 /mnt
  • monter les pseudo systèmes de fichiers indispensables :
for i in /sys /proc /run /dev /dev/pts; do mount --bind "$i" "/mnt$i"; done
  • faire le chroot :
    chroot /mnt
    Un fois dans le système chrooté tu pourras lancer tes commandes apt.

Merci pour ces instructions. Avec ça j’ai pu réinstaller proprement openssh-server:

root@195-154-216-106:~# apt-get purge openssh-server
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances        
Lecture des informations d'état... Fait
Le paquet suivant a été installé automatiquement et n'est plus nécessaire :
 openssh-sftp-server
Veuillez utiliser « sudo apt autoremove » pour le supprimer.
Les paquets suivants seront ENLEVÉS :
 openssh-server*
0 mis à jour, 0 nouvellement installés, 1 à enlever et 0 non mis à jour.
1 partiellement installés ou enlevés.
Après cette opération, 1 484 ko d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n]  
E: Impossible d'écrire le journal (Est-ce que /dev/pts est monté ?) - posix_openpt (19: Aucun périphérique de ce type)
(Lecture de la base de données... 73053 fichiers et répertoires déjà installés.)
Suppression de openssh-server (1:7.9p1-10) ...
Running in chroot, ignoring request.
Running in chroot, ignoring request: daemon-reload
Running in chroot, ignoring request: is-active
Running in chroot, ignoring request: stop
Running in chroot, ignoring request: stop
Running in chroot, ignoring request: daemon-reload
Traitement des actions différées (« triggers ») pour man-db (2.8.5-2) ...
(Lecture de la base de données... 73036 fichiers et répertoires déjà installés.)
Purge des fichiers de configuration de openssh-server (1:7.9p1-10) ...
Running in chroot, ignoring request: daemon-reload
Running in chroot, ignoring request: daemon-reload
Running in chroot, ignoring request: daemon-reload
Running in chroot, ignoring request: daemon-reload
Running in chroot, ignoring request: daemon-reload
Running in chroot, ignoring request: daemon-reload
Running in chroot, ignoring request: daemon-reload
Traitement des actions différées (« triggers ») pour systemd (241-5) ...
Running in chroot, ignoring request: daemon-reload
root@195-154-216-106:~# apt-get install openssh-server
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances        
Lecture des informations d'état... Fait
Paquets suggérés :
 molly-guard monkeysphere rssh ssh-askpass ufw
Les NOUVEAUX paquets suivants seront installés :
 openssh-server
0 mis à jour, 1 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 0 o/352 ko dans les archives.
Après cette opération, 1 484 ko d'espace disque supplémentaires seront utilisés.
Préconfiguration des paquets...
E: Impossible d'écrire le journal (Est-ce que /dev/pts est monté ?) - posix_openpt (19: Aucun périphérique de ce type)
Sélection du paquet openssh-server précédemment désélectionné.
(Lecture de la base de données... 73031 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../openssh-server_7.9p1-10_amd64.deb ...
Dépaquetage de openssh-server (1:7.9p1-10) ...
Paramétrage de openssh-server (1:7.9p1-10) ...

Creating config file /etc/ssh/sshd_config with new version
Creating SSH2 RSA key; this may take some time ...
2048 SHA256:24egjcAIlxS2026c1O0IHXveBs23vo2XZo9VKgr+OnY root@195-154-216-106 (RSA)
Creating SSH2 ECDSA key; this may take some time ...
256 SHA256:/CDBW+qVuAOb2cGoMpwF2bY+rQ8agN7ekx6lWvM2AZI root@195-154-216-106 (ECDSA)
Creating SSH2 ED25519 key; this may take some time ...
256 SHA256:GYlSn9Yv/+Gkm+2PfMM4uVMyNnQxn3eWj9vCazo4oaE root@195-154-216-106 (ED25519)
Created symlink /etc/systemd/system/sshd.service → /lib/systemd/system/ssh.service.
Created symlink /etc/systemd/system/multi-user.target.wants/ssh.service → /lib/systemd/system/ssh.service.
Running in chroot, ignoring request: daemon-reload
Running in chroot, ignoring request: is-active
rescue-ssh.target is a disabled or a static unit, not starting it.
Running in chroot, ignoring request: daemon-reload
Running in chroot, ignoring request.
Running in chroot, ignoring request: daemon-reload
Running in chroot, ignoring request: is-active
Running in chroot, ignoring request: start
Traitement des actions différées (« triggers ») pour man-db (2.8.5-2) ...
Traitement des actions différées (« triggers ») pour systemd (241-5) ...
Running in chroot, ignoring request: daemon-reload

Ensuite j’ai fait un “exit”, démonté les partitions et un “reboot”.

Je pensais que c’était gagné sauf que maintenant je n’arrive toujours pas à me connecter en SSH. C’est visiblement un probleme d’authentification (Permission denied). J’ai pourtant essayé avec un user non root au cas où le user root serait par défaut non autorisé.

Une idée ?

Ah en fait je n’avais pas quitté le mode “rescue”, c’était pour ça. Là je suis revenu en mode “normal” mais depuis mon serveur n’est plus pingable, j’attends la réponse du support d’Online.

As-tu bien redémarré le serveur en mode « normal » ?
Un redémarrage peut prendre plusieurs minutes…

Oui comme dis juste au dessus j’avais oublié de revenir en mode “normal” :wink:

Mais depuis que je suis revenu en mode “normal” le serveur n’est plus pingable, malgré un nouveau reboot (depuis leur console).

Quand au support technique ils ont osé me dire qu’ils ne peuvent rien faire car pour eux c’est un problème de configuration, incroyable !!

De plus les services de monitoring que je peux voir dans leur console disent que tout est ok (ping, HTTP et SSH seraient atteignable), sauf qu’ils m’ont aussi dit que leur monitoring était actuellement défaillant. Je trouve ça hallucinant…

L’assistance technique a probablement raison…

Tu es sûr que tu n’as pas un pare-feu ou un fail2ban qui aurais bloqué l’IP depuis la quelle tu te connectes ?

Sinon, il faut repasser en mode « rescue », refaire le chroot et vérifier la configuration réseau, le fstab, l’état des paquets (la mise à niveau a-t-elle été faite complètement et proprement ?) et tout ce qui pourrait empêcher ton serveur de démarrer normalement.

A priori le seul paquet qui était en souffrance suite à mon dist-upgrade était openssh-server, c’est en tout ce que disaient les logs d’apt-get. Et comme j’ai pu le réinstaller normalement tout doit être bon au niveau des paquets.

Je ne vois pas trop ce qui aurait pu changer au niveau de la configuration réseau ou de fstab.

Finalement le gars du support technique vient de me dire qu’il allait faire un mode rescue pour vérifier les disques, je vais donc attendre un peu…

Ton /etc/ssh/sshd_config n’avait eu aucune personnalisation de ta part
depuis la création de ton serveur ?

Oui j’avais du le toucher puisque lors de l’upgrade apt m’avait demandé si je voulais conserver mon fichier ou l’écraser par celui du mainteneur. Et j’avais choisi la 2e option, ce qui aurait du m’éviter tout souci…

PS: c’est un serveur dédié et non mutualisé

Erreur commune qui t’as fait perdre tout accès SSH.
Toutes tes optimisations et réglages de sshd_config ont été écrasés.
Mais en fait, c’est toi qui les a écrasés comme tout /etc/ssh.

La version du mainteneur est plutôt générique et certainement stricte.
Elle aurait dû être étudiée séparément pour voir éventuellement des différences.

J’ai planté récemment un raspberry en acceptant la version du mainteneur pour network-manager.

Ça ne change rien à la problématique il me semble.
Peut être des droits pour le SAV ?

Avec SSH, te connectais-tu en root ou avec un utilisateur ordinaire ?