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

33

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
Danny
fuente
2
por favor dénos la salida dels -la /root/.ssh/
mreithub
@mreithub Gracias por la rápida respuesta, agregada anteriormente.
Danny
3
intente eliminar el _tm1su nombre de archivo clave (es decir, mv id_rsa_tm1 id_rsae mv id_rsa_tm1.pub id_rsa.pub)
mreithub
@mreithub ¡Eso funcionó! Muchas gracias, sin embargo, no entiendo por qué no puedo agregar otras cadenas al nombre del archivo. Lo hago en mi iMac para conectarme a los servidores sin ningún problema ... es decir, puedo usar id_rsa.tm1.imac.pub sin ningún problema. ¿Y si quisiera varias claves?
Danny

Respuestas:

22

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.

michas
fuente
26

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).
jah
fuente
2
gracias, cada vez que recibo este error es porque mi archivo autorizado de claves en el host remoto (servidor) está mal formado. Desearía que el error no pareciera que hubiera un problema con el cliente.
tamal
3
¡Pegar en vim sin presionar 'i' primero!
Jordan Davidson
Para mí no parecía mal formado, pero eliminé el archivo y desde la máquina de origen hice el ssh-copy-id nuevamente para recrearlo. Problema resuelto.
alvarez
14

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.

Caleb
fuente
¡Guauu! ¡Este también mató bastante tiempo para mí! Perdí un poco de cabello! Entonces, en mi caso, también fue esto, solo mi clave de publicación estaba en el archivo autorizado de claves del lado del cliente, excepto que incluía una entrada de nombre @ host al final, donde mi host sshd no. No me di cuenta de que necesita hacer coincidir las teclas autorizadas en cada extremo, de hecho, no creo que las haya igualado antes. Esto fue un problema solo cuando mi cliente era CentOS 7, conectándose a Ubuntu 12.04. Ir desde MacOS u otros sistemas Ubuntu funcionó bien.
gregthegeek
Entonces, ¿cómo se soluciona este problema? Usted ha descrito mi problema a una T. Mi problema se exacerba aún más porque estoy saltando entre varios sistemas. En realidad, especificar que el archivo no funciona para mí
Madivad
@Madivad Soluciona el problema haciendo coincidir las claves públicas / privadas localmente (o sin ninguna clave pública).
Caleb
@Caleb Eso suena más simple de lo que es a menos que (y creo que se ha caído el centavo) esto significa que debería copiar las claves públicas y privadas a cada sistema que quiero usar como cliente SSH. He intentado crear un IdentityFile, pero obviamente lo estoy usando mal
Madivad
Eliminar el archivo huérfano id_rsa.pub en el cliente me resolvió esto. Me encontré con este problema una vez más en un nuevo cliente Centos 7 que se conecta al servidor Ubuntu 12.04. El problema del nombre de host @keys_keys autorizado no lo solucionaba Emparejé directorios, permisos, exactamente el mismo archivo de clave id_rsa, pero había un id_rsa.pub adicional (en el lado del cliente). Eliminado, ahora funciona. Ejecuté ssh-keygen para crear directorios rápidamente, luego rsync desde un buen sistema conocido. Pero eso dejó un archivo pub adicional que no coincide con ninguna clave privada (no estaba en rsync de origen). Volví a agregar un archivo pub no coincidente para verificar. Asegúrese de que coincida o elimine.
gregthegeek
5

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.

mreithub
fuente
4

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.

skywalkie
fuente
44
Bienvenido al sitio U + L Stack Exchange. Puede hacer que su respuesta sea más útil para los demás al proporcionar un ejemplo de cómo deberían ser los permisos correctos.
Erathiel
Tuve un problema muy similar, excepto con ~/.sshdir. Al menos en Fedora 28 cuando los ~/.sshpermisos eran 0775, no pude conectarme con claves públicas / privadas. Así que cambié los permisos a 0755 y trabajé como un encanto :)
PovilasB
3

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.

Dimitrios
fuente
¡Muchas gracias, hombre! ¡Salvaste mi día!
Anthony
Eso ayudó a aclararlo. El mío decía que el usuario suchandsuch de 123.123.123.123 no está permitido porque no aparece en AllowUsers . Muchas gracias!
aexl
2

Tratar

/sbin/restorecon -r /root/.ssh

Un posible problema con el contexto de venta

Abdel Karim Mateos Sanchez
fuente
Estoy en Ubuntu y no existe tal binario.
Sridhar Sarnobat
0

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

mennanov
fuente
0

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 [email protected]. 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
Aymen Alsaadi
fuente
-2

cliente:

vim /etc/ssh/ssh_config

#add your key 
IdentityFile ~/.ssh/yourkey

service sshd restart
李孝奎
fuente