Eu tenho alguns usuários que têm diferentes diretórios $ HOME do que /home/ .
As residências dos usuários estão em /pkg/home e /pkg owner é um usuário diferente, mas todos os usuários têm acesso de grupo a /pkg . Parece que o SSHD restringirá o acesso a authorized_keys (por exemplo, /pkg/home/usera/.sshd/authorized_keys ) porque o usuário não é o proprietário do caminho completo.
Existe alguma opção para sshd_config alterar esta restrição?
Não importa quem possui / pkg /. Se ele fosse de propriedade de usera , você teria problemas com userb etc. Portanto, deve ser algo mais que impeça o SSHD de usar o arquivo authorized_keys . Você precisa verificar se esse arquivo é gravável apenas pelo proprietário e se é de propriedade do usuário. O mesmo se aplica a todos os diretórios pais.
É tudo ou nada: se você desativar a opção StrictModes , o sshd nunca irá verificar nenhum modo de arquivo. Não há como dizer que certos casos ímpares são aceitáveis, como um diretório gravável em grupo (o que é bom se o usuário estiver sozinho no grupo).
O OpenSSH verifica as permissões e a propriedade de ~/.ssh/authorized_keys e seus diretórios contidos para cima. No entanto, interrompe a comparação quando alcança o diretório inicial. Por exemplo, no arranjo clássico em que o arquivo de autorização é /home/joe/.ssh/authorized_keys e /home/joe é o diretório pessoal do usuário, apenas /home/joe/.ssh/authorized_keys , /home/joe/.ssh e /home/joe são verificados.
Portanto, embora seu cenário seja altamente duvidoso ( /pkg deve ser de propriedade de root, com permissões de grupo adicionais, se necessário), ele não deve afetar o ssh.
Se algum link simbólico estiver envolvido, observe que o ssh expande todos os links simbólicos antes de iniciar suas verificações.
Os registros do sistema podem ter informações relevantes. Verifique se suas tentativas de login com falha causam qualquer mensagem de log.
Verifique se a sua versão do ssh realiza as mesmas verificações que a minha (observei a origem do OpenSSH 5.5p1) executando um daemon do modo de depuração em uma porta personalizada ( sshd -d -p 2222 ). Use strace -f -efile sshd -d -p 2222 , se necessário, para verificar a permissão dos arquivos que o servidor verifica. Se essas verificações de permissão não forem o problema, a adição de mais -d flags poderá lançar alguma luz.
Se você tiver o AppArmor, também há a possibilidade de que ele esteja restringindo o servidor ssh a ler arquivos nos diretórios .ssh dos usuários. Se você tiver o AppArmor e os diretórios pessoais em um local fora do padrão, será necessário atualizar as políticas do AppArmor (não apenas para o SSH). Veja Evince não consegue começar porque não pode leia .Xauthority .
Eu tive o mesmo problema, usando '/ data' como base para os diretórios do usuário. Para mim, não foi o suficiente para executar 'restorecon -R -v ~ / .ssh'. Primeiro, eu tive que correr
# semanage fcontext -a -e /home /data
como root e, em seguida, (também como raiz, como o diretório / data continha um diretório de propriedade da raiz)
# restorecon -R -v /data