LinuxParty
Nombre
autossh : monitorea y reinicia sesiones ssh
Sinopsis
autossh [ -V ] [ -M puerto [: echo_port] ] [ -f ] [SSH_OPTIONS]
Descripción
autossh es un programa para iniciar una copia de ssh y monitorearlo, reiniciándolo según sea necesario si muere o deja de pasar tráfico.
La idea original y el mecanismo fueron de rstunnel (Reliable SSH Tunnel). Con la versión 1.2 de autossh, el método cambió: autossh usa ssh para construir un bucle de reenvíos ssh (uno de local a remoto, uno de remoto a local) y luego envía datos de prueba que espera recuperar. (La idea es gracias a Terrence Martin).
Con la versión 1.3, se agrega un nuevo método (gracias a Ron Yorston): se puede especificar un puerto para un servicio de eco remoto que hará eco de los datos de prueba. Esto evita la congestión y el agravamiento de asegurarse de que todos los números de puerto en la máquina remota no colisionen. El método de bucle de reenvío sigue estando disponible para situaciones en las que puede no ser posible utilizar un servicio de eco.
Controlando ssh
Salidas SSH
autossh intenta distinguir la forma de muerte del proceso ssh que está monitoreando y actúa de manera apropiada. Las reglas son:
1. ' Si el proceso ssh salió normalmente
(por ejemplo, alguien escribió "exit" en una sesión interactiva),
autossh sale en lugar de reiniciar;
2. ' Si el propio autossh recibe una señal SIGTERM, SIGINT o SIGKILL, asume que fue señalado deliberadamente y sale después de matar el proceso ssh hijo;
3. ' Si autossh mismo recibe una señal SIGUSR1, mata el proceso ssh hijo e inicia uno nuevo;
4. ' Periódicamente (de forma predeterminada cada 10 minutos), autossh intenta pasar el tráfico en el puerto reenviado del monitor. Si esto falla, autossh matará el proceso ssh hijo (si todavía está en ejecución) y comenzará uno nuevo;
5. ' Si el proceso ssh secundario muere por cualquier otro motivo, autossh intentará iniciar uno nuevo.
Comportamiento de inicio
Si la sesión ssh falla con un estado de salida de 1 en el primer intento, autossh
1. ' asumirá que hay algún problema con la sintaxis o la configuración de la conexión, y saldrá en lugar de volver a intentarlo;
2. ' Hay un tiempo de "puerta de salida". Si el primer proceso ssh falla dentro de los primeros segundos de iniciarse, autossh asume que nunca "salió de la puerta de inicio" y sale. Esto es para manejar la autenticación inicial fallida, la conexión, etc. Este tiempo es de 30 segundos por defecto y se puede ajustar (consulte la variable de entorno AUTOSSH_GATETIME a continuación). Si AUTOSSH_GATETIME se establece en 0, entonces ambos comportamientos están deshabilitados: no hay "puerta de inicio", y autossh se reiniciará incluso si ssh falla en la primera ejecución con un estado de salida de 1. El tiempo de "puerta de inicio" también se establece en 0 cuando se usa la bandera -f para autossh.
Fallos continuos
Si la conexión ssh falla e intenta reiniciarla en una sucesión rápida, autossh comenzará a retrasar sus intentos de reiniciarse, retrocediendo gradualmente más y más hasta un intervalo máximo del tiempo de encuesta autossh (generalmente 10 minutos). Se puede "presionar" a autossh para que vuelva a intentarlo señalándolo, tal vez con SIGHUP ("kill -HUP").
Configuración de la conexión
Como las conexiones deben establecerse sin supervisión , el uso de autossh requiere que se configure algún tipo de autenticación automática. El uso de RSAAuthentication con ssh-agent es el método recomendado. El script de contenedor de ejemplo intenta comprobar si hay un agente ejecutándose para el entorno actual e iniciar uno si no lo hay.
No se puede enfatizar lo suficiente que debe asegurarse de que ssh funcione por sí solo, que pueda configurar la sesión que desee antes de intentar ejecutarla en autossh
Si está haciendo un túnel y está usando una versión anterior de ssh que no es compatible con el indicador -N , debe actualizar (su versión tiene fallas de seguridad). Si no puede actualizar, es posible que desee hacer lo que hace rstunnel y darle un comando a ssh para que se ejecute, como "sleep 99999999999".
Opciones
-M puerto [: echo_port]
especifica el puerto de monitorización base que se utilizará. Sin el puerto de eco, este puerto y el puerto inmediatamente superior ( puerto + 1) deberían ser algo que nada más esté usando. autossh enviará datos de prueba en el puerto de monitoreo base y los recibirá nuevamente en el puerto de arriba. Por ejemplo, si especifica "-M 20000", autossh configurará los reenvíos para que pueda enviar datos en el puerto 20000 y recibirlos en 20001.
Alternativamente, se puede especificar un puerto para un servicio de eco remoto. Este debería ser el puerto 7 si desea utilizar el servicio estándar de eco inetd. Cuando se especifica un puerto de eco, solo se utiliza el puerto de monitor especificado y lleva el mensaje de monitor en ambas direcciones.
Muchas personas deshabilitan el servicio de eco, o incluso deshabilitan inetd, así que verifique que este servicio esté disponible en la máquina remota. Algunos sistemas operativos permiten especificar que el servicio solo escucha en el host local (interfaz de bucle invertido), lo que sería suficiente para este uso.
El servicio de eco también puede ser algo más complicado: quizás un demonio que monitorea un grupo de túneles ssh.
Establecer el puerto del monitor en 0 desactiva la función de monitorización, y autossh solo reiniciará ssh al salir de ssh. Por ejemplo, si está utilizando una versión reciente de OpenSSH, es posible que desee explorar el uso de las opciones ServerAliveInterval y ServerAliveCountMax para que el cliente SSH salga si ya no está conectado al servidor. En muchos sentidos, esta puede ser una mejor solución que el puerto de monitoreo.
-f 'hace que autossh caiga en segundo plano antes de ejecutar ssh. La bandera -f se quita de los argumentos pasados a ssh. Tenga en cuenta que hay una diferencia crucial entre -f con autossh y -f con ssh: cuando se usa con autossh, ssh no podrá solicitar contraseñas o frases de contraseña. Cuando se usa -f , el tiempo de la "puerta de inicio" (ver AUTOSSH_GATETIME) se establece en 0.
-V 'hace que autossh muestre su número de versión y salga.
Ambiente
Aparte de la bandera para configurar el puerto de monitoreo de conexión, autossh usa variables de entorno para controlar las funciones. ssh parece seguir recopilando letras para las opciones, y esta parece la forma más fácil de evitar colisiones.
AUTOSSH_DEBUG
Si se establece esta variable, el nivel de registro se establece en LOG_DEBUG, y si el sistema operativo lo admite, syslog se establece para duplicar las entradas de registro en stderr.
AUTOSSH_FIRST_POLL
Especifica el tiempo de espera antes de la primera prueba de conexión. A partir de entonces, se utiliza el tiempo de encuesta general (consulte AUTOSSH_POLL a continuación).
AUTOSSH_GATETIME
Especifica cuánto tiempo debe estar activo ssh antes de considerarlo una conexión exitosa. El valor predeterminado es 30 segundos. Tenga en cuenta que si AUTOSSH_GATETIME se establece en 0, entonces no solo se desactiva el comportamiento del tiempo de puerta, sino que autossh también ignora la falla de la primera ejecución de ssh. Esto puede resultar útil cuando se ejecuta autossh en el arranque.
AUTOSSH_LOGLEVEL
Especifica el nivel de registro, correspondiente a los niveles utilizados por syslog; así que 0-7 siendo 7 el más hablador.
AUTOSSH_LOGFILE
Especifica que autossh debe usar el archivo de registro con nombre, en lugar de syslog.
AUTOSSH_MAXLIFETIME
Establece el número máximo de segundos que debe ejecutarse el programa. Una vez que se haya pasado el número de segundos, el hijo ssh será eliminado y el programa se cerrará.
AUTOSSH_MAXSTART
Especifica cuántas veces se debe iniciar ssh. Un número negativo significa que no hay límite en el número de veces que se inicia ssh. El valor predeterminado es -1.
AUTOSSH_MESSAGE Agregar
mensaje al mensaje de eco enviado al probar conexiones.
AUTOSSH_NTSERVICE
(sólo Cygwin). Cuando se establece en "sí", autossh se configura para ejecutarse como un servicio NT bajo cygrunsrv. Esto agrega el indicador -N para ssh si aún no está configurado, establece la salida del registro en stdout y cambia el comportamiento en la salida de ssh para que se reinicie incluso en una salida normal.
AUTOSSH_PATH
Especifica la ruta al ejecutable ssh, en caso de que sea diferente a la ruta compilada.
AUTOSSH_PIDFILE
Escribe autossh pid en el archivo especificado.
AUTOSSH_POLL
Especifica el tiempo de sondeo de la conexión en segundos; el valor predeterminado es 600 segundos. Si el tiempo de sondeo es menos del doble de los tiempos de espera de la red (por defecto 15 segundos), los tiempos de espera de la red se ajustarán a la mitad del tiempo de sondeo.
AUTOSSH_PORT
Establece el puerto de supervisión de la conexión. Sobre todo en caso de que ssh se apropie de -M en algún momento. Pero debido a este posible uso, AUTOSSH_PORT anula el indicador -M. Un valor de 0 desactiva la función de monitorización.
Autor
autossh fue escrito por Carson Harding.
Ver también
ssh (1), ssh-add (1), ssh-agent (1), ssh-keygen (1), cygrunsrv (1).
-
Linux
- Cambiar la Hora y la Fecha al sistema Linux
- Montar un directorio remoto, vía NFS, en Linux
- Predicciones de Linux para 2025
- Elementary OS 8: una distribución de Linux para usuarios de Windows y macOS
- Renombrar multiples archivos masivamente en Linux (quitar espacios, cambiar mayúsculas) a la vez en Linux
- He utilizado Linux durante 30 años. Aquí hay 5 razones por las que nunca cambiaré a Windows o MacOS
- Mis predicciones sobre Linux para 2025: será un buen año
- ¿Por qué Torvalds eliminó a los encargados rusos del mantenimiento del núcleo de Linux?
- 10 cosas que siempre hago después de instalar Linux (y por qué tú también deberías hacerlo)
- 7 cosas que nunca hago después de instalar Linux (y por qué tú tampoco deberías)
- Detección de Intrusos: Snort, Base, MySQL, y Apache2 en Ubuntu Linux 7.10
- ¿Por qué no más personas usan Linux en el escritorio? Tengo una teoría que quizás no te guste.
- Los países occidentales ricos lideran la expansión mundial del petróleo y el gas
- Systemd 256.1 aborda la queja de que 'systemd-tmpfiles' podría eliminar inesperadamente su directorio /home
- Por qué un kernel Linux de distribución 'congelada' no es la mejor opción para la seguridad