La ruta predeterminada de la clave del directorio de inicio no permitía escritura
La pregunta original sobre ZimaOS, publicada en diciembre de 2024, trataba sobre el flujo habitual de ~/.ssh/authorized_keys. La disposición de solo lectura del sistema impedía al autor crear ese archivo normalmente. Los primeros experimentos del tema no produjeron una solución alternativa duradera confirmada, por lo que no deben presentarse como una solución definitiva.
Un informe posterior sobre ZimaOS 1.7 utilizó un archivo de claves en /etc
En agosto de 2026, otro miembro de la comunidad informó de un método funcional en ZimaOS 1.7. Colocó las claves públicas en /etc/ssh/authorized_keys e indicó al demonio SSH que usara ese archivo. La configuración esencial era:
AuthorizedKeysFile /etc/ssh/authorized_keysCrea el archivo con privilegios administrativos, añade una clave pública completa por línea y establece permisos que impidan que otros usuarios lo modifiquen. Después, actualiza la configuración del servidor SSH y reinicia el demonio SSH. Como la publicación es un resultado de la comunidad y no una declaración oficial de compatibilidad, confirma el archivo de configuración real y el nombre del servicio en la versión instalada de ZimaOS antes de modificarlos.
Prueba el inicio de sesión con clave antes de desactivar la autenticación mediante contraseña
Mantén abierta la sesión SSH actual y conserva el acceso al terminal web de ZimaOS mientras realizas las pruebas. Abre un segundo terminal y comprueba que la clave pública permite iniciar correctamente una sesión nueva. Solo después de esa prueba debes considerar aplicar medidas de refuerzo opcionales.
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM no
PermitRootLogin no
PermitEmptyPasswords noEstas opciones tienen efectos más amplios que cambiar la ruta de las claves. Aplicarlas antes de comprobar que el inicio de sesión con clave funciona puede bloquear la administración remota. Además, quizá no sean adecuadas para todas las implementaciones, especialmente si el sistema depende deliberadamente de PAM o de un flujo controlado de inicio de sesión como root.
Considera el procedimiento específico de cada versión
La conversación abarca casi dos años, y el informe confirmado menciona específicamente ZimaOS 1.7. No demuestra que los mismos archivos se conserven tras las actualizaciones ni que se comporten de forma idéntica en versiones anteriores. Registra el cambio y vuelve a probar el acceso SSH después de actualizar el sistema operativo.
Preguntas frecuentes
¿Por qué no puedo crear ~/.ssh/authorized_keys en ZimaOS?
En el caso original, esa parte del sistema de archivos era de solo lectura. La solución alternativa posterior cambió la ubicación de las claves del demonio en lugar de intentar hacer escribible la ruta normal del directorio de inicio.
¿Dónde almacenaba las claves públicas el método funcional de ZimaOS 1.7?
Utilizaba /etc/ssh/authorized_keys y configuraba AuthorizedKeysFile para apuntar allí.
¿Debo desactivar inmediatamente la autenticación mediante contraseña?
No. Primero conserva disponible una sesión de recuperación y verifica un nuevo inicio de sesión autenticado mediante clave. Desactiva otros métodos de autenticación solo después de esa prueba y únicamente si se ajustan a la política de acceso del sistema.
