☰

Authorized_keys tiene mi clave, pero aún así es rechazada

tag-icon • tag-icon ssh authentication public-key
Authorized_keys tiene mi clave, pero aún así es rechazada

Me estoy conectando desde la máquina M1 a la máquina M2 usando ssh (con el mismo usuario en la otra máquina). También debo mencionar que el usuario comparte la misma clave en ambas máquinas. Con la autenticación por contraseña, todo funciona bien; no ocurre lo mismo con la autenticación de clave pública; Me aseguré ~/.ssh/authorized_keysde que M2 tenga la clave RSA autorizada, pero aún así, ssh recurre a la autenticación de contraseña. Me sale lo siguiente con ssh -vvv:

debug2: key: /home/joeuser/.ssh/id_rsa (0x7f42679e8200),
debug2: key: /home/joeuser/.ssh/id_dsa ((nil)),
debug2: key: /home/joeuser/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/joeuser/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/joeuser/.ssh/id_dsa
debug3: no such identity: /home/joeuser/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/joeuser/.ssh/id_ecdsa
debug3: no such identity: /home/joeuser/.ssh/id_ecdsa: No such file or directory
debug2: we did not send a packet, disable method

Debo mencionar que yosoycapaz de conectarse mediante autenticación de clave pública desde otras máquinas (no con la misma clave).

¿Cuáles son las posibles razones por las que falla la autenticación basada en claves en este caso?

Nota: Ambas máquinas son SLES (SuSE Linux Enterprise Server) 11.

Respuesta1

Estabas haciendo lo correcto al usar ssh -vvvdesde el cliente, emparéjalo con un sshd en modo de depuración, así:

una segunda instancia de servidor: # /usr/sbin/sshd -p 1234 -dddd

un cliente dedicado para conectar: $ ssh -i .ssh/id_rsa-admuser admuser@server -p 1234 -vvvv

En mi caso resultó que la información crucial estaba impresa únicamente en el cliente. El servidor pasó

debug2: user_key_allowed: check options...
debug2: user_key_allowed: advance ...
debug2: key not found

mientras que al cliente se le ocurrió esto:

debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa-admuser RSA SHA256:<censored> explicit agent
debug1: send_pubkey_test: no mutual signature algorithm

Entonces, ¿qué estaba pasando aquí?

El servidor era tan antiguo que no podían negociar un algoritmo auxiliar; La clave también fuecon fecha de, pero en general bien.

¿Cuál sería el enfoque básico ahora?

  1. iniciar el servidor dedicado en un puerto diferente
  2. conectarse desde el cliente en una nueva sesión
  3. compare el intercambio de claves en ambos lados, paso a paso
  4. validar los hallazgos utilizando un segundo par de claves recién generado

En este ejemplo específico había una explicación clara de que se trataba de un método antiguo e inseguro que había quedado obsoleto, es decir, que se describe aquí. https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

Para poder actualizar esa caja antigua, podría conectarme agregándola -o PubkeyAcceptedKeyTypes=+ssh-rsaa la línea de comando ssh en el cliente.

Respuesta2

Consulta los conceptos básicos:

  1. id_rsa e id_rsa.pub existen tanto en M1 como en M2
  2. id_rsa tiene permiso 600 (es decir, solo el propietario puede leer y escribir) tanto en M1 como en M2
  3. El archivo Authorized_keys tiene la clave pegada como una sola línea (sin saltos de línea)
  4. El permiso de claves_autorizadas es 600
  5. Normalmente, el permiso en mi carpeta .ssh es 600 (predeterminado)
  6. Verifique el permiso de cada carpeta/home hasta .ssh
  7. Sé que quieres usar RSA, pero prueba la clave DSA y comprueba si funciona. Si es así, habremos puesto a cero la configuración SSH y RSA.

Respuesta3

El error que obtienes es

/home/joeuser/.ssh/id_dsa: No such file or directory

Asegúrese de que este archivo exista, contenga la clave privada que corresponde a la clave pública que agregó, pertenezca joeusery tenga 600permisos de usuario:

sudo chown joeuser /home/joeuser/.ssh/id_dsa
sudo chmod 600 /home/joeuser/.ssh/id_dsa

También deberías intentar definir explícitamente la clave privada de esta manera:

ssh -i ~/.ssh/id_rsa [email protected]

Si no está seguro de si esta es la clave correcta, le recomiendo crear un nuevo par de claves RSA.

ssh-keygen -b 4096

y agregue el contenido de la clave pública ~/.ssh/id_rsa.pubal archivo autorizado_keys del servidor remoto. ¡Asegúrese de no sobrescribir una clave privada existente que aún necesita para iniciar sesión en otros servidores!

información relacionada