ssh rsa key auth só ocorre se eu já estiver logado no console

4

Não consigo descobrir isso - estou usando a autenticação baseada em chave id_rsa para nossos servidores (aproximadamente 400 servidores Linux e UNIX).

Neste caso, eu tenho 3 servidores idênticos com 3 instalações recentes do Ubuntu 12.04 - svr1 svr2 svr3 para o propósito desta discussão.

Eles são servidores blade da IBM, portanto, posso fazer login em um console remoto.

Para o svr1 eu posso ssh bem usando minha chave rsa - parece com isso do cliente com ssh -vvv:

debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/mbubb/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279 

e env vars estão definidos e eu estou em ...

Mas para o svr2 (e 3), é assim:

debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/mbubb/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering DSA public key: /home/mbubb/.ssh/id_dsa

... percorre outras opções importantes e finalmente:

   debug2: we did not send a packet, disable method
   debug1: No more authentication methods to try.
   Permission denied (publickey).

O que é curioso é se eu consolá-lo através do Bladecenter MM e, em seguida, ssh para o servidor funciona bem.

Olhando para /var/log/auth.log no svr2, não há entradas para quando recebo "Permission denied". Não parece "ver" a tentativa.

Eu verifiquei as permissões de diretório (homedir e sshdir) que são consistentes. Eu comparei / etc / ssh / sshd_config - eles são idênticos.

Talvez seja o PAM? Ou outro nível de autenticação.

Estou intrigado com isso - obviamente há algo básico aqui que eu não estou entendendo ...

    
por user150755 23.12.2012 / 17:46

1 resposta

5

Se você estiver usando um diretório pessoal criptografado, a correção é configurar um% co_de alternativo % location configurando

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

no arquivo authorized_keys do servidor, para que ele pareça em algum lugar diferente do diretório home do usuário para o arquivo.

O arquivo pode estar localizado em qualquer lugar, mas você precisa ter o sshd_config para separar os arquivos dos usuários em seus próprios diretórios, para que o sshd encontre as permissões apropriadas para o diretório e o arquivo.

    
por 23.12.2012 / 18:06

Tags