SSH: "El server rechazó nuestra key" sin ningún motivo

Estaba tratando de configurar un script de copy de security simple para que se ejecute automáticamente y que copie un file de una máquina de Windows a uno de Linux a través de SSH.

Como muchos tutoriales en línea simples sugieren que use pscp con una key privada generada con puttygen y coloqué la key pública correspondiente (presentada en forma de copyr / pegar por putty) en el file authorized_keys en Linux. Esto parece bastante sencillo teniendo en count que funcionó en otras 2 máquinas de Windows en una máquina Linux diferente, con la misma configuration.

No hay problemas de conectividad AFAICS y lo mismo ocurre con ssh, considerando que puedo iniciar session como root en la máquina Linux. El file de configuration ( sshd_config ) tiene AuthorizedKeysFile establecido en ~/.sshd/authorized_keys .

El error "El server rechazó nuestra key" sigue apareciendo, no importa lo que haga … Los loggings no muestran ningún problema de authentication …

Estoy planeando hacer más testings y establecer el valor de VERBOSE en VERBOSE o DEBUG2 o 3 pero considerando la urgencia del asunto y el hecho de que para probarlo en la máquina realmente tengo que pasar por un montón de problemas teniendo en count la la máquina está en un lugar bastante alejado de mi lugar de trabajo real …

Preguntas

  • ¿Alguien tiene alguna idea?
  • ¿Le ha pasado esto a alguien alguna vez?

Parece que esto podría ser un problema relacionado con las versiones ssh o algo por el estilo …

También estaba considerando la posibilidad de que necesite tener la key pública insertada en el file authorized_keys dentro del directory .ssh del usuario ( /user/.ssh/ ) además de tenerlo en la carpeta raíz (no tiene mucho sentido debido al valor de AuthorizedKeysFile en sshd_config ).

He hecho algunos teting con el set LogLevel del server ssh o VERBOSE pero no pude recuperar la información (problemas de responsabilidad), así que aquí va un logging de salida / debugging de otra fuente que parece mostrar el mismo error …

 Connection from 192.168.0.101 port 4288 debug1: Client protocol version 2.0; client software version OpenSSH_4.5 debug1: match: OpenSSH_4.5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.5 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user dcowsill service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "dcowsill" debug1: userauth-request for user dcowsill service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: test whether pkalg/pkblob are acceptable debug1: PAM: setting PAM_RHOST to "192.168.0.101" debug1: PAM: setting PAM_TTY to "ssh" debug1: temporarily_use_uid: 1052/105 (e=0/0) debug1: trying public key file /testuser/.ssh/authorized_keys debug1: restre_uid: 0/0 debug1: temporarily_use_uid: 1052/105 (e=0/0) debug1: trying public key file /testuser/.ssh/authorized_keys debug1: restre_uid: 0/0 Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2 debug1: userauth-request for user dcowsill service ssh-connection method publickey debug1: attempt 2 failures 2 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 1052/105 (e=0/0) debug1: trying public key file /testuser/.ssh/authorized_keys debug1: restre_uid: 0/0 debug1: temporarily_use_uid: 1052/105 (e=0/0) debug1: trying public key file /testuser/.ssh/authorized_keys debug1: restre_uid: 0/0 Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2 Connection closed by 192.168.0.101 

Parece que el progtwig está intentando abrir el file authorized_keys con permissions del propietario, pero luego no hay más información sobre lo que está generando el problema. Una última cosa, he comprobado y verificado dos veces el file y los permissions de Foler y están todos bien.

Algunas de las posibles razones que conozco están relacionadas con los permissions de files, en su mayoría son demasiado amplios y, en particular, puedo recordar dos razones

  1. exponiendo / inicio / directory de usuario a más que el propietario
  2. .ssh files .ssh y / o authorized_keys (configúrelos a 700/600 respectivamente si son más que eso)

el motivo exacto de la key se rechaza al iniciar un server sshd adicional en otro puerto con opciones de debugging y no de demonio si tiene acceso de administrador en el server que puede ejecutar:

 sudo `which sshd` -p 2020 -Dd 

en el server

Después de dejar esa ejecución ejecutar ssh a él:

 ssh -p 2020 -i /path/to/refusedkey 

La salida del server le dirá el motivo de la denegación

alguna testing obvia

  • formatting de authorized_keys ssh-rsa AA...long_line_of_char comment putty gen alguna vez da otra forma.

  • autorización:

    • ~ user / .ssh / authorized_keys es -rw-r – r–
    • ~ usuario / .ssh / es drwx ——
    • ~ el usuario no es escribible en todo el mundo.
  • La key se desplegaría id ~ root o in ~ user dependiendo del usuario al que se conecte.

algo less obvio:

  • root no puede ser ssh'd to. ( PermitRootLogin no o comentario)
  • location pnetworkingeterminada para authorized_keys AuthorizedKeysFile %h/.ssh/authorized_keys

    • es .ssh en el directory de inicio de ~ usuario.
  • ejemplo de location personalizada para authorized_keys AuthorizedKeysFile /foo/bar/authorized_keys.%h

    • es decir, keys, están ubicadas en /foo/bar dir.
    • en el file authorized_keys.root para root
    • en el file authorized_keys.user para el usuario, el file es propiedad de root

En mi caso lo he resuelto haciendo:

 chmod 700 myuserdir/.ssh chmod 600 myuserdir/.ssh/authorized_keys 

En el cuadro de Windows, en lugar de usar puttygen para generar la key privada de rsa, descargué cygwin de cygwin.org. Ofrece algunos packages por defecto. Modifiqué el package de networking para instalar OpenSSH. Esto ha instalado, entre otras cosas, el progtwig ssh-keygen. Entonces, corrí:

  • ssh-keygen -t rsa y dejó el código de acceso vacío
  • Esto creó la key privada llamada id_rsa en c:/cygwin/home/myusername/.ssh
  • Comencé Puttygen y seleccioné la opción de menu "Archivo -> Cargar key privada" y seleccioné tu id_rsa (no el público id_rsa.pub ).
  • Guárdelo en formatting de masilla haciendo clic en el button "Guardar key privada" (lo llamé putty.ppk)
  • Inicie masilla y select Conexión -> SSH -> Auth -> Clave privada para authentication. Ingrese el putty.ppk generado.
  • Ingrese su nombre de usuario en masilla: Conexión -> Datos -> Nombre de usuario de inicio de session automático

Ahora puedo conectarme sin ingresar usuario ni contraseña.

Correr:

 sudo `which sshd` -p 2020 -Dd 

como root en una session y en otra session ejecute:

 ssh -p 2020 -i /path/to/refusedkey refusedkeyusername@hostname 

Trabajé para que entendiera el motivo. Mis permissions de usuario no se establecieron en 700. Obtuve el o / p como se muestra a continuación

 debug1: trying public key file /home/userid/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK Authentication refused: **bad ownership** or modes for directory /home/sapadmin debug1: restre_uid: 0/0 Failed publickey for userid from 172.31.2.12 port 27382 ssh2: RSA Connection closed by 172.31.2.12 [preauth] 

¡De acuerdo! Una razón es que el directory de inicio del usuario del file de contraseña no es el directory desde el que desea copyr los files. ¡Solo root puede copyr desde cada ware, los otros usuarios no!

por ejemplo, si desea copyr del directory / backup, asegúrese de que el usuario que desea autenticar tenga el directory de inicio establecido en / backup (propiedad de él), para que scp encuentre la ruta corect a authorized_keys "/backup/.ssh/ authorized_key "

segundo: asegúrese de copyr al file authorized_keys exactamente el text de Putty Key Generator con "ssh-rsa AA …" en una sola línea. puede eliminar cualquier comentario como "rsa-key-xxx .." desde el final. ¡El file authorized_keys debe tener buena suerte para el usuario / grupo!

Desde el logging del server de debugging que compartió, parece que la key que ha especificado en el lado del cliente simplemente no coincide con ninguna de las disponibles en /testuser/.ssh/authorized_keys.

si /testuser/.ssh/authorized_keys es la location esperada, debe verificar que exista una línea de key pública que coincida con su key privada utilizada en el lado del cliente; es decir, si usa say, id_rsa en el cliente, marque id_rsa.pub junto a coincide exactamente con una de las líneas en /testuser/.ssh/authorized_keys.

Si tiene dudas sobre la location del file authorized_keys en el server, debe averiguar si especifica el nombre de usuario correcto en el lado del cliente.