Estoy administrando un servidor RedHat donde los usuarios inician sesión a través de SSH con autenticación basada en clave privada/pub.
Me gustaría evitar que cambien, eliminen o modifiquen accidentalmente el contenido de su~/.sshcarpetas. Algunos de ellos ya han modificado de forma recursiva 777 toda su propia carpeta de inicio porque "era más fácil compartir archivos con colegas de esta manera" y se dispararon en el pie.
¿Alguna idea de cómo puedo lograr esto? Preferiblemente con sistema de permisos estándar de Linux.
Respuesta1
La respuesta corta es que no puedes.
SSH es muy exigente con los permisos y no reproduce archivos que no le gustan. Además, los usuarios ssh_configse analizan.antesla configuración de todo el sistema.
Dicho esto,puedeSerá posible colocar los archivos en otro lugar y montar el directorio como un sistema de archivos de solo lectura $HOME/.sshpara cada usuario. (Es posible, pero no sé cómo tratarían esto ssh y las herramientas asociadas).
Algunos de ellos ya han modificado de forma recursiva 777 toda su propia carpeta de inicio.
Entonces tienes problemas de SEGURIDAD y capacitación mucho mayores.
Respuesta2
Es difícil proteger a los usuarios de su propia ignorancia e incompetencia.
Pero dependiendo de cuánto necesite permitir que sus usuarios se administren por sí mismos y cuánto administre usted por ellos: puede configurar sshd para buscar claves en una ubicación alternativa fuera de su directorio de inicio y en otro lugar que no sea ~/.ssh/authorized_keys.
Comando de claves autorizadas
Una solución relativamente compleja es la/etc/ssh/sshd_config AuthorizedKeysCommand directiva que, en lugar de depender de archivos de claves_autorizadas, especifica un programa que se utilizará para buscar las claves públicas del usuario, por ejemplo:
un servicio web (trivial)
o cuando sus nombres de usuario son idénticos a los nombres de usuario de Github, puede permitir que los usuarios se autentiquen con los pares de claves que cargaron allí:
AuthorizedKeysCommand /usr/bin/curl https://github.com/%u.keys
Como se menciona enesta respuesta; Deberá crear una política SELinux adecuada para AuthorizedKeysCommand, ya que las políticas predeterminadas la bloquean.
Me encanta este enfoque porque puede resolver muchos problemas relacionados con la administración de claves autorizadas: agrega administración centralizada, elimina el problema del huevo y la gallina de obtener claves autorizadas para los servidores cuando desea deshabilitar la autenticación de contraseña en ssh y más.
Aprovecha el hecho de que las claves públicas no son particularmente sensibles (a diferencia de sus claves privadas asociadas), por lo que centralizar su administración no agrega riesgo en mi humilde opinión y probablemente incluso mejore sus capacidades de control y generación de informes.
Archivo de claves autorizadas
Un poco menos complejo es almacenar claves en un directorio fuera de su directorio de inicio. Por ejemplo, usar /etc/ssh/<username>(reemplazar <username>con su nombre de usuario real). Este directorio debe tener 755 permisos y ser propiedad del usuario. Mueva el authorized_keysarchivo a él. El archivo autorizado_keys aún debe tener permisos 644 y ser propiedad del usuario.
En/etc/ssh/sshd_configajustar elAuthorizedKeysFileconfiguración
AuthorizedKeysFile /etc/ssh/%u/authorized_keys
Y reinicie el demonio ssh
Respuesta3
La mejor solución que se me ocurre es crear .sshy authorized_keysser de propiedad raíz.
.ssh/claves_autorizadas de propiedad raíz
SSH es exigente con los permisos, pero no sin razón. En primer lugar, requiere que el propio usuario tenga acceso de lectura authorized_keys(lo que requiere acceso de lectura a todos los directorios principales). En segundo lugar, niega el acceso si cualquier usuario que no sea el propio usuario o root tiene acceso de escritura a /home, .ssho authorized_keys. Esto no lo permite o+wy g+wpara un grupo que tiene otros usuarios en él.
Esta configuración me funciona, el usuario puede iniciar sesión:
drwxr-xr-x 19 root root 4096 Sep 22 11:24 /
drwxr-xr-x 3 root root 4096 Sep 22 11:19 /home/
drwx------ 14 test test 4096 Sep 22 11:44 /home/test/
drwxr-x--- 2 root test 4096 Sep 22 11:42 /home/test/.ssh/
-rw-r--r-- 1 root test 98 Sep 22 11:36 /home/test/.ssh/authorized_keys
Dado que .sshy authorized_keysson propiedad de root, el usuario no puede cambiar los permisos sobre ellos ni eliminarlos. Tampoco pueden editar su propio authorized_keysarchivo.
Si desea permitir que el usuario edite su archivo authorized_keys, puede agregar permisos de escritura grupal. Esto requiere que el testgrupo no tenga más miembros que testél mismo:
-rw-rw-r-- 1 root test 99 Sep 22 12:04 /home/test/.ssh/authorized_keys
Con cualquiera de los dos enfoques, el usuario ya no puede crear sus propios archivos en .ssh, por lo que es posible que desee proporcionarles también algunos archivos adicionales. Algunas que me vienen a la mente son: known_hosts, configy id_rsa{.pub,}otros tipos de claves.
Alternativa: chattr
Algunos sistemas de archivos Linux son compatiblesatributos de archivo, en particular unbandera inmutable. Los archivos/directorios con el indicador inmutable establecido no se pueden eliminar, modificar ni cambiar sus permisos. Sólo el root puede establecer/borrar este indicador.
Este comando funcionaría, incluso con la propiedad/permisos predeterminados:
# chattr +i ~test/.ssh/{authorized_keys,}
Ahora .sshya authorized_keysno se puede modificar de ninguna manera, ni siquiera por root. Si root necesita actualizar estos archivos, los necesitará chattr -iprimero. Se utiliza lsattrpara comprobar los atributos.
Este enfoque es más simple, pero menos flexible. También necesita soporte para el sistema de archivos; Creo que es compatible al menos con ext2/3/4, XFS y btrfs.
¿ACL Posix?
También hayACL Posix(Listas de control de acceso), que permiten un control un poco más detallado. No estoy muy familiarizado con ellos y no estoy seguro de si son de alguna ayuda aquí.
Modos estrictos
Nota:Se desaconseja mucho, pero se prevé que esté completo.
El servidor OpenSSHtiene una directiva de configuraciónllamado StrictModes, que determina qué tan exigente es SSH con los permisos:
Especifica si sshd debe verificar los modos de archivo y la propiedad de los archivos y el directorio de inicio del usuario antes de aceptar el inicio de sesión. Esto normalmente es deseable porque los principiantes a veces dejan accidentalmente que su directorio o archivos se puedan escribir en todo el mundo. El valor predeterminado es
yes.
Si desactiva esa opción, tendrá más libertad sobre cómo configurar la propiedad y los permisos. Sin embargo, SSH es estricto por defecto por buenas razones. Un usuario que modifica 777 sus archivos SSH es un riesgo para la seguridad.
Respuesta4
Ejecute un trabajo cron para arreglar los permisos cada noche.
Eliminar archivos es un poco más difícil. Posiblemente también puedas restaurar los archivos faltantes desde la copia de seguridad desde cron. Pero parece que podrías meterte en casos extremos extraños con eso... puede que necesites más inteligencia de la que un script puede proporcionar. Comenzaría poco a poco y agregaría funciones con cautela a una función de restauración.