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

Support Debian
, ,
1

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 !

2

essaye ton serveur ssh depuis

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.

3

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.

4

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 ?

5

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.

6

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

À 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é.

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

8

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.

9

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 !

10

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

11

Un système bloqué au démarrage avec un noyau linux-image-4.16.0-1-amd64 cela arrive.
Un peu de lecture pour les longues soirées d’hiver :slight_smile:
Attention, c’est du lourd ! Parmi les intervenants on trouve un certain « Theodore Y. Ts’o » 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

12

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 !