¿Se iniciará 1 desde una sesión ssh remota (a través de VPN) para eliminar mi conexión ssh?

Solución 1:

Sí, sí lo hará. La mayoría de los servicios no se ejecutan en el nivel de ejecución 1.

Solución 2:

Deberia estar bien. Si bien el demonio de escucha SSH se detiene en el nivel de ejecución 1 en la mayoría de las distribuciones, las conexiones existentes deberían permanecer activas y las redes no deberían verse afectadas. Sin embargo, no lo estaría haciendo sin tener algún tipo de consola remota conectada:nunca se sabe cuándo aparecerá una llamarada solar deshonesta y cortará sus conexiones de red durante el tiempo suficiente para interrumpir su sesión SSH.

EDITAR :Algunas pruebas indican que, al menos en los sistemas Debian, /etc/rc1.d/S30killprocs eliminará las conexiones SSH existentes (porque está acabando con todo). Me inclinaría a manipular ese script temporalmente y hacer su trabajo a mano (evitando las conexiones SSH) si tuviera que intentar hacer lo que quieres hacer. Sin embargo, aún prefiero usar una consola remota.

Solución 3:

Lamento mencionarlo después de tanto tiempo. Necesitaba una respuesta a esta misma pregunta. Las respuestas actuales son incorrectas para mi caja. Mis hallazgos son para la instalación basada en Centos 5.11.

1. La razón por la que el cliente ssh se desconecta es porque init 1 hace algo como service network stop .Lo que observo es que todas las interfaces de red se caen y se desconfiguran.ip a y ifconfig -a confirma esto.

2. init 1 detiene sshd proceso de escucha. No detiene sshd proceso secundario que mantiene la sesión para el cliente conectado. La sesión ssh finalmente se cancela debido al tiempo de espera de TCP porque la red se cae, la sesión ssh no se elimina. Si vuelvo a activar la red service network start en la consola lo suficientemente rápido, entonces mis clientes permanecen conectados aunque la caja esté en el nivel de ejecución 1.

3. La pregunta menciona VPN. Si el servidor VPN al que se dirige está en el cuadro donde está haciendo init 1 entonces sí, normalmente te desconectarás porque el servidor VPN por defecto NO se ejecutará en el nivel de ejecución 1.

Mi solución para llevar el sistema al nivel de ejecución 1 sin perder sesiones ssh es configurar temporalmente los servicios necesarios para continuar ejecutándose en el nivel de ejecución 1. Todo basado en Centos 5.11.YMMV.Descargo de responsabilidad: No me gustaría confiar en que esto funcione.

    # keep network interfaces up
    chkconfig --level 1 network on
    # if you are connecting though VPN e.g. OpenVPN running on same server
    chkconfig --level 1 openvpn on
    # While at it, might as well keep SSHD running, so you can reconnect
    chkconfig --level 1 sshd on

    init 1
    # look for messages that indicate that run level has been reached
    tail -F /var/log/messages
    # Aug 31 14:21:19 pabx-demo kernel: Kernel logging (proc) stopped.
    # Aug 31 14:21:19 pabx-demo kernel: Kernel log daemon terminating.
    # Aug 31 14:21:20 pabx-demo exiting on signal 15

Eso es todo. Esto me permite tomar el cuadro para iniciar 1 de forma remota mientras mantengo el control.

Una vez que haya terminado, no olvide deshacer los cambios:

chkconfig --level 1 network off
chkconfig --level 1 openvpn off
chkconfig --level 1 sshd off