J'ai une machine récemment mise à jour vers Fedora 25, exécutant openSSH 7.4. Depuis lors, la connexion via ssh prend 25 à 30 secondes sur un LAN où cela ne prend normalement pas plus d'une seconde.
Exécuter le client avec -vvv , en utilisant l'authentification par clé publique, la pause se produit ici.
debug1: Authentication succeeded (publickey).
Authenticated to crystalline.kodiak ([192.168.0.22]:127).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
Cela semble identique à la sortie vers d'autres machines (Fedora 23, openSSH 7.2) sur le même réseau qui n'ont aucun problème.
Surveillance top côté serveur lors de la connexion, systemd s'allume brièvement - quelques secondes - au début de la pause, ce qui n'est pas perceptible sur les autres machines. Après cela, le système est complètement inactif. De même, il n'y a pas d'activité inhabituelle côté client.
Une fois connecté, tout va bien.
J'ai regardé l'échange du client avec Wireshark et pendant la pause, aucun paquet n'est échangé. Le client et le serveur sont sur Ethernet via un routeur, je peux donc également surveiller l'adresse du serveur pour tout trafic. Il ne se passe rien.
Voici le sshd_config :
Port 127
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
IgnoreRhosts yes
SyslogFacility AUTHPRIV
LogLevel INFO
TCPKeepAlive yes
ClientAliveInterval 120
ClientAliveCountMax 15
PermitRootLogin yes
StrictModes yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM yes
X11Forwarding no
UsePrivilegeSeparation sandbox
AcceptEnv LANG LC_*
Subsystem sftp /usr/libexec/openssh/sftp-server
Selon la suggestion de Sato Katsura dans les commentaires, j'ai essayé avec UseDNS no; cela n'a fait aucune différence.
Réponse acceptée :
Il s'avère que c'est tout à fait le cas du coin.
La machine est un Raspberry Pi, exécutant le noyau stock Pi, mais avec un userland armhf Fedora 25 générique. Il a également été configuré sans tête et n'a jamais été utilisé autrement, mais lorsqu'il est branché sur un moniteur et un clavier, il y avait un problème évident avec systemd-logind.service . Je l'ai retracé jusqu'à ce problème, qui a été introduit l'année dernière lorsque des parties centrales de systemd sont devenues dépendantes de seccomp, qui pour une raison quelconque n'est pas inclus dans le noyau Pi d'origine, mais peut-être via une mauvaise configuration qui donne l'impression que c'est le cas. /P>
La solution était assez simple; les options de fichier de service qui nécessitent seccomp doivent être supprimées. Il y en a une poignée dans /usr/lib/systemd/system , y compris systemd-logind.service .
Cela laisserait également probablement la mise en réseau désactivée sur un système de stock, mais j'utilise mon propre service pour cela et cela n'a pas été affecté (c'est-à-dire que les chances que quelqu'un d'autre rencontre ce problème de cette façon sont minces).
Connexe :Besoin d'échapper aux caractères regex dans sed pour qu'ils soient interprétés comme des caractères regex ?Quoi qu'il en soit, j'ai commenté les lignes suivantes dans chacun d'eux :
MemoryDenyWriteExecute=yes
SystemCallFilter=...
Redémarré, plus de problèmes.