# Serveur ssh extrêmement long à se lancer tant qu'aucun utilisateur n'est connecté localement

**URL:** <https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270>\
**Category:** Support Debian\
**Tags:** serveur, ssh, systemd\
**Created:** [Décembre 27, 2018, 8:49 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270 "2018-12-27T08:49:38Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![kro](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kro/32/7458_2.png) [@kro](https://www.debian-fr.org/u/kro)\
**Post date:** [Décembre 27, 2018, 8:49 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/1 "2018-12-27T08:49:39Z")

</div>

Bonjour, je viens d’installer debian testing (buster) sur mon nuc que j’utilise comme serveur.

Le système démarre en quelque secondes, mais j’ai un problème avec mon serveur SSH, le service met plus de 4 minutes à démarrer une fois que le service est lancé :

```
krodelabestiole@micropoutre:~$ sudo journalctl /usr/sbin/sshd
[sudo] Mot de passe de krodelabestiole : 
-- Logs begin at Thu 2018-12-27 09:35:41 CET, end at Thu 2018-12-27 09:42:32 CET. --
déc. 27 09:39:12 micropoutre sshd[418]: Server listening on 0.0.0.0 port 12754.
déc. 27 09:39:12 micropoutre sshd[418]: Server listening on :: port 12754.

```

J’ai remarqué que si je me connecte localement avec un utilisateur, le service est accessible immédiatement.  
Tant que le service n’est pas lancé, le port 12754 apparaît évidemment comme fermé.  
Le problème se pose aussi bien avec une connexion par mot de passe que par clé, et mon répertoire home n’est pas chiffré.  
Le serveur est “pingable” quelques secondes après son démarrage (ip statique).

J’aimerais bien éviter d’avoir à attendre 5 minutes à chaque fois que je redémarre.  
Quelqu’un aurait une idée de la raison de cette lenteur, ou un moyen d’avoir plus d’information sur ce qui pourrait en être à l’origine ?  
merci !

---

<div class="post-metadata">

**Author:** ![anonyme2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f08c70/32.png) [@anonyme2](https://www.debian-fr.org/u/anonyme2)\
**Post date:** [Décembre 27, 2018, 1:23 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/2 "2018-12-27T13:23:41Z")

</div>

essaye ton serveur ssh depuis

> **[SSH Server Test - Check SSH Connectivity](https://www.infobyip.com/sshservertest.php)**
>
> Check that an SSH server is reachable from the internet and see the version banner it returns.

Depuis ta machine tu ne peux te connecter sur ton ssh que en local. Le lien donné te permet de te connecter depuis une adesse extérieure. Tu verras alors mieux ce qui se passe.

---

<div class="post-metadata">

**Author:** ![kro](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kro/32/7458_2.png) [@kro](https://www.debian-fr.org/u/kro)\
**Post date:** [Décembre 27, 2018, 1:40 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/3 "2018-12-27T13:40:47Z")

</div>

merci pour ta réponse  
ceci dit en local ou pas ça ne change rien : le port n’est pas “en écoute”.  
ça vient de debian lui même. quel que soit le moyen d’y accéder (boucle locale / ip / nom de domaine) ça ne change rien : le service ne fonctionne pas avant plusieurs minutes.  
tu peux voir dans les logs que systemd essaie de démarrer le service à 9h35, mais que ssh ne se met pas en écoute avant 9h39. ce qui se constate dans la pratique avec nmap ou autre : pas d’écoute sur le port 12754 avant 9h39.

---

<div class="post-metadata">

**Author:** ![kro](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kro/32/7458_2.png) [@kro](https://www.debian-fr.org/u/kro)\
**Post date:** [Décembre 27, 2018, 1:50 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/4 "2018-12-27T13:50:56Z")

</div>

le contenu de /etc/systemd/system/ssd.service  
(c’est celui par défaut je n’y ai pas touché) :

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

[Install]
WantedBy=multi-user.target
Alias=sshd.service

```

le service démarre donc après network.target et auditd.service  
j’imagine que la condition network.target est déjà validée vu que je peux pinger la machine quelques secondes après le boot.  
je sais pas à quoi correspond auditd.service.  
est-ce qu’il y a moyen de monitorer ce genre de choses ?

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 27, 2018, 2:00 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/5 "2018-12-27T14:00:28Z")

</div>

Tu peux exécuter

```
systemd-analyze critical-chain sshd.service

```

pour voir d’où vient le délai.  
Tu peux aussi regarder dans les logs de sshd qui doivent se trouver dans /var/log/auth\*.log.

---

<div class="post-metadata">

**Author:** ![kro](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kro/32/7458_2.png) [@kro](https://www.debian-fr.org/u/kro)\
**Post date:** [Décembre 27, 2018, 2:10 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/6 "2018-12-27T14:10:44Z")

</div>

merci pour ces conseils

```
ssh.service +36.606s
└─network.target @875ms
  └─networking.service @629ms +245ms
    └─local-fs.target @627ms
      └─boot-efi.mount @602ms +24ms
        └─dev-disk-by\x2duuid-5004\x2d41A7.device @548ms

```

je ne vois rien de particulier…  
pareil, j’avais regardé dans auth.log, mais rien trouvé d’intéressant :

```
Dec 27 09:35:41 micropoutre systemd-logind[395]: New seat seat0.
Dec 27 09:35:41 micropoutre systemd-logind[395]: Watching system buttons on /dev/input/event1 (Power Button)
Dec 27 09:35:41 micropoutre systemd-logind[395]: Watching system buttons on /dev/input/event0 (Power Button)
Dec 27 09:35:42 micropoutre systemd-logind[395]: Watching system buttons on /dev/input/event3 (Nuvoton w836x7hg Infrared Remote Transceiver)
Dec 27 09:39:12 micropoutre sshd[418]: Server listening on 0.0.0.0 port 12754.
Dec 27 09:39:12 micropoutre sshd[418]: Server listening on :: port 12754.
```

---

<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:** [Décembre 27, 2018, 6:30 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/7 "2018-12-27T18:30:33Z")

</div>

> [@kro](#):
>
> J’ai remarqué que si je me connecte localement avec un utilisateur, le service est accessible immédiatement.

À mon avis, il y a un problème d’entropie. Au démarrage le système bloque le lancement effectif des démons tels que `sshd` qui font appel au générateur de nombres pseudo-aléatoires tant qu’il n’y a pas suffisamment d’entropie. Une fois que quelqu’un est connecté localement l les sources d’aléa sont beaucoup plus nombreuses (des interruptions liées au déplacement d’une souris par exemple) et le déficit d’entropie est vite comblé.

> [@kro](#):
>
> mon nuc que j’utilise comme serveur.

Avec ce genre d’appareil minimaliste, le noyau a très peu de sources d’entropie fiable.  
Je n’arrive pas à retrouver sur quelle liste de diffusion ce problème était abordé.

Cordialement,  
Regards,  
Mit freundlichen Grüßen,  
مع تحياتي الخالصة

* * *

F. Petitjean  
Ingénieur civil du Génie Maritime.

Le jugement est la faculté de penser le particulier comme contenu dans le général.  
-± Emmanuel Kant -±

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 27, 2018, 7:35 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/8 "2018-12-27T19:35:13Z")

</div>

Bien vu, je n’y avais pas pensé. Si je ne m’abuse, ce n’est pas tant le système qui bloque l’application que l’application qui attend plus d’entropie que le système ne peut lui en fournir.  
Dans ce cas, l’installation du paquet haveged devrait fournir l’entropie manquante.

---

<div class="post-metadata">

**Author:** ![kro](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kro/32/7458_2.png) [@kro](https://www.debian-fr.org/u/kro)\
**Post date:** [Décembre 27, 2018, 8:13 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/9 "2018-12-27T20:13:37Z")

</div>

merci pour ces pistes. ça me semble quand même très théorique, d’autant qu’il ne me semble pas que sshd requiert un générateur aléatoire, ce serait plutôt ssh-keygen. dans mon cas la paire de clé est déjà générée, il me semble qu’il n’y a plus rien d’aléatoire. je me trompe peut-être.

j’installerai quand même haveged pour tester, je connais pas. je vous tiens au jus, dans l’immédiat je planche sur un autre problème plus urgent.

merci !

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 27, 2018, 8:39 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/10 "2018-12-27T20:39:03Z")

</div>

Tu te trompes : il faut encore générer les clés de session qui servent à chiffrer les communications.

---

<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:** [Décembre 27, 2018, 8:39 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/11 "2018-12-27T20:39:25Z")

</div>

> [@kro](#):
>
> ça me semble quand même très théorique,

Un système bloqué au démarrage avec un noyau `linux-image-4.16.0-1-amd64` cela arrive.  
[Un peu de lecture](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572) pour les longues soirées d’hiver 🙂  
Attention, c’est du lourd ! Parmi les intervenants on trouve un certain «&nbsp;Theodore Y. Ts’o&nbsp;» [tytso@mit.edu](mailto:tytso@mit.edu)

Cordialement,  
Regards,  
Mit freundlichen Grüßen,  
مع تحياتي الخالصة

* * *

F. Petitjean  
Ingénieur civil du Génie Maritime.

« Je préfère le vin d’ici à l’au-delà »  
Pierre Dac

---

<div class="post-metadata">

**Author:** ![kro](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kro/32/7458_2.png) [@kro](https://www.debian-fr.org/u/kro)\
**Post date:** [Janvier 13, 2019, 8:48 UTC](https://www.debian-fr.org/t/serveur-ssh-extremement-long-a-se-lancer-tant-quaucun-utilisateur-nest-connecte-localement/78270/12 "2019-01-13T20:48:43Z")

</div>

je mets un peu de temps à répondre parce que j’ai pas redémarré des masses ce serveur, mais là ça fait 3 fois que le serveur ssh se lance instantanément, donc force est de constater que l’installation du paquet haveged a résolu le problème ! merci à tous les 2 !