Tengo una máquina recientemente actualizada a Fedora 25, ejecutando openSSH 7.4. Desde entonces, iniciar sesión a través de ssh toma entre 25 y 30 segundos en una LAN donde normalmente no toma más de 1 segundo.
Ejecutando el cliente con -vvv , utilizando la autenticación de clave pública, la pausa se produce aquí.
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
Esto parece idéntico a la salida a otras máquinas (Fedora 23, openSSH 7.2) en la misma red que no tienen ningún problema.
Observando la parte superior del lado del servidor durante el inicio de sesión, systemd se enciende brevemente, unos segundos, al comienzo de la pausa, algo que no se nota en las otras máquinas. Después de eso, el sistema está completamente inactivo. Asimismo, no hay actividad inusual en el lado del cliente.
Una vez que haya iniciado sesión, todo estará bien.
He visto el intercambio del cliente con Wireshark y durante la pausa no hay intercambio de paquetes. El cliente y el servidor están en Ethernet a través de un enrutador, por lo que también puedo ver la dirección del servidor en busca de tráfico. No pasa nada.
Aquí está el 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
Según la sugerencia de Sato Katsura en los comentarios, he probado con UseDNS no; esto no hizo ninguna diferencia.
Respuesta aceptada:
Resulta que este es el caso de la esquina.
La máquina es una Raspberry Pi, que ejecuta el kernel Pi estándar, pero con un usuario genérico armhf Fedora 25. También se configuró sin periféricos y nunca se usó de otra manera, pero cuando se conectó a un monitor y teclado hubo un problema obvio con systemd-logind.service . Lo rastreé hasta este problema, que se presentó el año pasado cuando las partes centrales de systemd se volvieron dependientes de seccomp, que por alguna razón no está incluido en el kernel de Pi, pero posiblemente a través de una mala configuración que hace que parezca que lo está.
La solución fue bastante simple; Las opciones del archivo de servicio que requieren seccomp deben eliminarse. Hay un puñado de estos en /usr/lib/systemd/system , incluido systemd-logind.service .
También es probable que deje la red deshabilitada en un sistema estándar, pero uso mi propio servicio para esto y eso no se vio afectado (es decir, la posibilidad de que alguien más se encuentre con este problema de esta manera es escasa).
Relacionado:¿Necesita escapar de los caracteres de expresión regular en sed para que se interpreten como caracteres de expresión regular?De todos modos, comento las siguientes líneas en todos ellos:
MemoryDenyWriteExecute=yes
SystemCallFilter=...
Reiniciado, no más problemas.