La clave pública SSH no se enviará al servidor

He estado luchando con esto durante un par de horas, por lo que cualquier ayuda es muy apreciada ...

Tengo 2 servidores que puedo usar sshcon claves públicas de OSX, no hay problemas, así que estoy seguro de que todo está bien sshd_config.

Estoy tratando de configurar un trabajo cron para rsyncsincronizar los dos servidores y necesito el servidor B (copia de seguridad) sshen el servidor A usando una clave pública.

Por mi vida no puedo entender por qué no encuentra mis claves públicas: están en ~/.ssh/(es decir /root/.ssh) y todos los permisos de archivo son correctos en A y B.

Esta es la salida:

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

También tenga en cuenta que está buscando claves privadas que no existen ...

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

Echa un vistazo a tu página de manual de 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).

o la página del comando man 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.

Verá, hay algunos nombres de archivo especiales que se prueban si no especifica una clave. Esos también son los archivos que ve en su salida de registro.

Para usar una clave en un archivo con un nombre diferente, tiene tres opciones:

• especifique el archivo explícitamente usando la -iopción anterior .
• configure el archivo en la configuración de su cliente utilizando la IdentityFileopción anterior .
• agregue la clave a su agente usando ssh-add.

Para sesiones interactivas, el agente es el más flexible. Para su trabajo cron, la -iopción es probablemente la más fácil.

Un archivo de claves autorizadas con formato incorrecto en el host de destino es otra razón por la que ssh genera el mensaje "no enviamos un paquete" y solicita una contraseña en lugar de utilizar la autenticación de clave pública:

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

El problema en este caso particular era que los datos de clave pública, que se habían pegado en .ssh/authorized_keysel host de destino, faltaban su primer carácter:

sh-rsa AAAA...

La solución fue simplemente agregar la "s" que faltaba.

ssh-rsa AAAA...

Y entonces:-

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

Esta cadena exacta de mensajes de error en la pregunta también puede ocurrir en el caso de un par de claves privadas / públicas mal coincidentes en el lado local . No, eso no tiene ningún sentido, pero me arranqué el pelo durante mucho tiempo tratando de descubrir qué estaba pasando.

• El sistema remoto A se ha .ssh/mykey.pubcopiado .ssh/authorized_keys.
• El sistema local B tiene .ssh/mykeyla clave privada correcta para que coincida con la clave pública del sistema A, pero también tiene un .ssh/mykey.pubarchivo que es una coincidencia incorrecta , posiblemente la versión anterior de una clave reemplazada.

SSH de B a A ( ssh -i mykey A) fallará con los mensajes en la pregunta, sobre todo si enciende -vvdesde el cliente ssh verá:

Intentando con la clave privada: .ssh / mykey
no enviamos un paquete, deshabilite el método

Esto es una mentira porque la clave real no se probó, aparentemente utilizó el archivo de clave pública local con el nombre correspondiente para determinar si era probable que funcionara y luego no hizo nada cuando no coincidían. Ninguna cantidad de información de depuración en ambos lados realmente sugiere el problema.

Los nombres de archivo predeterminados que ssh está buscando son id_rsay id_rsa.pub.

Si desea utilizar otros nombres de archivo, debe especificarlos en ssh_config(usando la IdentityFileconfiguración) o mediante el parámetro de línea de comando ssh -i.

Tuve el mismo problema en RedHat; revisó los registros y descubrió que el directorio de inicio tenía derechos de usuario incorrectos.

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

La fijación de los derechos de directorio de inicio resolvió esto.

Una forma sencilla de depurar en Debian / Ubuntu es: conectarse con contraseña y seguir el registro

tail -f /var/log/auth.log

Intente conectarse desde otro terminal y verá el error ...

En mi caso, el directorio / root era 770 y no 700, que es el valor predeterminado. El error fue "Autenticación rechazada: propiedad o modos incorrectos para el directorio / root"

Arregla esto y listo.

Tratar

/sbin/restorecon -r /root/.ssh

Un posible problema con el contexto de venta

despues de correr

ssh-copy-id user@remote-host

Normalmente debería funcionar. Pero si falla, intente esto: inicie sesión en el host remoto como el usuario que desea iniciar sesión en el futuro y ejecute:

ssh-keygen

Me ayudó.

Entonces, lo que me sucedió es que tengo 2 máquinas virtuales para acceder desde mi máquina local (2 claves id_rsa.pub e id_rsa2.pub). Me di cuenta de que mi conexión ssh está usando id_rsa.pub por defecto para cualquier conexión ssh user@xx.xx.xx.xx. Resolví mi problema agregando un archivo de configuración y especifico la identidad que se utilizará para cada host de la siguiente manera:

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