Solución:
Como han mencionado otras respuestas, parece que no hay forma de obligar a SSH a ignorar esa opción. El cheque está sucediendo en authfile.c función sshkey_perm_ok:
if ((st.st_uid == getuid()) && (st.st_mode & 077) != 0) {
error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
error("@ WARNING: UNPROTECTED PRIVATE KEY FILE! @");
error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
error("Permissions 0%3.3o for '%s' are too open.",
(u_int)st.st_mode & 0777, filename);
error("It is required that your private key files are NOT accessible by others.");
error("This private key will be ignored.");
return SSH_ERR_KEY_BAD_PERMISSIONS;
}
Si cambiar los permisos del archivo de clave no es una opción, una solución es descargar la fuente OpenSSH, eliminar ese cheque del código y reconstruirlo.
Una respuesta a una pregunta relacionada sugiere que no hay forma de omitir la verificación de permisos.
Sin embargo, tuve el mismo problema — quería que varios usuarios compartieran la misma clave para poder acceder y controlar un gran grupo de hosts — y mi solución podría ser útil para otros.
Esto es lo que hice:
- Cree un usuario especial (digamos,
master
) y grupo (master
) para mantener la tecla. - Cree / almacene los archivos de claves en
~master/.ssh/
. - Otorgue permisos de lectura grupales al archivo de claves,
chmod g+r ~master/.ssh/id_rsa
. - Agregue cada uno de los usuarios autorizados al
master
grupo. - Hacer un enlace desde
~user/.ssh/id_rsa
para~master/.ssh/id_rsa
.
Esto permite al usuario autorizado ssh
sin problemas, pero evita abrir la llave a todos. Además, el propietario de la clave no es root.
Extrañamente, el master
el propio usuario seguirá recibiendo la advertencia de “clave privada desprotegida”. Esto puede evitarse cambiando el propietario (pero no el grupo) del archivo de claves a algún usuario especial que nunca necesitará usar la clave,
sudo chown daemon ~master/.ssh/id_rsa
, por ejemplo.