O cliente SSH não oferece chave pública para o servidor SSH

Question

Eu tenho dois usuários não-root em um servidor Linux. Se eu fizer uma conexão SSH (autenticação baseada em chave) para um servidor SSH específico sob o primeiro usuário, ele será bem-sucedido:

/* debug messages removed for brevity */
debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '.ssh/id_rsa': 
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8

Agora, sob o segundo usuário, onde especifico o arquivo de chave privada com -i .ssh/SD , a autenticação baseada em chave não é bem-sucedida. Todas as mensagens de depuração do cliente SSH são exatamente as mesmas até aqui:

/* debug messages removed for brevity */
debug1: Next authentication method: publickey
debug1: Trying private key: .ssh/SD
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '.ssh/SD': 
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Por que o cliente SSH no segundo caso não oferece a chave pública? Esta é uma etapa obrigatória na autenticação baseada em chave, não é?

    

Answer 1

Há duas coisas que eu verificaria.

1. Parece que você está usando chaves ssh diferentes, portanto, verifique se as permissões estão corretas. A pasta .ssh deve ser 0700, a chave privada rsa deve ser 0600, a chave pública deve ser 0644. Use ls -l ~/.ssh para ver as permissões.

2. Certifique-se de que a chave pública seja transferida para o segundo servidor. Você pode usar ssh-copy-id ~/.ssh/SD.pub para copiar a chave pública para o segundo servidor. Depois que ele for executado, você poderá verificar se ele está lá, efetuando login no servidor (como root ou usando uma senha) e, em seguida, cat ~/.ssh/authorized_keys . Ele deve ter a saída exata de cat ~/.ssh/SD.pub em seu sistema local. Pode ter outras chaves se você as adicionou antes.

Se ambas as coisas parecerem boas e você ainda não conseguir entrar, você deve olhar os logs do servidor em / var / log / secure ou você também pode executar um segundo servidor ssh em primeiro plano para ver o que está acontecendo. No servidor remoto, execute

sudo $(which sshd) -p 6666 -D -d

Em seguida, no seu sistema, tente efetuar login no novo daemon ssh com

ssh -p 6666 -i ~/.ssh/SD <SERVER>

Você deve ver as informações de registro impressas no terminal no servidor, que pode ter mais informações sobre o motivo da falha do login.

Como uma explicação para o segundo daemon sshd. Você precisa de sudo mesmo que as permissões sejam geralmente 0755 para segurança. Você também precisa fornecer o caminho completo para o binário sshd. É por isso que $(which sshd) está incluído no comando. -p 6666 define a porta (acabei de escolher uma aleatoriamente). -D será executado em primeiro plano e -d ativará a depuração.