Dirigido a cualquier desarrollador que use la API de Coolify para leer logs de despliegue, no solo al equipo de sistemas. Es comportamiento propio de Coolify 4.1.2, no algo introducido por Pampling — pero afecta a todas nuestras aplicaciones por igual.
Los logs de deployment que devuelve la API de Coolify incluyen la clave SSH privada del host, en base64 y en claro, dentro del comando de clonado del repositorio.
Verificado empíricamente sobre un log real de 82 KB: la clave localhost's key aparece completa (comprobado con tres sondas independientes en zonas únicas del material criptográfico). No es una deploy key de repositorio, es de mucho más alcance: es la clave con la que Coolify accede al propio servidor como root — ver Servidor pmpserverubu §3, restricción de origen de esa clave.
Ocurre en cada despliegue de cada aplicación, no en un caso aislado.
Para meter la clave dentro del contenedor de build, Coolify genera y ejecuta un comando del tipo:
echo <clave-privada-en-base64> | base64 -d > /root/.ssh/id_rsa
y registra en el log de deployment todos los comandos que ejecuta, incluido ese, con su argumento completo.
Base64 no es cifrado: es una codificación reversible. Publicar una clave en base64 es funcionalmente equivalente a publicarla en texto plano.
Vía la API REST de Coolify:
curl -s -H "Authorization: Bearer $COOLIFY_TOKEN" \
"https://coolify.pampl.ing/api/v1/deployments/DEPLOYMENT_UUID" \
| jq -r '.logs | fromjson | .[] | .output'
Ver Coolify — Gestión de aplicaciones §3 para el resto de recetas sobre logs de deployment.
logs a los tokens de API que no tienen el permiso read:sensitive (ver Coolify §5). Esa restricción es una protección legítima, no un obstáculo burocrático: hoy es lo único que impide que la clave root circule a través de los tokens del equipo de desarrollo. No debe "resolverse" concediendo ese permiso a tokens de desarrollo por comodidad — haría exactamente lo contrario de proteger.-----BEGIN OPENSSH PRIVATE KEY-----, o bloques base64 largos inmediatamente después de un echo ... | base64 -d).from= sobre esa clave en /root/.ssh/authorized_keys (ver Servidor pmpserverubu §3) hace que, aunque la clave se filtre a través de un log, ya no sirva para conectar desde fuera de la red privada del servidor. Reduce mucho el impacto real de una fuga, pero no elimina el problema de fondo: la clave sigue viajando en claro en cada log de deployment.read:sensitive a tokens de desarrollo "para poder ver más en los logs de deploy".