Вопросы Теги

SSH зависает перед запросом входа в систему

For Images:

You can watch images with fbi:

NAME
       fbi - linux framebuffer imageviewer

SYNOPSIS
       fbi [ options ] file ...

DESCRIPTION
       fbi  displays  the  specified  file(s) on the linux console using the framebuffer device.  PhotoCD, jpeg, ppm,
       gif, tiff, xwd, bmp and png are supported directly.  For other formats fbi tries to use ImageMagick's convert.

Example command:

$ fbi path/to/file.jpg

For videos:

  • You can use vlc from tty/console:

    Example command:

    $ vlc /path/to/file.mp4

  • You can also use mplayer:

    $ mplayer /path/to/file.mp4

    Note: Video output drivers can be set by -vo option e.g caca, fbdev. (This external article may help)

1
05.03.2018, 13:43
2 ответа

Esto es solo una teoría, pero lo que sospecho que está sucediendo es que las conexiones TCP para sus sesiones ssh están muriendo, pero el "servidor en la nube" no lo está detectando. Entonces, cuando va a hacer una conexión a localhost -p 23xx, el proceso ssh todavía está allí y escuchando, pero cuando intenta enviar datos de regreso al Pi, se cuelga hasta que se encuentra el número máximo de retransmisiones de TCP y finalmente decide que la conexión es muerto y sale (dices que se cuelga para siempre, pero apuesto a que si esperas lo suficiente obtendrás un restablecimiento de la conexión ).
Ahora, suponiendo que tiene el Pi configurado para volver a conectarse si el túnel ssh muere, podría pensar que esto debería solucionar el problema. Hay un par de problemas potenciales con esta idea. Primero, es posible que Pi tampoco esté detectando la conexión muerta. Entonces, hasta que intente enviar datos y alcance el límite de retransmisiones de TCP, no verá la conexión inactiva y se reconectará. El segundo problema potencial es que incluso si detecta la conexión inactiva e intenta volver a conectarse, no podrá establecer el oyente en el servidor de la nube porque el ssh anterior todavía está allí y se aferra al puerto.

La solución aquí es configurar ssh para que pueda detectar las conexiones inactivas.Hay algunas formas de hacerlo, TCP KeepAlive y SSH KeepAlive. (referencia:https://unix.stackexchange.com/a/34201/4358)

La configuración de TCP KeepAlive(TCPKeepAliveen ssh config )utiliza la funcionalidad de mantenimiento nativo -de TCP. Básicamente, el kernel envía un ACK de TCP vacío cada X segundos, y cuando no recibe un ACK del otro extremo (o se restablece ), cierra la conexión que notifica a la aplicación (SSH ).

SSH KeepAlive (la configuración ServerAlive*y ClientAlive*)es similar pero opera en una capa más alta. Aquí, el proceso SSH envía datos reales a través de la conexión y busca una respuesta. Esto debería detectar una conexión inactiva tan bien como un TCP KeepAlive normal, sin embargo, es más probable que mantenga la conexión viva, ya que los saltos en el medio pueden reconocer los paquetes TCP KeepAlive e ignorarlos, y agotar el tiempo de espera de la conexión inactiva. Pero un SSH KeepAlive no se puede reconocer porque parece tráfico real en cualquier salto en el medio.

TL; DR:

En el raspberry Pis, agregue la siguiente configuración a la configuración de su cliente ssh(~/.ssh/configo/etc/ssh/ssh_config):

ServerAliveInterval 15
ServerAliveCountMax 1

(documentación)

En el servidor, agregue la siguiente configuración a su configuración del demonio ssh(/etc/ssh/sshd_config):

ClientAliveInterval 20
ClientAliveCountMax 1

(documentación)

Tenga en cuenta que hice el valor del Intervalo ligeramente más alto. La razón de esto es solo para que ambos lados no envíen sus mensajes KeepAlive exactamente al mismo tiempo y se crucen en el cable. No hay daño real en esto, solo una pequeña ineficiencia. Tampoco importa qué lado esté más alto, siempre que sean diferentes.

3
27.01.2020, 23:44

У меня такая же проблема. 

$ ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.9  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::d949:d257:c622:3388  prefixlen 64  scopeid 0x20<link>
        ether 18:1d:ea:00:4e:cf  txqueuelen 1000  (Ethernet)
        RX packets 333970  bytes 471184965 (449.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 76462  bytes 9787485 (9.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Измените значение mtu на 1200.(MTU)

$ ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1200
        inet 192.168.1.9  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 18:1d:ea:00:4e:cf  txqueuelen 1000  (Ethernet)
        RX packets 334117  bytes 471271158 (449.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 76604  bytes 9808842 (9.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

После этого SSH подключился, как и ожидалось. Надеюсь, этот ответ сократит ваш поиск обходных путей.:)

0
12.09.2020, 14:20

Теги

Похожие вопросы