Guías de seguridad
No des claves de root a entornos que pueden ser comprometidos: privilegio mínimo en claves SSH
¿Registras una clave SSH en producción desde un entorno efímero y comprometible (un pod de GPU-cloud, un runner de CI)? Si se filtra, alguien obtiene root en producción. Cómo hacer las claves de privilegio mínimo con un usuario no-root y una clave restringida a un solo comando.
Para: cualquiera que llegue a producción por SSH desde un entorno efímero — un pod de GPU-cloud, un runner de CI, una VM desechable. Sin pasos de ataque — solo hacer las claves de privilegio mínimo para reducir el radio de la explosión. Para la base de separar claves, ver la lista de comprobación de la base.
La visión de este sitio: trata los entornos efímeros como no confiables
El cómputo desechable a menudo omite el endurecimiento — es un sitio que puede comprometerse. Poner ahí una clave de root de producción es como dejar la copia de la llave de tu puerta de entrada en la calle. Este sitio usa una clave distinta por servidor, acota cada una a un propósito, y retira las claves en el momento en que dejan de usarse (→ separa las claves para minimizar el radio de la explosión). Tratar una clave no como "un pase práctico" sino como "el activo más crítico que abre todo si se filtra" es, al final, la postura más segura.
✗ clave de root en un entorno efímero
entorno comprometido → root en producción con esa clave → alcanza archivos, secretos y otros servicios — todo.
○ clave no-root restringida a un comando
aunque se filtre la misma clave, solo puede ejecutar el único comando especificado. Sin shell, sin reenvío — el daño queda contenido a una operación.
Por qué es peligrosa una clave de root en un entorno efímero
Los entornos efímeros tienden a omitir el endurecimiento ("lo borraremos pronto"), lo que los convierte en un trampolín fácil para un atacante. Una clave de root de producción ahí maximiza el daño de golpe.
Supón que levantas un pod para cómputo y, para trabajar en producción desde él, registras una clave en el authorized_keys de root. Práctico — pero si ese pod se compromete, el atacante entra a producción como root con esa clave. Sea el punto de entrada un RCE o una fuga de clave, la forma final es la misma: producción tomada con una clave robada (relacionado: una clave robada vía RCE y facturada por fraude).
Tres pasos hacia claves de privilegio mínimo
Cambia de "concede todo el poder porque es cómodo" a "limita lo que puede hacer al mínimo".
Retira la clave de root del entorno efímero
~/.ssh/authorized_keys de producción las claves que ya no uses. Si están inactivas, quitarlas no tiene impacto. Primero, elimina lo "dejado por ahí".Aunque se necesite de nuevo, no vuelvas a root
Restringe la clave a una sola operación
command="..." y restrict a la línea de la clave en authorized_keys. Incluso un inicio de sesión exitoso solo puede ejecutar el único comando especificado, con el reenvío de puertos y el shell deshabilitados. Una fuga queda contenida a esa única operación.# Registra una clave restringida a UNA operación en el authorized_keys de un usuario no-root.
# Iniciar sesión con ella solo puede ejecutar el comando dado; el reenvío y la PTY están apagados.
command="/usr/local/bin/deploy-pull",restrict ssh-ed25519 AAAA...resto-de-la-clave-publica deploy@cirestrict deshabilita el reenvío, el reenvío de agente, la PTY, X11 y más de una vez; command="..." fija la acción ejecutable a una sola cosa. La jugada básica es una clave acotada a un único propósito — solo hacer pull de un despliegue, solo ejecutar un script específico — creada por caso de uso.
El montaje en el que cae la gente (peligroso)
- registrar una clave en el root de producción desde un pod/CI
- dejar en su sitio las claves terminadas
- reutilizar una clave en muchos servidores
- esparcir claves que conceden un shell completo
El montaje de privilegio mínimo
- llegar a producción solo como usuario no-root
- las claves están limitadas a una operación (restringidas a un comando)
- separar claves por servidor y propósito
- quitar las claves de authorized_keys en el momento en que dejan de usarse
Trata una clave reutilizada como tu activo más crítico
Piensa en una clave como "un pase práctico" y la reutilizarás y olvidarás de borrarla. Dale la vuelta: trátala como el activo más crítico que abre todo si se filtra. Separa por servidor y propósito, mantén las claves de producción fuera de los entornos efímeros, y quítalas siempre tras usarlas. Solo eso rompe la peor cadena — una fuga encadenándose a todo.
Qué hace este sitio
Este sitio usa una clave dedicada por servidor y nunca reutiliza claves. Los despliegues aterrizan en un usuario no-root, creado a propósito, y producción es unidireccional — "recibe, no sale a buscar" (→ producción solo recibe). No deja claves permanentes desde el cómputo efímero hacia producción; se conecta solo cuando hace falta, con privilegio mínimo. La razón es justo la de este artículo: diseña por adelantado el alcance de una clave para que sea pequeño, de modo que un compromiso no pueda encadenarse a todo.
Sigue leyendo
FAQ
Q¿Por qué es peligroso poner una clave de root en un entorno efímero?
Los entornos efímeros como los pods de GPU-cloud o los runners de CI son desechables, así que a menudo se omite el endurecimiento y pueden comprometerse. Pon ahí una clave de root a producción, y en el momento en que ese entorno se compromete, el atacante obtiene root en producción junto con la clave. Trata los entornos efímeros como no confiables y mantén las claves de root de producción fuera de ellos.
Q¿Y si aun así necesito llegar a producción desde un entorno efímero?
No vuelvas a root. Crea un usuario no-root dedicado y registra una clave que limite lo que puede hacer a una sola operación. En authorized_keys, una clave restringida a un comando y con la marca restrict significa que incluso un inicio de sesión exitoso solo puede ejecutar ese único comando. Una fuga queda entonces contenida a esa única operación.
Q¿Cuál es el principio clave para la gestión de claves?
Trata una clave reutilizada como tu activo más crítico y nunca construyas un montaje en el que una fuga exponga todo. Separa las claves por servidor y por propósito, y quita las claves de authorized_keys cuando ya no se necesiten. Eso evita que una sola fuga se encadene.