Habilite SSH masivo concurrente en un solo servidor


9

Mi objetivo es permitir que 10000 ssh simultáneos se ejecuten en un solo servidor.

Por simplicidad, le estoy diciendo a localhost:

for i in `seq 1 10000`; do
    ssh localhost "echo ${i}; sleep 100"  >>./info 2>>./log &
done

sleep 100es asegurarse de que cuando se inicie el ssh número 10000, el primer ssh todavía esté conectado, de modo que haya 10000 ssh simultáneos .

Y aquí están los dos tipos de mensajes de error que recibí:

1. ssh_exchange_identification: Connection closed by remote host

2. ssh_exchange_identification: read: Connection reset by peer

He hecho las siguientes modificaciones:

  1. En /etc/security/limits.confy /etc/security/limits.d/90-nproc.conf, establezca soft & hard nofile& nprocen 65535 (este es el valor máximo posible, ¿verdad? - Actualización: no. El valor máximo es 1048576 )
  2. En /etc/sysctl.conf, establecerkernel.pty.max = 65535
  3. En /etc/ssh/sshd_config, conjunto MaxStartups 10000.

Estas modificaciones me permiten ejecutar con éxito 1000 ssh simultáneos en un solo servidor, pero no funcionan para 2000 y superiores ssh s.

Algunas personas han sugerido cambiar el valor de MaxSessions(en realidad no estoy claro acerca de su uso: ¿cómo afecta la multiplexación a mi caso?), /proc/sys/net/core/netdev_max_backlogY /proc/sys/net/core/somaxconn, pero parecen no hacer ninguna diferencia.

Además, no hay ningún error si son 10000 ssh simultáneos a diferentes servidores (los problemas ocurren solo cuando ssh a un solo servidor):

for i in `seq 1 10000`; do
    j=$(( 1 + $i % 8 ))
    ssh server-${j} "echo hi; sleep 100" >info-${j} 2>log-${j} &
done

He estado atrapado en esto por bastante tiempo.
¡Cualquier ayuda sería muy apreciada!


1
El registro del servidor sshd puede proporcionar más información sobre el motivo del rechazo de las conexiones. Básicamente, si desea solo 10000 sesiones, le recomendaría que use multiplexación usando ControlMaster (y luego, por supuesto, aumente MaxSessions).
Jakuje

1
No creo que sleep 100shaga lo que tú piensas. Se ejecuta no en la sesión ssh, sino en su propia máquina.
daniel kullmann

1
@Jakuje, gracias por recordarme que revise el registro del servidor. Encontré error: reexec socketpair: Too many open files, así que supongo que el valor anterior de nofile(es decir, 65535) estaba lejos de ser suficiente. No estoy familiarizado con ControlMaster pero lo intentaré, ¡gracias! :)
Clara

1
Interesante, cuando ejecuto una de las líneas, ps axu | egrep "ssh|sleep" | grep -v grepsolo enumera el sleep 100s, no el ssh. Creo que deberías cambiar el comando a ssh "echo hi; sleep 100s".
Daniel Kullmann

2
@danielkullmann Sí, tiene toda la razón: sleep 100debe estar en el comando enviado a través de ssh, que es el caso en mi script real, pero hice un error tipográfico aquí. He actualizado la publicación principal en consecuencia. ¡Muchas gracias por señalarlo!
Clara

Respuestas:


2

/ ojalá pudiera comentar

sshd necesita (normalmente, pero aunque no especificó los casos de uso exactos, etc.) asignar una pty por inicio de sesión, sin embargo, en su caso, ssh "echo hi; sleep 100s" NO asigna una pty, por lo que no necesita la configuración kernel.pty.max ... a menos que desee que miles de usuarios hayan iniciado sesión * ... para probar eso, deberá agregar la opción -t a sus pruebas, es decir. ssh -t "echo hola; duerme 100s"

Volviendo al tema en cuestión con las error: reexec socketpair: Too many open files Pruebas en un Wheezy dist-actualizado al sistema Jessie, descubrí que / etc / security / limit * no cambia los límites del sshd.

compruebe eso con lo cat /proc/<pid-of-sshd>/limits que en mi caso, después de configurar /etc/security/limits.conf: * nofile soft 65535 * nofile hard 65535 todavía informa solo 1024 (soft) y 4096 (hard) para los límites de sshd. La resolución parece ser forzar el ulimit -Hn 65535& ulimit -n 65535dentro del /etc/init.d/sshscript usando los comandos ulimit, he elevado los nofiles del sshd a 65535/65535 desde 1024/4096

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.