Forum Linux.debian/ubuntu Le serveur ssh plante après 20 minutes (debian)

Posté par bug le 14 avril 2020 à 19:32. Licence CC By‑SA.

Étiquettes :

avr.

2020

J'ai installé sur mon pi raspbery (debian buster) un serveur nextcloud.
J'essaie de me connecter à mon serveur avec ssh mais, j'obtiens ceci :

$ ssh pi@192.168.1.36
> ssh : connect to host 192.168.1.36 port 22 : Connexion refusée

Sur mon serveur, je lance la commande : sudo systemctl status sshd, j'obtiens :

    ● ssh.service - Serveur OpenBSD Secure Shell
       Loaded : chargé (/lib/systemd/system/ssh.service ; activé ; vendor preset : activé)
       Actif : échec (Résultat : code de sortie) depuis Mon 2020-04-13 21:28:55 CEST ; il y a 17h
         Docs : man:sshd(8)
               man:sshd_config(5)
      Processus : 622 ExecStartPre=/usr/sbin/sshd -t (code=sortie, statut=1/FAILURE)

    13 avril 21:28:55 systemd [1] : ssh.service : Service RestartSec=100ms expiré, redémarrage de la programmation.
    13 avril 21:28:55 systemd [1] : ssh.service : Redémarrage programmé, le compteur de redémarrage est à 5.
    13 avril 21:28:55 systemd [1] : ssh.service : Redémarrage programmé, le compteur de redémarrage est à 5 : Arrêtez le serveur OpenBSD Secure Shell.
    13 Avril 21:28:55 systemd [1] : ssh.service : Demande de démarrage répétée trop rapidement.
    13 Avril 21:28:55 systemd [1] : ssh.service : Echec avec le résultat "exit-code".
    13 avril 21:28:55 systemd[1] : Echec du démarrage du serveur OpenBSD Secure Shell.

Quand je fais sudo apt purge openssh-server -y ; sudo apt install openssh-server -y.

Le serveur ssh fonctionne à nouveau pendant environ 20 minutes, puis s'arrête de fonctionner.

Pouvez-vous m'aider ?
Merci.

# Serveur en mode debug

Posté par Walter le 14 avril 2020 à 20:56. Évalué à 2.

Salut,

lance ton serveur ssh en mode debug : /usr/sbin/sshd -d -p 22

comme ça tu pourras voir pourquoi il plante dans la console
# Logs?

Posté par Lol Zimmerli (site web personnel, Mastodon) le 14 avril 2020 à 21:42. Évalué à 3.

Que dit

journalctl --since "-1 hour"|grep ssh

?

La gelée de coings est une chose à ne pas avaler de travers.
- [^] # Re: Logs?
  
  Posté par Lol Zimmerli (site web personnel, Mastodon) le 14 avril 2020 à 21:43. Évalué à 3.
  
  Et je te recommande de remplacer tes ; par des && dans tes one-liners :)
  
  La gelée de coings est une chose à ne pas avaler de travers.
- [^] # Re: Logs?
  
  Posté par bug le 15 avril 2020 à 11:31. Évalué à 1. Dernière modification le 15 avril 2020 à 11:32.
  Bonjour,
  
  Merci pour toutes vos réponses!
  
  Voici le résultat de la commande "journalctl --since "-1 hour"|grep ssh"
```
avril 15 10:07:55  sudo[3854]:     root : TTY=tty1 ; PWD=/home/pi ; USER=root ; COMMAND=/usr/bin/apt purge openssh-server -y
avril 15 10:08:14  userdel[4242]: delete user 'sshd'
avril 15 10:08:17  sudo[4283]:     root : TTY=tty1 ; PWD=/home/pi ; USER=root ; COMMAND=/usr/bin/apt install openssh-server -y
avril 15 10:08:26  useradd[4453]: new user: name=sshd, UID=107, GID=65534, home=/run/sshd, shell=/usr/sbin/nologin
avril 15 10:08:27  usermod[4460]: change user 'sshd' password
avril 15 10:08:27  chage[4466]: changed password expiry for sshd
avril 15 10:08:31  sshd[4575]: Server listening on 0.0.0.0 port 22.
avril 15 10:08:31  sshd[4575]: Server listening on :: port 22.
avril 15 10:13:04  sshd[4716]: Connection closed by 192.168.1.78 port 53144 [preauth]
avril 15 10:15:28  sshd[4734]: Accepted password for pi from 192.168.1.78 port 53220 ssh2
avril 15 10:15:28  sshd[4734]: pam_unix(sshd:session): session opened for user pi by (uid=0)
avril 15 10:30:32  systemd[1]: ssh.service: Main process exited, code=killed, status=9/KILL
avril 15 10:30:32  systemd[1]: ssh.service: Failed with result 'signal'.
avril 15 10:30:32  systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
avril 15 10:30:32  systemd[1]: ssh.service: Scheduled restart job, restart counter is at 1.
avril 15 10:30:32  sshd[4895]: /etc/ssh/sshd_config line 84: Unsupported option UsePAM
avril 15 10:30:32  sshd[4895]: Could not load host key: /etc/ssh/ssh_host_rsa_key
avril 15 10:30:32  sshd[4895]: Could not load host key: /etc/ssh/ssh_host_dsa_key
avril 15 10:30:32  sshd[4895]: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
avril 15 10:30:32  sshd[4895]: Disabling protocol version 2. Could not load host key
avril 15 10:30:32  sshd[4895]: sshd: no hostkeys available -- exiting.
avril 15 10:30:32  systemd[1]: ssh.service: Control process exited, code=exited, status=1/FAILURE
avril 15 10:30:32  systemd[1]: ssh.service: Failed with result 'exit-code'.
avril 15 10:30:32  systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
avril 15 10:30:32  systemd[1]: ssh.service: Scheduled restart job, restart counter is at 2.
avril 15 10:30:32  sshd[4918]: /etc/ssh/sshd_config line 84: Unsupported option UsePAM
avril 15 10:30:32  sshd[4918]: Could not load host key: /etc/ssh/ssh_host_rsa_key
avril 15 10:30:32  sshd[4918]: Could not load host key: /etc/ssh/ssh_host_dsa_key
avril 15 10:30:32  sshd[4918]: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
avril 15 10:30:32  sshd[4918]: Disabling protocol version 2. Could not load host key
avril 15 10:30:32  sshd[4918]: sshd: no hostkeys available -- exiting.
avril 15 10:30:32  systemd[1]: ssh.service: Control process exited, code=exited, status=1/FAILURE
vril 15 10:30:32   systemd[1]: ssh.service: Failed with result 'exit-code'.
avril 15 10:30:32  systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
avril 15 10:30:32  systemd[1]: ssh.service: Scheduled restart job, restart counter is at 3.
avril 15 10:30:32  sshd[4927]: /etc/ssh/sshd_config line 84: Unsupported option UsePAM
avril 15 10:30:32  sshd[4927]: Could not load host key: /etc/ssh/ssh_host_rsa_key
avril 15 10:30:32  sshd[4927]: Could not load host key: /etc/ssh/ssh_host_dsa_key
avril 15 10:30:32  sshd[4927]: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
avril 15 10:30:32  sshd[4927]: Disabling protocol version 2. Could not load host key
avril 15 10:30:32  sshd[4927]: sshd: no hostkeys available -- exiting.
avril 15 10:30:33  systemd[1]: ssh.service: Control process exited, code=exited, status=1/FAILURE
avril 15 10:30:33  systemd[1]: ssh.service: Failed with result 'exit-code'.
avril 15 10:30:33  systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
avril 15 10:30:33  systemd[1]: ssh.service: Scheduled restart job, restart counter is at 4.
avril 15 10:30:33  sshd[4941]: /etc/ssh/sshd_config line 84: Unsupported option UsePAM
avril 15 10:30:33  sshd[4941]: Could not load host key: /etc/ssh/ssh_host_rsa_key
avril 15 10:30:33  sshd[4941]: Could not load host key: /etc/ssh/ssh_host_dsa_key
avril 15 10:30:33  sshd[4941]: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
avril 15 10:30:33  sshd[4941]: Disabling protocol version 2. Could not load host key
avril 15 10:30:33  sshd[4941]: sshd: no hostkeys available -- exiting.
avril 15 10:30:33  systemd[1]: ssh.service: Control process exited, code=exited, status=1/FAILURE
avril 15 10:30:33  systemd[1]: ssh.service: Failed with result 'exit-code'.
avril 15 10:30:33  systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
avril 15 10:30:33  systemd[1]: ssh.service: Scheduled restart job, restart counter is at 5.
avril 15 10:30:33  sshd[4957]: /etc/ssh/sshd_config line 84: Unsupported option UsePAM
avril 15 10:30:33  sshd[4957]: Could not load host key: /etc/ssh/ssh_host_rsa_key
avril 15 10:30:33  sshd[4957]: Could not load host key: /etc/ssh/ssh_host_dsa_key
avril 15 10:30:33  sshd[4957]: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
avril 15 10:30:33  sshd[4957]: Disabling protocol version 2. Could not load host key
avril 15 10:30:33  sshd[4957]: sshd: no hostkeys available -- exiting.
avril 15 10:30:33  systemd[1]: ssh.service: Control process exited, code=exited, status=1/FAILURE
avril 15 10:30:33  systemd[1]: ssh.service: Failed with result 'exit-code'.
avril 15 10:30:33  systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
avril 15 10:30:33  systemd[1]: ssh.service: Failed with result 'exit-code'.
avril 15 10:30:33  systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
avril 15 10:30:33  systemd[1]: ssh.service: Scheduled restart job, restart counter is at 6.
avril 15 10:30:33  systemd[1]: ssh.service: Start request repeated too quickly.
avril 15 10:30:33  systemd[1]: ssh.service: Failed with result 'exit-cod
```
  La commande /usr/sbin/sshd -d -p 22 : Renvoie quelque chose de similaire
  
  J'ai donc essayé : ssh-keygen -A Sans succès
  
  Auriez-vous une idée du problème ?
  
  Merci d'avance.
  - [^] # Re: Logs?
    
    Posté par NeoX le 15 avril 2020 à 12:27. Évalué à 3.
    2problemes d'apres les LOGs
    
    avril 15 10:30:33 sshd[4957]: /etc/ssh/sshd_config line 84: Unsupported option UsePAM
    
    ligne 84, l'option UsePAM ne semble pas être appréciée
    
    avril 15 10:30:33 sshd[4957]: Could not load host key: /etc/ssh/ssh_host_rsa_key
    avril 15 10:30:33 sshd[4957]: Could not load host key: /etc/ssh/ssh_host_dsa_key
    avril 15 10:30:33 sshd[4957]: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
    avril 15 10:30:33 sshd[4957]: Disabling protocol version 2. Could not load host key
    
    il ne semble pas trouvé les clefs, ou les clefs n'ont pas les bons droits.
    
    si tu as la main physiquement sur la machine,
    
    sauvegarde les fichiers de configs et les clefs
    tar zxcvf /root/openssh-down.tgz /etc/ssh* /etc/sshd*
    
    supprimes tout
```
apt purge openssh-server
rm -rf /etc/ssh*
```
    reinstalle
    apt install opens-server
    
    ca va remettre le fichier de config par défaut, refaire les clefs SSHs
    - [^] # Re: Logs?
      
      Posté par bug le 16 avril 2020 à 10:09. Évalué à 1. Dernière modification le 16 avril 2020 à 10:09.
      
      Bonjour,
      
      Merci pour votre réponse, j'ai bien fait ce que vous m'avez demandé mais après 10-15 minutes le serveur coupe la connexion et impossible de m'y reconnecter.
      
      C'est à perdre la tête :).
    - [^] # Re: Logs?
      
      Posté par aiolos le 16 avril 2020 à 10:11. Évalué à 1.
      
      Si les clefs disparaissent en cours d'utilisation, ce ne serait pas un problème sur un disque ?
      - [^] # Re: Logs?
        
        Posté par bug le 16 avril 2020 à 14:52. Évalué à 1.
        
        Les clefs sont toujours présentes mais impossible des les utiliser. Si c'est un problème de disque pourquoi il y a que ssh qui plante ?
        
        [^] # Re: Logs?
        
        Posté par NeoX le 16 avril 2020 à 16:56. Évalué à 2.
        
        il y a que ssh qui plante ?
        
        et il n'y a que SSH qui plante, ou la machine n'est plus du tout joignable, en web, en ftp, en vnc… ?
        
        [^] # Re: Logs?
        
        Posté par bug le 16 avril 2020 à 20:47. Évalué à 1.
        
        Il y a bien que le serveur ssh qui plante sinon tout fonctionne parfaitement (apache, mariadb…).
        
        [^] # Re: Logs?
        
        Posté par NeoX le 17 avril 2020 à 09:17. Évalué à 2.
        
        problème d'espace disque saturé ?
        
        SSH a besoin d'écrire sur le disque quand on se connecte
        
        apache et mariaDB sont généralement en lecture, sauf quand on upload un fichier, ou quand on ajoute des données sur le disque
  - [^] # Re: Logs?
    
    Posté par Thibault (site web personnel) le 16 avril 2020 à 21:59. Évalué à 1.
    
    Salut,
    
    avril 15 10:30:32 systemd[1]: ssh.service: Main process exited, code=killed, status=9/KILL
    avril 15 10:30:32 systemd[1]: ssh.service: Failed with result 'signal'.
    avril 15 10:30:32 systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
    avril 15 10:30:32 systemd[1]: ssh.service: Scheduled restart job, restart counter is at 1.
    
    Le premier truc bizarre, c'est que sshd est tué violemment (SIGKILL). Cela ne devrait pas arriver naturellement. Peut-être un problème de pas assez de mémoire ?
    Je te suggère d'aller vérifier dans le journal ce qui se passe autour de 10:30:32.
    
    Le second truc bizarre c'est que tu sembles arriver à démarrer ssh à la main, mais avec l'unit de systemd cela ne fonctionne pas. C'est la même configuration utilisée entre le démarrage à la main et le démarrage via systemd (tu peux aller voir le fichier unit ssh.service ce qu'il y a dedans et lancer la même commande, normalement tu devrais avoir le même résultat). Cela pourrait potentiellement venir d'un problème de droit sur tes clefs.
    
    Bon courage.
    - [^] # Re: Logs?
      
      Posté par bug le 17 avril 2020 à 19:04. Évalué à 1. Dernière modification le 17 avril 2020 à 19:06.
      Bonjour,
      
      Merci pour vos réponses.
      
      Je pense que le problème d'espace peut-être écarté. Voici le retour de df -h:
      Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/root 118G 107G 5,9G 95% / devtmpfs 465M 0 465M 0% /dev tmpfs 469M 0 469M 0% /dev/shm tmpfs 469M 24M 446M 6% /run tmpfs 5,0M 4,0K 5,0M 1% /run/lock tmpfs 469M 0 469M 0% /sys/fs/cgroup /dev/mmcblk0p1 253M 53M 200M 21% /boot tmpfs 94M 0 94M 0% /run/user/1000
      
      Voici le fichier ssh.service
      
      [Unit] Description=OpenBSD Secure Shell server Documentation=man:sshd(8) man:sshd_config(5) After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Service] EnvironmentFile=-/etc/default/ssh ExecStartPre=/usr/sbin/sshd -t ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/usr/sbin/sshd -t ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartPreventExitStatus=255 Type=notify RuntimeDirectory=sshd RuntimeDirectoryMode=0755
      
      En effet, quand je fais /usr/sbin/sshd -t j'ai les même erreurs.
      Could not load host key…
      
      Si c'est un problème de droit comment lui donner ?
      
      P.S : J'ai remarqué quand je fais apt install openssh-server après l'avoir désinstallé, il y a cette ligne : rescue-ssh.target is a disabled or a static unit, not starting it.
      
      Merci
      - [^] # Re: Logs?
        
        Posté par NeoX le 18 avril 2020 à 11:19. Évalué à 2.
        
        Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
        /dev/root 118G 107G 5,9G 95% /
        […]
        
        ton disque est plein (107Go occupé pour 118Go total, reste 5.9Go, soit 5%)
        seul root peut travailler dedans, sur les 5% restants
        
        fait un peu de place sur ton disque, et ca devrait rentrer dans l'ordre
        
        [^] # Re: Logs?
        
        Posté par bug le 18 avril 2020 à 14:38. Évalué à 1. Dernière modification le 18 avril 2020 à 14:39.
        
        J'ai fais un peux de place comme vous me l'avez demandé, j'ai maintenant 32GO de libre.
        
        J'ai aussi fais un redémarrage mais le problème persiste. :)
        
        [^] # Re: Logs?
        
        Posté par NeoX le 18 avril 2020 à 16:29. Évalué à 2.
        
        J'ai aussi fais un redémarrage mais le problème persiste. :)
        
        toujours à 15/20minutes, ou ca tient plus longtemps ?
        si tu laisses une ligne ssh ouverte, et que tu surveilles l'espace disque, et quelques valeurs, ca dit quoi ?
        
        avec screen ou tmux, tu peux avoir plusieurs "écrans" pour afficher
        top ou htop dans l'un
        watch df -h dans un autre,
        
        parce que c'est vraiment bizarre ton ssh qui se stoppe tout seul.
        tu as regardé la RAM utilisée (free -m ou top)
        
        voire dans les logs si ssh se fait OOMkillé (OutOfMemory Kill),
        c'est un truc qui tu les process qui consomment trop
        
        [^] # Re: Logs?
        
        Posté par bug le 19 avril 2020 à 14:45. Évalué à 1.
        
        Merci pour votre réponse,
        
        Quand la connexion se coupe le RAM reste constante (300Mo/1Go), quand a l'espace disque libre il ne change pas.
        
        voire dans les logs si ssh se fait OOMkillé (OutOfMemory Kill), c'est un truc qui tu les process qui consomment trop
        
        Je n'ai pas trouvé le moyen de le trouver dans les logs, comment faire s'il vous plaît ?
        
        [^] # Re: Logs?
        
        Posté par NeoX le 20 avril 2020 à 09:39. Évalué à 2.
        
        Je n'ai pas trouvé le moyen de le trouver dans les logs, comment faire s'il vous plaît ?
        
        en ligne de commande je fais ca
        
        grep -I oomkill /var/log/lefichier.log
        
        le fichier log peut être messages, syslog, daemon.log ca depend des distributions
  - [^] # Re: Logs?
    
    Posté par benoar le 20 avril 2020 à 15:03. Évalué à 2.
    Tu t'es fait trouer ? La première fois que SSH est lancé, il se lance sans problème et ne dit pas avoir d'option inconnue dans la config. De plus, les clés doivent bien exister à ce moment-là.
    avril 15 10:08:31 sshd[4575]: Server listening on 0.0.0.0 port 22. avril 15 10:08:31 sshd[4575]: Server listening on :: port 22.Ensuite, un KILL sorti de nulle part, et redémarrage avec une conf différente (ou un binaire différent ne supportant pas PAM), et les clés manquantes ? J'imagine en fait un binaire spécifique compilé par un attaquant, avec des clés statiques dedans où un truc du genre.
```
avril 15 10:30:32  sshd[4895]: /etc/ssh/sshd_config line 84: Unsupported option UsePAM
avril 15 10:30:32  sshd[4895]: Could not load host key: /etc/ssh/ssh_host_rsa_key
avril 15 10:30:32  sshd[4895]: Could not load host key: /etc/ssh/ssh_host_dsa_key
avril 15 10:30:32  sshd[4895]: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
avril 15 10:30:32  sshd[4895]: Disabling protocol version 2. Could not load host key
avril 15 10:30:32  sshd[4895]: sshd: no hostkeys available -- exiting.
```
    Bref, quelqu'un est en train de faire quelque-chose dans ton dos, ou a (plus probablement) installé un RAT ou autre truc du genre. Vérifie que ta machine n'est pas infectée.
# Commentaire supprimé

Posté par Yosinbb le 17 avril 2020 à 08:25. Évalué à 0. Dernière modification le 17 avril 2020 à 08:53.

Ce commentaire a été supprimé par l’équipe de modération.
# re

Posté par bug le 19 avril 2020 à 19:10. Évalué à 1.

Cependant la RAM + plus le cache semble saturé la mémoire
- [^] # Re: re
  
  Posté par bug le 19 avril 2020 à 21:23. Évalué à 1.
  
  Non, après plusieurs essaie la RAM est à environ 120Mo et le server ssh plante toujours
# re

Posté par bug le 21 avril 2020 à 11:40. Évalué à 1.

Je sais que mon problème est un peux bizzard mais si vous avez une idée je suis preneur.

:)
- [^] # Re: re
  
  Posté par Lol Zimmerli (site web personnel, Mastodon) le 21 avril 2020 à 23:14. Évalué à 2.
  
  Que donne
  ls -als /etc/ssh/*key
  
  La gelée de coings est une chose à ne pas avaler de travers.
  - [^] # Re: re
    
    Posté par bug le 22 avril 2020 à 11:29. Évalué à 1.
    
    Bonjour,
    
    Merci pour votre message
    
    Voici le retour de ls -als /etc/ssh/*key
    
    4 -rw------- 1 root root 513 avril 21 11:51 /etc/ssh/ssh_host_ecdsa_key
    4 -rw------- 1 root root 411 avril 21 11:51 /etc/ssh/ssh_host_ed25519_key
    4 -rw------- 1 root root 1823 avril 21 11:51 /etc/ssh/ssh_host_rsa_key
    - [^] # Re: re
      
      Posté par Lol Zimmerli (site web personnel, Mastodon) le 30 avril 2020 à 23:53. Évalué à 2.
      
      J'ai vu que tu avais réglé le problème, extra. Mais pour être complet, je remarque que le log mentionne
      
      Could not load host key: /etc/ssh/ssh_host_dsa_key
      
      Et que cette clé n'est pas dans le résultat du ls
      
      La gelée de coings est une chose à ne pas avaler de travers.
# Solution

Posté par bug le 23 avril 2020 à 20:21. Évalué à 2.

Bonjour à tous !!

J'ai trouvé le problème, le système de fichier était HS.

Merci pour votre aide

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.