Qualquer motivo sshd_config não pode ser definido para um arquivo authorized_keys não em casa?

Question

Solução de problemas de SSH e NX Eu tenho uma conexão SSH em funcionamento usando uma chave RSA. O problema é que o servidor NX deseja que o parâmetro sshd_config AuthorizedKeysFile seja configurado para um arquivo instalado pelo NX, /var/lib/nxserver/home/.ssh/authorized_keys2 . Depois que fiz essa alteração, a conexão remota do SSH não pôde ser autorizada. eu tentei,

• acrescentando o home authorized_keys em ~/.ssh a este arquivo / var ...
• Suas permissões são nx , group root e 644, então adicionei os parâmetros AllowUsers e AllowGroups com ambas as contas ao final de sshd_config .
• Reiniciou o servidor SSHD após cada alteração sshd.

Infelizmente, o ssh não permitirá essa conexão.

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Se eu alterar sshd_config AuthorizedKeysFile de volta para as configurações originais, então tudo é ótimo. Então, alguma razão o sshd não aceita o arquivo de chave autorizado que o NX quer?

Existem alguns problemas confusos aqui. Por exemplo, o authorized_keys2 foi depreciado ? Não que esses caras se importassem , porque eles discutem o uso de authorized_keys2 para NX dois anos após o primeiro post.

Muitos usuários do NX observam que o AuthorizedKeysFile é apenas o nome do arquivo, mas esta página man em sshd_config (igual ao CentOS6) e diz "Após a expansão do [token], o AuthorizedKeysFile é considerado um caminho absoluto ou relativo ao diretório home do usuário." O caminho do NX deve estar OK, certo?

Infelizmente meu servidor do CentOS está usando o OpenSSH 5.3, porque o 6.2 (no meu cliente) suporta espaço lista deliminada de AuthorizedKeysFile (s).

    

Answer 1

Primeiro de tudo, em tais condições eu sempre tento ter meus logs no máximo iniciando o customizado sshd :

sshd -d -p 11122 -f /new/config/file

E tentando se conectar a ele:

ssh -v -p 11122 this.host

Isso torna sua configuração atual segura e fornece todas as informações sobre como a conexão foi estabelecida.

E agora vem um palpite. sshd exigirá que os arquivos-chave sejam:

1. Acessível e legível pelo servidor.
2. Gravável apenas pelo usuário. E isso significa que todas as pastas (/ var, / var / lib e assim por diante) não devem ser graváveis por nenhum usuário ou grupo além de root , wheel e usuário que efetua login. / li>

Answer 2

Esta é uma pergunta Fd, porque após usar a dica do Kworr para testar sshd parando o serviço daemon e iniciando-o manualmente no modo de depuração, o caminho não-doméstico funciona apenas para localizar ( que é o que você esperaria depois de "expansão de token") Desculpe pessoal.

Assim, para responder a minha própria pergunta: Não, não há nenhuma razão para que authorized_keys não possa estar fora de casa.

    

Answer 3

O padrão é usar um arquivo no diretório pessoal do usuário (veja abaixo). O% h pode ser usado explicitamente para mostrar isso. Aqui mostra uma lista de cada caminho separado por um espaço ...

O que eu tentaria é alterar as permissões para 600. Isso é o que eu tenho meu arquivo autorized_keys definido em todas as minhas contas. Permissões inválidas são traduzidas em um erro de permissões negadas. Isso permite que você verifique se o arquivo authorized_keys não inclui adições indesejadas antes de corrigir suas permissões.

Se for esperado que usuários diferentes façam uso das mesmas authorized_keys, então você tem um problema ...

AuthorizedKeysFile
         Specifies the file that contains the public keys that can be used for user authentication.  The format is described in the AUTHORIZED_KEYS FILE
         FORMAT section of sshd(8).  AuthorizedKeysFile may contain tokens of the form %T which are substituted during connection setup.  The following
         tokens are defined: %% is replaced by a literal '%', %h is replaced by the home directory of the user being authenticated, and %u is replaced by
         the username of that user.  After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory.
         Multiple files may be listed, separated by whitespace.  The default is “.ssh/authorized_keys .ssh/authorized_keys2”.