Chave pública SSH não envia para o servidor

Estou lutando com isso há algumas horas, então qualquer ajuda é muito apreciada ...

Eu tenho dois servidores com os quais posso sshcom chaves públicas do OSX, sem problemas, por isso estou certo de que tudo está bem sshd_config.

Estou tentando configurar um trabalho cron para rsyncsincronizar os dois servidores e preciso do servidor B (backup) para o sshservidor A usando uma chave pública.

Durante toda a minha vida, não consigo descobrir por que não encontra minhas chaves públicas - elas estão dentro ~/.ssh/(ie. /root/.ssh) E todas as permissões de arquivo estão corretas no 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 ele está procurando 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

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 bem, 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 saída do seu log.

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

• especifique o arquivo explicitamente usando a -iopção acima .
• configure o arquivo na sua configuração de cliente usando a IdentityFileopção acima .
• adicione a chave ao seu agente usando ssh-add.

Para sessões interativas, o agente é o mais flexível. Para o seu trabalho cron, a -iopção é provavelmente a mais fácil.

Um arquivo autorizado_keys malformado no host de destino é outro motivo pelo qual o ssh gera a mensagem "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 nesse caso específico era que os dados da chave pública, que foram colados .ssh/authorized_keysno host de destino, estavam com seu primeiro caractere ausente: -

sh-rsa AAAA...

A solução foi simplesmente adicionar os "s" ausentes.

ssh-rsa AAAA...

E entao:-

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).

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

• O sistema remoto A foi .ssh/mykey.pubcopiado .ssh/authorized_keys.
• O sistema local B possui .ssh/mykeyessa é a chave privada correta para corresponder à chave pública do sistema A, mas também possui um .ssh/mykey.pubarquivo que corresponde a uma falha de correspondência, possivelmente a versão anterior de uma chave substituída.

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

Tentando chave privada: .ssh / mykey
não enviamos um pacote, desabilite o método

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

Os nomes de arquivo padrão que o ssh está procurando é id_rsae id_rsa.pub.

Se você quiser usar outros nomes de arquivo, especifique-os ssh_config(usando a IdentityFileconfiguração) ou através do parâmetro da linha de comando ssh -i.

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

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

A correção dos direitos do diretório doméstico resolveu isso.

Uma maneira simples de depurar no Debian / Ubuntu é: Conecte-se com a senha e siga o log

tail -f /var/log/auth.log

Tente conectar a partir de outro terminal e você verá o erro ...

No meu caso, o diretório / root era 770 e não 700, que é o padrão. O erro foi "Autenticação recusada: propriedade incorreta ou modos para o diretório / raiz"

Corrija isso e pronto.

Experimentar

/sbin/restorecon -r /root/.ssh

Um possível problema com o contexto de vendas

Depois de correr

ssh-copy-id user@remote-host

normalmente deve funcionar. Mas, se falhar, tente o seguinte: efetue login no host remoto como o usuário no qual você deseja efetuar login no futuro e execute:

ssh-keygen

Isso me ajudou.

Então, o que aconteceu comigo é que tenho 2 VMs para acessar da minha máquina local (2 chaves id_rsa.pub e id_rsa2.pub). Percebi que minha conexão ssh está usando id_rsa.pub por padrão para qualquer conexão ssh user@xx.xx.xx.xx. Resolvi meu problema adicionando um arquivo de configuração e especifique a identidade a ser usada para todos os hosts, como o seguinte:

vi ~/.ssh/config

Add both hostnames and their identity file as follows:

Host server1.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
  IdentityFile /backup/home/aymen/.ssh/id_rsa2

cliente:

vim /etc/ssh/ssh_config

#add your key 
IdentityFile ~/.ssh/yourkey

service sshd restart