Las sesiones SSH se cuelgan al apagar / reiniciar

13

Tengo un servidor que ejecuta Debian y sshd en él, y en caso de que necesite reiniciar el servidor, mi sesión SSH se bloquea en el lado del cliente hasta que se agote el tiempo de espera de TCP. Supongo que esto se debe a que cuando sshdse termina, no cierra explícitamente las sesiones SSH abiertas al host. ¿Qué debo hacer para sshddesconectar primero a todos y luego terminar de forma normal? Hasta ahora no veo un parámetro man sshd_configque esté relacionado con el comportamiento cerrado.

ssh debian systemd

— Vesper
fuente

Cuando todo lo demás falla, puede matar a un cliente SSH en cualquier momento presionando [Enter] [~] [.]. Explicación sobre cómo resolver realmente su problema también.

— n.st

32

Cuando apaga o reinicia su sistema, systemdintenta detener todos los servicios lo más rápido posible. Eso implica derribar la red y terminar todos los procesos que aún están vivos, generalmente en ese orden. Entonces, cuando systemd mata los procesos SSH bifurcados que manejan sus sesiones SSH, la conexión de red ya está deshabilitada y no tienen forma de cerrar la conexión del cliente con gracia.

Su primer pensamiento podría ser simplemente matar todos los procesos SSH como el primer paso durante el apagado, y hay bastantes archivos de servicio systemd que hacen exactamente eso.

Pero hay, por supuesto, una solución más limpia (cómo se "supone" que hacer): systemd-logind.
systemd-logindrealiza un seguimiento de las sesiones de usuario activas (locales y SSH) y asigna todos los procesos generados dentro de ellos a los llamados "sectores". De esa manera, cuando el sistema se apaga, systemd puede SIGTERMAR todo lo que se encuentra dentro de los segmentos del usuario (que incluye el proceso SSH bifurcado que está administrando una sesión en particular) y luego continuar apagando los servicios y la red.

systemd-logindrequiere un módulo PAM para recibir notificaciones de nuevas sesiones de usuario y dbusdeberá usarlo loginctlpara verificar su estado, así que instale ambos:

apt-get install libpam-systemd dbus

Asegúrese de que /etc/ssh/sshd_configrealmente va a utilizar el módulo con UsePAM yes.

— n.st
fuente

Bien, objetivo logrado, y gracias por la explicación. (Aunque me gustaría alguna forma de control de la dependencia para el apagado, por lo que todo es de primera SIGTERM'd mientras que ser capaz de terminar su trabajo, esto se puede hacer como una solución en capas.)

— Vesper

Por alguna razón, no me notificaron la respuesta mientras visitaba solo StackOverflow. Extraño.

— Vesper el

1

Entonces, para abreviar, solo para ahorrar unos segundos en el apagado, ¿tenemos que instalar una carga completa de basura solo para que nuestras conexiones se terminen correctamente? Seriamente ? Esto se está poniendo mal. Estamos condenados.

— leucos

3

Tenga en cuenta que el primer reinicio después de instalar libpam-systemd y dbus aún dejaría su sesión SSH suspendida. Para evitar eso, en lugar de reboothacerlo, realice un shutdown -rretraso predeterminado de 1 minuto, dejándole tiempo para cerrar la sesión SSH.

— mivk

9

Esto es algo que debe configurar en el lado del cliente, no en el lado del servidor. Edite su ~/.ssh/configpara contener

ServerAliveInterval 15
ServerAliveCountMax 5

Esto significa que después de 15 segundos de inactividad, su cliente enviará un mensaje al servidor. Si no obtiene ninguna respuesta, lo intentará nuevamente hasta 5 veces, y cuando todavía no obtenga una respuesta, cerrará la sesión.

— Jenny D
fuente

2

Esto dará como resultado un retraso de 75 segundos antes de que el cliente ssh informe que el servidor está inactivo. ¿Derecho?

— Vesper

1

Sí, y puede ajustar los parámetros para reducir el tiempo de espera.

— Tero Kilkanen

Esto resolvió mi problema. Un problema tan irritante.

— Justin Andrusk

5

Este comportamiento se informa en este error de Debian , solo necesita configurar correctamente los scripts de apagado enviados con el paquete porque, automáticamente, no se copian de manera predeterminada:

cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl  enable ssh-session-cleanup.service

— Rfraile
fuente

1

Puede especificar las opciones de las que habló Jenny D en su respuesta solo para un comando ssh, como

ssh -t -o ServerAliveInterval=1 -o ServerAliveCountMax=1 user@host sudo poweroff

si haces eso a menudo, puedes escribirlo.

— Diego Medaglia
fuente

0

Funciona para mí con lshd. Entonces la solución sería

apt install lsh-server
apt remove openssh-server

— Dios
fuente

0

Lamentablemente, serverfault no me dejó responder en hilo por muy pocos puntos desde hace años. Pero no necesito enviar spam en otros blogs para desbloquear ^^ ... así que como respuesta dedicada:

Como mencionó Rfraile

cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl  enable ssh-session-cleanup.service

trabajos. Para usarlo sin reiniciar la instancia / servidor, debe realizar tareas adicionales:

systemctl daemon-reload
systemctl start ssh-session-cleanup.service

Por lo tanto, el servicio se registra e inicia y systemd necesita detenerlo para reiniciar / apagar.

— Reiner030
fuente

Entonces, ¿estás repitiendo otra respuesta?

— RalfFriedl

¿No? Utilicé las 2 líneas solo como referencia para la respuesta superior porque todavía no puedo responder como está escrito. Agregué los pasos necesarios para usarlo sin reiniciar. Esto también se puede dar en otro hilo de preguntas pero que no he revisado.

— Reiner030