¿Por qué mi inicio de sesión SSH es lento?

Estoy viendo retrasos en los inicios de sesión de SSH. Específicamente, hay 2 puntos donde veo un rango de retrasos instantáneos a varios segundos.

1. Entre emitir el comando ssh y obtener una solicitud de inicio de sesión y
2. entre ingresar la frase de contraseña y tener la carga de shell

Ahora, específicamente estoy viendo detalles ssh solo aquí. Obviamente, la latencia de la red, la velocidad del hardware y los sistemas operativos involucrados, los scripts de inicio de sesión complejos, etc. pueden causar demoras. Para el contexto, utilizo una gran cantidad de distribuciones de Linux y algunos hosts Solaris que utilizan principalmente Ubuntu, CentOS y MacOS X como mis sistemas cliente. Casi todo el tiempo, la configuración del servidor ssh no cambia desde la configuración predeterminada del sistema operativo.

¿En qué configuraciones de servidor ssh debería interesarme? ¿Hay parámetros del sistema operativo / kernel que se pueden ajustar? ¿Trucos de inicio de sesión? Etc?

Prueba a poner UseDNSa noen /etc/sshd_configo /etc/ssh/sshd_config.

Cuando ejecuté ssh -vvven un servidor con un rendimiento lento similar, vi un bloqueo aquí:

debug1: Next authentication method: gssapi-with-mic

Al editar /etc/ssh/ssh_configy comentar ese método de autenticación, el rendimiento de inicio de sesión volvió a la normalidad. Esto es lo que tengo en mi /etc/ssh/ssh_configen el servidor:

GSSAPIAuthentication no

Puede configurarlo globalmente en el servidor, por lo que no acepta GSSAPI para autenticar. Simplemente agregue GSSAPIAuthentication noal /etc/ssh/sshd_configservidor y reinicie el servicio.

Para mí, el culpable fue la resolución IPv6, estaba agotando el tiempo de espera. (Supongo que la configuración de DNS incorrecta en mi proveedor de host). Descubrí esto haciendo ssh -v, lo que mostró qué paso estaba colgando.

La solución es sshcon la -4opción:

ssh -4 [email protected]

Con systemd, el inicio de sesión puede bloquearse en la comunicación dbus con logind después de algunas actualizaciones, luego debe reiniciar logind

systemctl restart systemd-logind

Lo vi en Debian 8, Arch Linx y en una lista Suse

Siempre puede comenzar sshcon la -vopción que muestra lo que se está haciendo en este momento.

$ ssh -v you@host

Con la información que proporcionó, solo puedo sugerir algunas configuraciones del lado del cliente:

• Como escribe que está ingresando contraseñas manualmente, le sugiero que use la autenticación de clave pública si es posible. Esto lo elimina como un cuello de botella de velocidad.

• También puede deshabilitar el reenvío de X con -xy el reenvío de autenticación con -a(estos pueden estar deshabilitados de forma predeterminada). Deshabilitar especialmente el reenvío X puede proporcionarle una gran mejora de velocidad si su cliente necesita iniciar un servidor X para el sshcomando (por ejemplo, bajo OS X).

Todo lo demás realmente depende de qué tipo de retrasos experimente dónde y cuándo.

Con respecto al punto 2., aquí hay una respuesta que no requiere modificar el servidor ni tener privilegios administrativos / raíz.

Necesita editar su archivo "user ssh_config" que es:

vi $HOME/.ssh/config

(Nota: tendría que crear el directorio $ HOME / .ssh si no existe)

Y añadir:

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Puede hacerlo por host si es necesario :) ejemplo:

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Asegúrese de que la dirección IP coincida con la IP de su servidor. Una gran ventaja es que ahora ssh proporcionará autocompletado para este servidor. Por lo tanto, puede escribir ssh lin+ Taby se debe completar automáticamente ssh linux-srv.

Verifique /etc/resolv.confen el servidor para asegurarse de que el servidor DNS, que figura en este archivo, funcione correctamente y elimine cualquier DNS que no funcione.

A veces es muy útil.

Además de los problemas de DNS ya mencionados, si está ingresando a un servidor con muchos montajes NFS, entonces puede haber un retraso entre la contraseña y la solicitud a medida que el quotacomando verifica su uso / cuota en todos los sistemas de archivos que no están montados con el noquota. En los sistemas Solaris, puede ver esto por defecto /etc/profiley omitirlo ejecutando touch $HOME/.hushlogin .

Trabaja bien.

# uname -a
SunOS oi-san-01 5.11 oi_151a3 i86pc i386 i86pc Solaris
# ssh -V
Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080ff
# echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config
# echo "LookupClientHostnames no" >> /etc/ssh/sshd_config
# svcadm restart ssh

UseDNS no, no funciona con OpenIndiana !!!

Lea "man sshd_config" para todas las opciones

"LookupClientHostnames no" si su servidor no puede resolver

Si ninguna de las respuestas anteriores funciona y se enfrenta a problemas de búsqueda inversa de DNS, también puede verificar si nscd(servicio de nombres cache daemon) está instalado y ejecutándose.

Si este es el problema, es porque no tiene caché dns, y cada vez que solicita un nombre de host que no está en su archivo host, envía la pregunta a su servidor de nombres en lugar de buscar en su caché

Probé todas las opciones anteriores y el único cambio que funcionó fue comenzar nscd.

También debe verificar el orden para hacer una resolución de consulta dns /etc/nsswitch.confpara usar primero el archivo hosts.

Probablemente esto solo sea específico para Debian / Ubuntu OpenSSH, que incluye el user-group-modes.patch escrito por uno de los mantenedores de paquetes de Debian. Este parche permite que los archivos ~ / .ssh tengan configurado el bit de escritura del grupo (g + w) si solo hay un usuario con el mismo gid que el del archivo. La función secure_permissions () del parche hace esta comprobación. Una de las fases de la verificación es pasar por cada entrada passwd usando getpwent () y comparar el gid de la entrada con el gid del archivo.

En un sistema con muchas entradas y / o autenticación lenta NIS / LDAP, esta verificación será lenta. nscd no almacena en caché las llamadas getpwent (), por lo que cada entrada passwd se leerá en la red si el servidor no es local. En el sistema encontré esto, agregaba aproximadamente 4 segundos por cada invocación de ssh o inicio de sesión en el sistema.

La solución es eliminar el bit de escritura en todos los archivos en ~ / .ssh haciendo chmod g-w ~/.ssh/*.

Descubrí que reiniciar systemd-logind.service solo solucionó el problema durante unas horas. Cambiar UsePAM de yes a no en sshd_config ha resultado en inicios de sesión rápidos, aunque motd ya no se muestra. ¿Comentarios sobre problemas de seguridad?

Para completar todas las respuestas que muestran que las resoluciones DNS pueden ralentizar su inicio de sesión ssh, a veces, faltan reglas de firewall. Por ejemplo, si DEJAS todos los paquetes de ENTRADA por defecto

iptables -t filter -P INPUT DROP

entonces tendrá que aceptar INPUT para el puerto ssh y la solicitud DNS

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

ssh -vvv la conexión fue realmente buena hasta que se colgó en el sistema tratando de obtener el terminal durante al menos 20 segundos:

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
... waiting ... waiting ... waiting

¡Después de hacer un systemctl restart systemd-logind en el servidor tuve conexión instantánea otra vez!

Esto fue en debian8 ! ¡Así que systemd era el problema aquí!

Nota: Bastien Durel ya dio una respuesta para este problema, sin embargo, carece de la información de depuración. Espero que esto sea útil para alguien.

Recientemente he encontrado otra causa de inicios de sesión ssh lentos.

Incluso si usted tiene UseDNS noen /etc/sshd_config, sshd todavía puede realizar búsquedas DNS inversas si /etc/hosts.denytiene una entrada como:

nnn-nnn-nnn-nnn.rev.some.domain.com

Eso podría suceder si tiene DenyHosts instalado en su sistema.

Sería genial si alguien supiera cómo hacer que DenyHosts evite ingresar este tipo de entrada /etc/hosts.deny.

Aquí hay un enlace a las Preguntas frecuentes de DenyHosts sobre cómo eliminar entradas /etc/hosts.deny: consulte ¿Cómo puedo eliminar una dirección IP que DenyHosts bloqueó?

Podemos encontrar que el método de resolución de nombre preferido no es el archivo host y luego el DNS.

Por ejemplo, esta sería la configuración habitual:

[root@LINUX1 ~]# cat /etc/nsswitch.conf|grep hosts
#hosts:     db files nisplus nis dns
hosts:      files dns myhostname

Primero, se alcanza el archivo de hosts (opción: archivos) y luego DNS (opción: dns), sin embargo, podemos encontrar que se ha agregado otro sistema de resolución de nombres que no está operativo y nos está causando la lentitud al tratar de hacer la resolución inversa.

Si el orden de resolución de nombre no es correcto, puede cambiarlo en: /etc/nsswitch.conf

Extraído de: http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html

Intenté todas las respuestas pero ninguna funcionó. finalmente descubro mi problema:

primero ejecuto sudo tail -f /var/log/auth.log para poder ver el registro de ssh y luego en otra sesión ejecuté ssh 172.16.111.166y noté que esperaba

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

después de buscar, ubiqué esta línea en / etc / ssd / ssh_config

ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Lo comenté y la demora se fue

Nota: Esto comenzó como un tutorial de "Cómo depurar", pero terminó siendo la solución que me ayudó en un servidor Ubuntu 16.04 LTS.

TLDR : Ejecute landscape-sysinfoy compruebe si ese comando tarda mucho en finalizar; es la impresión de información del sistema en un nuevo inicio de sesión SSH. Tenga en cuenta que este comando no está disponible en todos los sistemas, el landscape-commonpaquete lo instala. ("Pero espera hay mas...")

Inicie un segundo servidor ssh en otro puerto de la máquina que tenga el problema, hágalo en modo de depuración, lo que no hará que se bifurque e imprima mensajes de depuración:

sudo /usr/sbin/sshd -ddd -p 44321

conectarse a ese servidor desde otra máquina en modo detallado:

ssh -vvv -p 44321 username@server

Mi cliente muestra las siguientes líneas justo antes de comenzar a dormir:

debug1: Entering interactive session.
debug1: pledge: network

Buscar en Google eso no es realmente útil, pero los registros del servidor son mejores:

debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051

Noté que cuando cambio UsePAM yesa UsePAM noeste problema se resuelve.

No relacionado con UseDNSninguna otra configuración, solo UsePAMafecta este problema en mi sistema.

No tengo idea de por qué, y tampoco me voy UsePAMa noir porque no sé cuáles son los efectos secundarios, pero esto me permite seguir investigando.

Por lo tanto, no considere que esto sea una respuesta, sino un primer paso para comenzar a descubrir qué está mal.

Entonces continué investigando y corrí sshdcon strace( sudo strace /usr/sbin/sshd -ddd -p 44321). Esto produjo lo siguiente:

sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5)                                = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022)                              = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385

La línea /etc/update-motd.dme hizo sospechar, aparentemente el proceso espera el resultado de las cosas que están en/etc/update-motd.d

Así que cd'd en /etc/update-motd.dy pasó un sudo chmod -x *fin de inhibir PAM para ejecutar todos los archivos que generan esta dinámica Message Of The Day, que incluye la carga del sistema y si los paquetes deben ser actualizados, y esto resuelve el problema.

Este es un servidor basado en una CPU N3150 "energéticamente eficiente" que tiene mucho trabajo que hacer las 24 horas del día, los 7 días de la semana, por lo que creo que recopilar todos estos datos motd fue demasiado.

Puedo comenzar a habilitar scripts en esa carpeta de forma selectiva, para ver cuáles son menos dañinos, pero especialmente las llamadas landscape-sysinfoson muy lentas y 50-landscape-sysinfollaman a ese comando. Creo que es el que causa el mayor retraso.

Después de volver a habilitar la mayor parte de los archivos que llegué a la conclusión de que 50-landscape-sysinfoy 99-esmfueron la causa de mis problemas. 50-landscape-sysinfotardó unos 5 segundos en ejecutarse y 99-esmunos 3 segundos. Todos los archivos restantes alrededor de 2 segundos en total.

Ninguno de los dos 50-landscape-sysinfoy 99-esmson cruciales. 50-landscape-sysinfoimprime estadísticas interesantes del sistema (¡y también si tiene poco espacio!) e 99-esmimprime mensajes relacionados conUbuntu Extended Security Maintenance

Finalmente, puede crear un script echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.shy obtener esa impresión a pedido.

Este hilo ya está proporcionando un montón de soluciones, pero el mío no se da aquí =). Asi que aqui esta. Mi problema (tardó aproximadamente 1 minuto en iniciar sesión en ssh en mi Raspberry Pi) se debió a un archivo .bash_history dañado. Dado que el archivo se lee al iniciar sesión, esto estaba causando el retraso de inicio de sesión. Una vez que eliminé el archivo, el tiempo de inicio de sesión volvió a la normalidad, como instantáneo.

Espero que esto ayude a otras personas.

Para mí necesitaba GSSAPI, y no quería desactivar las búsquedas inversas de DNS. Eso no parecía una buena idea, así que revisé la página principal para resolv.conf. Resulta que un firewall entre mí y los servidores a los que estaba enviando SSH estaba interfiriendo con las solicitudes de DNS, porque no estaban en una forma que el firewall esperaba. Al final, todo lo que tenía que hacer era agregar esta línea a resolv.conf en los servidores en los que estaba SSHing:

options single-request-reopen​

Sorprendentemente, una actualización de paquete de enlace en CentOS 7 se rompió con el nombre, ahora indicando en el registro que /etc/named.conf tenía un problema de permisos. Había funcionado bien durante meses con 0640. Ahora quiere 0644. Esto tiene sentido ya que el demonio nombrado pertenece al usuario 'nombrado'.

Con el nombre anulado, todo fue lento, desde los inicios de sesión ssh hasta el servicio de la página desde el servidor web local, las aplicaciones LAMP lentas, etc.

Para mí hubo un problema en mi /etc/hostsarchivo local . Así que sshestaba probando dos IP diferentes (una incorrecta) que tardó una eternidad en expirar.

Usando ssh -vhizo el truco aquí:

$ ssh -vvv remotesrv
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/mathieu/.ssh/config
debug1: /home/mathieu/.ssh/config line 60: Applying options for remotesrv
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotesrv [192.168.0.10] port 22.
debug1: connect to address 192.168.0.10 port 22: Connection timed out
debug1: Connecting to remotesrv [192.168.0.26] port 22.
debug1: Connection established.