Tecnología · GUÍA PRÁCTICA
¿ControlMaster de OpenSSH bloqueado? Prueba el socket antes de borrarlo
Resuelve el ControlPath efectivo, pregunta si el maestro sigue vivo, separa rutas obsoletas de transportes colgados y fallos de ruta, y repara solo el límite demostrado.
Un fallo de ControlMaster no es un solo problema. La ruta puede resolverse en otro lugar, superar el límite de un socket Unix, estar en un sistema de archivos inadecuado, señalar a un maestro terminado o llegar a un maestro local cuyo transporte remoto está colgado. Borrar primero la ruta destruye pruebas y puede competir con un proceso vivo.
Sigue las pruebas: fija la configuración efectiva con ssh -G, valida el ControlPath privado y su longitud, pregunta a ese socket con ssh -O check y elige exit, unlink, reubicación o keepalive según el límite observado. Termina demostrando que un segundo cliente reutiliza el nuevo maestro.
1. Fija el alias y la configuración efectiva
Usa el mismo alias y contexto que falló. Ejecuta ssh -G alias y registra hostname, user, port, proxyjump, controlmaster, controlpath y controlpersist. OpenSSH suele tomar primero la línea de comandos, luego el archivo del usuario y después el del sistema, y conserva el primer valor; mirar solo el último bloque coincidente puede identificar otro socket.
No expandas otro alias a mano. Los tokens %h, %p, %r y %C se resuelven desde la conexión efectiva, así que dos nombres aparentemente equivalentes pueden usar maestros distintos. Conserva toda la salida como prueba.
2. Valida la ruta antes de probar vida
Confirma que ControlPath está en un directorio del usuario SSH y no escribible por otros. Usa %h-%p-%r o, si falta longitud, %C. Comprueba permiso de búsqueda en cada padre y escritura en el directorio final; un padre ausente o no escribible es fallo de ruta, no socket obsoleto.
Mide la ruta codificada. Linux expone 108 bytes en sun_path para sockets con nombre, pero otras implementaciones pueden admitir menos; deja margen. Un directorio de ejecución corto y privado evita rutas profundas de home, contenedor o CI.
3. Pregunta al maestro exacto
Ejecuta ssh -O check alias con la configuración fijada. Para una ruta capturada usa ssh -S "$socket" -O check host con el mismo host, usuario y puerto efectivos. Una respuesta correcta identifica al maestro activo y normalmente su PID; guarda la salida antes de cambiar nada.
No dependas de un único texto de error en todas las versiones. Si no hay ruta vuelve a expansión o creación. Una conexión rechazada solo crea un candidato obsoleto: verifica dueño, tipo, alias y procesos que mantengan el socket abierto. Si responde, investiga el transporte, no lo borres.
4. Separa ruta obsoleta de transporte colgado
Si el maestro responde y quieres detenerlo, usa ssh -O exit alias y confirma que desaparecen proceso y ruta. No hagas unlink a un maestro que responde: los clientes existentes podrían seguir mientras los nuevos crean otro maestro. Solo tras no obtener respuesta, confirmar el dueño y no hallar proceso ni socket abierto, archiva la prueba y elimina esa ruta concreta.
La respuesta del socket solo prueba el canal local. Configura ServerAliveInterval junto con ServerAliveCountMax si necesitas un corte acotado; estos mensajes cifrados detectan que el servidor dejó de responder en un transporte establecido, un límite distinto de TCPKeepAlive.
5. Repara la ubicación de ruta y sistema de archivos
Si la creación falla en overlay o en un espacio de contenedor, reproduce una vez en un directorio privado y corto de un sistema local. Un caso de CI funcionó al sacar ControlPath de overlayfs, pero eso diagnostica esa ubicación y no todos los overlays. Mantén %C u otro token único por destino.
Prefiere un directorio 0700 del usuario, por ejemplo bajo un $XDG_RUNTIME_DIR apropiado. Si pruebas /dev/shm, crea un subdirectorio privado y verifica dueño y modo; nunca dejes sockets previsibles directamente en un directorio compartido escribible. Registra la limpieza de ControlPersist y de terminaciones abruptas.
6. Prueba la reparación y declara el límite
Inicia una conexión verbosa y guarda la línea de configuración de multiplexación. Conecta desde un segundo proceso con el mismo alias, verifica reutilización y repite ssh -O check. Compara ssh -G antes y después para demostrar la ruta y tupla previstas, no una caída accidental a una sesión sin multiplexación.
Acepta solo si la ruta privada se crea, el maestro exacto responde, el segundo cliente lo reutiliza, exit o persistencia actúan como se diseñó y el comando remoto funciona. El alcance son sockets ControlMaster con pathname y clientes muestreados; sockets abstractos, lanzadores, módulos de seguridad, proxies y parches de proveedor requieren más pruebas.
