OpenSSH rechazó el directory .ssh con un enlace simbólico

En mi entorno, el directory real .ssh existe en un dispositivo externo y los enlaces de él a ~/.ssh con un enlace simbólico. El uso de openssh como cliente funciona sin problemas, pero sshd no permite la authentication con key pública dentro de él.

¿Hay algún método para usar el directory .ssh en un dispositivo externo?

 journalctl -u sshd 
 Authentication refused: bad ownership or modes for directory /pool/secure/ssh 

permissions

 $ ls -ld ~/.ssh lrwxrwxrwx. 1 foobar foobar 28 Mar 7 19:59 .ssh -> /pool/secure/ssh $ ls -l /pool/secure/ssh -rw------- 1 foobar foobar 381 Jun 29 15:01 authorized_keys -rw------- 1 foobar foobar 292 Jun 29 15:01 config -rw-------. 1 foobar foobar 5306 Jun 23 02:16 known_hosts $ ls -ld /pool/secure/ssh drwx------. 2 foobar foobar 8 Jun 29 15:01 

versión

 $ ssh -V OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 

Agregado el 2017-06-29 (Consejos)

  • OpenBSD y FreeBSD pueden modificar el permiso de acceso de symlink por chmod. Pero Linux no tiene una llamada al sistema que realice esa operación.
  • stat (2) sigue el enlace.
  • Especificaciones base Problema 7 no especificado el valor de los bits de modo de file devueltos en el campo st_mode.

Resuelto el 2017-06-30

auth_secure_path tiene la respuesta. Esta function comtesting los permissions de file y directory, el range incluye el directory principal. Continúa comprobando si los permissions correctos (solo el propietario puede escribir) están configurados, hasta pasar el inicio o la raíz.

 ex) general environment /home/foobar/.ssh (raise error if group and other can write) /home/foobar (same) break! ex) special environment (like me) /home/foobar/.ssh -> /pool/secure/ssh /pool/secure/ssh (raise error if group and other can write) /pool/secure (same) /pool (same) / (same) break! 

Es un problema de permissions.

.ssh verificar los permissions para todos los directorys anteriores e include la página principal de foobar , y también todos los directorys sobre el directory .ssh destino en su dispositivo externo. Además de foobar y los directorys .ssh destino, todos los demás deben ser propiedad de root y no escribibles por nadie más.

También puede tener un problema de SELinux. Puede verificar el context de security de SELinux de files y directorys con el indicador -Z :

 [sheepd0g@dogpound ~]$ ls -ZA drwxr-xr-x. root root system_u:object_r:home_root_t:s0 .. drwxrwxr-x. sheepd0g sheepd0g unconfined_u:object_r:user_home_t:s0 20170620-auditlogs -rw-rw-r--. sheepd0g sheepd0g unconfined_u:object_r:user_home_t:s0 random.dat drwx------. sheepd0g sheepd0g unconfined_u:object_r:ssh_home_t:s0 .ssh 

Un par de cosas para tener en count:

  1. El período al final de los campos del modo permiso significa que el context SELinux está activo para ese file.
  2. Observe que el campo Tipo para la carpeta .ssh es diferente (ssh_home_t).
  3. Es posible que los objects, types, políticas y configuraciones de SELinux no sean los mismos en las distribuciones, o incluso en las versiones principales. Lo que funciona para RHEL6 puede no serlo, digamos SUSE 10 o Debian 6 (no estoy seguro de que Debian 6 tenga la aplicación de SELinux, de fábrica …)

De todos modos, este es un buen lugar para mirar si todo lo demás falla. Puede verificar si SELinux está en modo de aplicación lo suficientemente fácil con lo siguiente:

 [sheed0g@dogpound ~]$ sudo getenforce Enforcing 

Si sospecha que SELinux nos ha solucionado el problema, puede cambiar SELinux a modo Permissive (las políticas están habilitadas, pero no se realiza ninguna acción, solo se registran / auditan las acciones):

 [sheepd0b@dogpound ~]$ sudo setenforce 0 [sheepd0b@dogpound ~]$ sudo getenforce Permissive 

Si tu problema desaparece, este es probablemente el problema.

Tenga en count que hay MUCHA más complejidad para SELinux que lo que aquí se representa. Si su .ssh / está en un recurso compartido de NFS, se le solicitará que realice más cambios con la configuration booleana de SELinux.

Aquí hay dos buenas references para SELinux:

Entrada de la wiki de CentOS en SELinux

Guía SELinux de Red Hat Enterprise Linux 7

El SSH se queja por una razón. El directory ~/.ssh/ es escribible en todo el mundo y, por lo tanto, cualquiera puede modificarlo.

Si no es un problema para usted, puede configurar StrictModes no en sshd_config y se usará de todos modos. No olvide reiniciar el service sshd después del cambio.