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 ?
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 :
fdisk -l ou parted -l;mount /dev/sda1 /mnt
for i in /sys /proc /run /dev /dev/pts; do mount --bind "$i" "/mnt$i"; done
chroot /mntMerci 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” 
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 ?
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…
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…
Alors je laisse le soin à d’autres pour t’aider.
Je ne connais pas assez.
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) ?
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.