OpenSSH recusou o diretório .ssh com um link simbólico

Question

No meu ambiente, o diretório .ssh real existe no dispositivo externo e links dele para ~/.ssh com um link simbólico. Usando openssh como cliente está trabalhando sem problema, mas sshd não permite autenticação com chave pública dentro dele.

Existe algum método para usar o diretório .ssh no dispositivo externo?

journalctl -u sshd

Authentication refused: bad ownership or modes for directory /pool/secure/ssh

permissões

$ 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

versão

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

Adicionado em 2017-06-29 (Dicas)

• O OpenBSD e o FreeBSD podem modificar a permissão de acesso do symlink por chmod. Mas o Linux não tem chamada do sistema para fazer essa operação.
• stat (2) siga o link.
• Especificações básicas do problema 7 não especificado o valor dos bits do modo de arquivo retornados no campo st_mode.

Resolvido em 2017-06-30

auth_secure_path tem a resposta. Esta função verifica as permissões de arquivo e diretório, o intervalo inclui o diretório pai. Ele continua a verificar se as permissões corretas (somente o proprietário pode gravar) estão definidas, até passar a casa ou o root.

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!

    

Answer 1

É um problema de permissões.

Você precisa verificar as permissões de todos os diretórios acima e incluir a% home de foobar e também todos os diretórios acima do diretório .ssh de destino em seu dispositivo externo. Além dos diretórios foobar e% target .ssh , todos os outros devem ser de propriedade de root e não podem ser gravados por mais ninguém.

Você também pode ter um problema no SELinux. Você pode verificar o contexto de segurança de arquivos e diretórios do SELinux com o -Z flag:

[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

Algumas coisas a serem observadas:

1. O período no final dos campos do modo de permissão significa que o contexto do SELinux está ativo para esse arquivo.
2. Observe que o campo Tipo para a pasta .ssh é diferente (ssh_home_t).
3. Objetos, tipos, políticas e configurações do SELinux podem não ser os mesmos em distribuições ou mesmo em versões principais. O que funciona para o RHEL6 pode não ser, digamos, SUSE 10 ou Debian 6 (eu não estou certo de que o Debian 6 tenha a aplicação do SELinux fora da caixa ...)

Independentemente disso, este é um bom lugar para procurar se tudo o mais falhar. Você pode verificar se o SELinux está no modo de execução com bastante facilidade com o seguinte:

[sheed0g@dogpound ~]$ sudo getenforce
Enforcing

Se você suspeitar do problema do SELinux, poderá alternar o SELinux para o modo Permissivo (as políticas são ativadas, mas nenhuma ação é tomada - apenas registro / auditoria de ações):

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

Se o seu problema desaparecer, este é provavelmente o problema.

Por favor, note que há muito mais complexidade para o SELinux do que o representado aqui. Se o seu .ssh / estiver em um compartilhamento NFS, você será obrigado a fazer mais alterações nas configurações booleanas do SELinux.

Aqui estão duas boas referências para o SELinux:

entrada do wiki do CentOS no SELinux

Guia do SELinux do Red Hat Enterprise Linux 7

    

Answer 2

O SSH está reclamando por um motivo. O diretório ~/.ssh/ é mundialmente gravável e, portanto, qualquer um pode modificá-lo.

Se isso não for um problema para você, você pode definir StrictModes no em sshd_config e ele será usado de qualquer maneira. Não se esqueça de reiniciar o serviço sshd após a alteração.