chave pública SSH não enviará para o servidor

Question

Eu tenho lutado com isso por algumas horas, então qualquer ajuda é muito apreciada ...

Eu tenho 2x servidores, dos quais eu posso ssh para com chaves públicas do OSX, sem problemas, então estou certo de que tudo está bem com sshd_config .

Estou tentando configurar uma tarefa cron para que rsync sincronize os dois servidores e precise do servidor B (backup) para ssh no servidor A usando uma chave pública.

Eu não posso, na minha vida, descobrir por que ele não encontra minhas chaves públicas - elas estão em ~/.ssh/ (ou seja, /root/.ssh ) e todas as permissões de arquivo estão corretas em A & B.

Esta é a saída:

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

Observe também que está procurando por chaves privadas que não existem ...

drwx------. 2 root root 4096 May 25 10:15 .
dr-xr-x---. 4 root root 4096 May 24 18:52 ..
-rw-------. 1 root root  403 May 25 01:37 authorized_keys
-rw-------. 1 root root    0 May 25 01:41 config
-rw-------. 1 root root 1675 May 25 02:35 id_rsa_tm1
-rw-------. 1 root root  405 May 25 02:35 id_rsa_tm1.pub
-rw-------. 1 root root  395 May 25 02:36 known_hosts

    

Answer 1

Dê uma olhada na sua página de manual do ssh:

   -i identity_file
          Selects a file from which the identity (private key) for public
          key authentication is read.  The default is ~/.ssh/identity for
          protocol   version   1,   and  ~/.ssh/id_dsa,  ~/.ssh/id_ecdsa,
          ~/.ssh/id_ed25519 and ~/.ssh/id_rsa  for  protocol  version  2.
          Identity files may also be specified on a per-host basis in the
          configuration file.  It is possible to have multiple -i options
          (and  multiple  identities  specified  in configuration files).

ou a página do manual ssh_config:

   IdentityFile
          Specifies a file from which the user's DSA, ECDSA,  ED25519  or
          RSA   authentication   identity   is   read.   The  default  is
          ~/.ssh/identity for  protocol  version  1,  and  ~/.ssh/id_dsa,
          ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for proto‐
          col version 2.  Additionally, any identities represented by the
          authentication  agent  will  be  used for authentication unless
          IdentitiesOnly is set.

Veja, existem alguns nomes de arquivos especiais que são tentados se você não especificar uma chave. Esses também são os arquivos que você vê na sua saída de log.

Para usar uma chave em um arquivo com nome diferente, você tem três opções:

• especifique o arquivo explicitamente usando a opção -i acima.
• configure o arquivo na configuração do seu cliente usando a opção IdentityFile acima.
• adicione a chave ao seu agente usando ssh-add .

Para sessões interativas, o agente é o mais flexível. Para sua tarefa cron, a opção -i é provavelmente a mais fácil.

    

Answer 2

Um arquivo mal-intencionado de authorized_keys no host de destino é outra razão pela qual o ssh exibe a mensagem "nós não enviamos um pacote" e solicita uma senha em vez de usar o pubkey auth: -

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method

O problema neste caso em particular era que os dados da chave pública, que haviam sido colados em .ssh/authorized_keys no host de destino, não tinham seu primeiro caractere: -

sh-rsa AAAA...

A solução foi simplesmente adicionar o "s" ausente.

ssh-rsa AAAA...

E assim: -

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.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
...
debug1: Authentication succeeded (publickey).

    

Answer 3

Essa sequência exata de mensagens de erro na pergunta também pode ocorrer no caso de um par de chaves privadas / públicas sem correspondência no lado local . Não, isso não faz qualquer sentido, mas eu apenas rasguei meu cabelo por um longo tempo tentando descobrir o que estava acontecendo.

• O sistema remoto A tem .ssh/mykey.pub copiado em .ssh/authorized_keys .
• O sistema local B possui .ssh/mykey , que é a chave privada correta para corresponder à chave pública do sistema A, mas também possui um arquivo .ssh/mykey.pub que é uma correspondência incorreta, possivelmente a versão anterior de uma chave substituída.

O SSH de B para A ( ssh -i mykey A ) falhará com as mensagens na pergunta, principalmente se você ativar -vv do cliente ssh que você verá:

Trying private key: .ssh/mykey
we did not send a packet, disable method

Isso é uma mentira porque a chave real não foi tentada, ela aparentemente usou o arquivo de chave pública local com o nome correspondente para descobrir se era provável que funcionasse e, em seguida, não fez nada de verdade quando era incompatível . Nenhuma quantidade de informações de depuração nos dois lados realmente sugere o problema.

    

Answer 4

Os nomes de arquivos padrão que o ssh está procurando são id_rsa e id_rsa.pub .

Se você quiser usar outros nomes de arquivos, terá que especificá-los em ssh_config (usando a configuração IdentityFile ) ou através da linha de comando ssh parâmetro -i .

    

Answer 5

Eu tive o mesmo problema no RedHat; verificou os logs e descobriu que o diretório home tinha direitos de usuário incorretos.

sshd[2507]: Authentication refused: bad ownership or modes for directory /home/user

Corrigir os direitos de dir home resolveu isso.

    

Answer 6

Tente

/sbin/restorecon -r /root/.ssh

Um possível problema com o contexto de vendas

    

Answer 7

Depois de executar

ssh-copy-id user@remote-host

normalmente, deveria funcionar. Mas se falhar, tente isto: faça o login no host remoto como o usuário que você deseja fazer login no futuro e execute:

ssh-keygen

Isso me ajudou.