Por que o ssh / sshd no servidor tenta acessar o /home/user/.ssh depois que eu movi o diretório home de meus usuários?

0

Mudei meu diretório pessoal de usuários com usermod -m -d /path/to/new/home/username , o que parece ter funcionado bem.

No entanto, no meu diretório home [movido] eu tenho a pasta ".ssh" que está configurada para permitir a conexão de outro host usando autenticação de chave pública, sem senha. Isso (autenticação de chave pública sem senha) funcionou bem ao conectar a partir da estação de trabalho "cliente", antes que eu mudei meu diretório home.

man sshd diz que o local do arquivo authorized_keys é por padrão ~/.ssh/authorized_keys e meu sshd_config não o substitui porque não tem nenhum conjunto de diretivas AuthorizedKeysFile .

Sempre que me conecto ao host do meu "cliente", ele pede uma senha. Não deveria, deveria me registrar diretamente, cortesia de auth de chave pública. Minha suspeita é que sshd no host ainda acha que meu diretório pessoal é /home/<user> ou, na pior das hipóteses, insiste em adicionar meu nome de usuário a algum prefixo assumido, que não é mais válido.

O interessante é que, se eu gerar outro sshd -de -p 23 e conectar ao host nessa porta com ssh -p 23 ... (mesma linha de comando, apenas com -p 23 adicionado), ele reconhecerá o caminho do meu novo diretório inicial em o host e me registra de verdade.

Eu tentei recarregar e reiniciar sshd com service sshd reload e service sshd restart e, finalmente, reinicializei o host. Nada mudou em relação a sshd me pedindo senha.

Onde eu começo a depurar isso? Eu estou no CentOS 6.5 x86-64.

Atualizar

Agora tenho strong indicação de que isso é relacionado ao SELinux. Aparentemente, o contexto de segurança no novo diretório inicial está errado, mas é praticamente tudo que descobri. O SELinux foi instalado no sistema sem que eu me perguntasse, e eu não sei nada sobre ele (nem deveria, já que não toquei nele, mas confiei em usermod -m -d ... para fazer um trabalho que ele deveria fazer).

    
por amn 10.10.2014 / 14:59

1 resposta

1

Uma solução é modificar sua configuração do SELinux para que o SELinux esteja ciente do contexto requerido neste contexto:

semanage fcontext -a -s unconfined_u -t ssh_home_t '/path/to/your/new/home/\.ssh(/.*)?'

Isso é inspirado na saída de semanage fcontext -l | grep ssh , que no meu sistema revela que /root também é gerenciado dessa maneira.

Observe que escolhi o usuário unconfined_u SELinux - se você pretende usar um diferente, por exemplo Se esta casa for para um serviço, pode ser sensato escolher system_u .

    
por 10.10.2014 / 16:37