La autenticación de clave pública falla SOLO cuando sshd es daemon

No tengo idea de cómo sucede esto. La distribución es Scientific Linux 6.1 y todo está configurado para realizar la autenticación mediante clave pública. Sin embargo, cuando sshd se ejecuta como un demonio (servicio sshd start), no acepta claves públicas. (Para obtener este registro, he cambiado el script sshd para agregar la opción -ddd)

debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 64 bytes for a total of 1853
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1

Si sshd se ejecuta en modo de depuración /usr/sbin/sshd -ddd, la autenticación funciona como un encanto:

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug3: Wrote 320 bytes for a total of 2109
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0

¿¿Algunas ideas?? ¿Alguien ha visto algo como esto?

Notas:

Los permisos de archivo se han verificado dos veces:

# ll -d .ssh
drwx------. 2 root root 4096 Oct 14 10:05 .ssh
# ll .ssh
total 16
-rw-------. 1 root root  786 Oct 14 09:35 authorized_keys
-rw-------. 1 root root 1675 Oct 13 08:24 id_rsa
-rw-r--r--. 1 root root  393 Oct 13 08:24 id_rsa.pub
-rw-r--r--. 1 root root  448 Oct 13 12:51 known_hosts

Me preguntaron si sshd puede acceder a los archivos raíz en "modo demonio". La respuesta más cercana a esta pregunta es:

# netstat -ntap | grep 22
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      19847/sshd 
# ps -ef | grep 19847
root     19847     1  0 09:58 ?        00:00:00 /usr/sbin/sshd

Si sshd se ejecuta como root, no sé cómo no es posible acceder a sus propios archivos. ¿Podría SELinux ser la causa?

Sí, SELinux es probablemente la causa. El .sshdirectorio probablemente esté mal etiquetado. Mira /var/log/audit/audit.log. Debería estar etiquetado ssh_home_t. Consulte con ls -laZ. Corre restorecon -r -vv /root/.sshsi es necesario.

Tuve el mismo problema En mi caso, restorecon y chcon no funcionaron.

No quería deshabilitar selinux. Después de mucha investigación, finalmente pensé que era porque mi directorio de inicio estaba montado desde otro lugar (NFS). Encontré este informe de error que me dio pistas.

Corrí:

> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off

para confirmar use_nfs_home_dirs estaba apagado y luego:

sudo setsebool -P use_nfs_home_dirs 1

Encenderlo.

Ahora puedo ingresar a mi máquina con mi llave y sin ingresar una contraseña. Alternar el booleano use_home_nfs_dirs fue lo que necesitó para mí.

Para agregar a la respuesta de Mark Wagner, si está utilizando una ruta de directorio de inicio personalizada (es decir, no /home), debe asegurarse de haber configurado el contexto de seguridad de SELinux. Para hacerlo, si tiene directorios de inicio de usuario en, por ejemplo /myhome, ejecute:

semanage fcontext -a -e /home /myhome
restorecon -vR /myhome

Parece que usa diferentes teclas al probar las conexiones, 0x7f266e1a8840 vs 0x7f85527ef230. Intente conectarse usando 'ssh -v example.com' a sshd ejecutándose como un demonio y en modo de depuración y busque las claves utilizadas por ssh alrededor de la cadena "Ofrecer clave pública RSA".