SELinux impide ssh mediante clave pública

SELinux impide ssh mediante clave pública

Tengo un usuario $USERque es una cuenta de usuario del sistema con un archivo de usuarios autorizados. Cuando tengo SELinux habilitado, no puedo ingresar al servidor mediante ssh usando la clave pública. Si puedo setenabled 0, $USERahora puedo iniciar sesión.

¿Qué bool/política de SELinux debo cambiar para corregir este comportamiento sin deshabilitar SELinux por completo?

Vale la pena señalar que $USERpuedo iniciar sesión con una contraseña bajo esta configuración predeterminada de SELinux. Agradecería tener alguna idea de lo que está sucediendo aquí y por qué SELinux no está bloqueando eso. (Deshabilitaré la autenticación de contraseña por completo después de que esto se resuelva, por lo que es mejor saber esta pregunta)

Respuesta1

Suponiendo que los permisos del sistema de archivos sean correctos en ~/.ssh/*, luego verifique la salida de

sealert -a /var/log/audit/audit.log

Debería haber una pista en una entrada AVC allí. Lo más probable es que la solución se reduzca a ejecutar:

restorecon -R -v ~/.ssh

Respuesta2

Si sealertfalta en un sistema, como ocurría en un sistema que encontré recientemente, también existe la posibilidad de audit2allow:

$ sudo audit2allow -w -a
type=AVC msg=audit(1548909218.552:1037): avc:  denied  { read } for  pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file
    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

Desglosando el AVC:

avc: denied { read } for pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556
    "sshd" was denied read on a file resource named "authorized_keys".
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
    SELinux context of the sshd process that attempted the denied action.
tcontext=system_u:object_r:admin_home_t:s0 tclass=file
    SELinux context of the authorized_keys file.

Aunque audit2allow no indicó de manera concisa cómo solucionar el problema, al observar scontexty tcontext, el scontextvalor indica el contexto necesario mientras tcontextmuestra el contexto insatisfactorio del archivo "authorized_keys".

En este caso, restorecon -R -v ~/.sshpor sí solo no funcionó, pero aplicando el contexto deseado sí:

$ sudo semanage fcontext --add -t ssh_home_t "/path/to/my/.ssh(/.*)?"; \
$ sudo restorecon -FRv /path/to/my/.ssh

Según sea necesario, cambie los nombres de los recursos y/o el contexto según lo que se ve en el AVC. Los detalles precisos en esta respuesta se construyeron para resolver un problema relacionado con las "claves_autorizadas", pero una solución podría seguir este modelo incluso si se indica un archivo o contexto diferente en el AVC producido por sealerto audit2allow.

información relacionada