Permiso ssh denegado (clave pública) después de actualizar Fedora 33

3 minutos de lectura

avatar de usuario
Bolsillo

He estado intentando muchas respuestas a estas preguntas de Stackoverlow, igual que estoy preguntando ahora, pero aún no puedo resolver mi problema, estoy tratando de clonar por ssh pero siempre tengo Permission denied (publickey)

cuando corro GIT_SSH_COMMAND="ssh -vvv" git clone git@bitbucket.org:myusername/my-api.git

debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ssh-rsa SHA256:kkXQOXSRBEiUtuE8AikLLLwbHaxvSc0ojez9YXaGp2A
debug3: hostkeys_foreach: reading file "/home/alienwarepocket/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/alienwarepocket/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from bitbucket.org
debug3: hostkeys_foreach: reading file "/home/alienwarepocket/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/alienwarepocket/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 18.205.93.2
debug1: Host 'bitbucket.org' is known and matches the RSA host key.
debug1: Found key in /home/alienwarepocket/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/alienwarepocket/.ssh/id_rsa RSA SHA256:ktMzaalYyvU9Ev1bgELXatabkUkdcT828O0PppnNiV4M explicit agent
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-with-mic,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 public key: /home/alienwarepocket/.ssh/id_rsa RSA SHA256:ktMzaalYyvU9Ev1bgELXatabkUkdcT828O0PppnNiV4M explicit agent
debug1: send_pubkey_test: no mutual signature algorithm
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
git@bitbucket.org: Permission denied (publickey).
fatal: Could not read from remote repository.

después de actualizar Fedora 33, tuve este problema, no fue un problema en Fedora 32

  • Supongo que debido a la nueva instalación, su clave pública ha cambiado. ¿Puedes intentar clonar a través de https?

    – Tranquilo

    2 de noviembre de 2020 a las 8:20

  • ese es un error de Fedora 33, lo encontré en Reddit, alguien preguntó el mismo tipo de error @Peaceful

    – Bolsillo

    2 de noviembre de 2020 a las 9:31


  • No es un error: Fedora 33 ahora está firmemente en contra de la criptografía débil.

    – Jetski tipo S

    19 de noviembre de 2020 a las 2:55

  • Habías aceptado la respuesta correcta antes.

    – VoC

    26 de noviembre de 2020 a las 8:20

  • He editado mi respuesta para incluir el update-crypto-policies --set DEFAULT:FEDORA32 comando (que era parte del enlace que mencioné originalmente)

    – VoC

    26 de noviembre de 2020 a las 10:27


avatar de usuario
VonC

Esto podría estar relacionado con “Cambios/StrongCryptoSettings2 en Fedora33

Los cambios para la política predeterminada son:

  • Mantenga solo TLS 1.2 (y TLS 1.3 cuando esté disponible) como protocolos habilitados y mueva TLS 1.x, x<=1 al nivel heredado.
  • Requerir parámetros de campo finito (RSA, Diffie-Hellman) de 2048 y más en la configuración predeterminada
  • Deshabilite la compatibilidad con SHA1 para su uso en firmas (certificados X.509, TLS, protocolos de enlace IPSEC)

Los “Impacto de actualización/compatibilidadLa sección del mencionado enlace menciona claramente:

Puede ser que la nueva configuración rompa el software que se conecta a servidores que utilizan algoritmos débiles.
La compatibilidad se puede obtener cambiando el sistema al nivel de política de Fedora 32:

update-crypto-policies --set DEFAULT:FEDORA32

NO RECOMENDADO aunque: si puede usar un ed25519, esto es mejor.

Como se menciona en la respuesta de Peque, puede agregar en su ~/.ssh/config una opción inicialmente encontrada in sshd_config

 PubkeyAcceptedKeyTypes
         Specifies the key types that will be accepted for public key
         authentication as a list of comma-separated patterns.

Entonces, si no puede usar ed25519, puede, para un host específico, permitir el uso de id_rsa llaves con:

Host aHost
    Hostname a.hostname.com
    PubkeyAcceptedKeyTypes +ssh-rsa

Finalmente: Vuelva a verificar sus permisos después de la actualización:

  • ~/.ssh es 775 drwxrwxr-x.
  • ~/.ssh/id_rsa es 600 -rw-------.
  • ~/.ssh/id_rsa.pub es 644 -rw-r--r--.
  • ~/.ssh/config es 600 -rw-------.
  • ~/.ssh/authorized_keys en el servidor remoto es 600 -rw-------

pero usando ssh-keygen -t ed25519 llaves parece ser recomendado ahora.

  • para configurar por defecto como fedora anterior, eso no se recomienda porque lo nuevo en fedora 33 es más seguro,

    – Bolsillo

    26 de noviembre de 2020 a las 10:29

  • @Pocket Sí, acabo de editar la respuesta para indicar claramente que no se recomienda.

    – VoC

    26 de noviembre de 2020 a las 10:30


  • Regenerar una clave con ssh-keygen -t ed25519 arreglé mi problema con bitbucket.org.

    – Crujido

    1 de diciembre de 2020 a las 4:44


  • ¡Gracias por la solución! Agregue a la descripción que los permisos de ~/.ssh/config deben ser 600

    – Alexander Arutinyants

    15 de febrero de 2021 a las 9:01

  • @AlexanderArutinyants Buen punto. He editado la respuesta en consecuencia.

    – VoC

    15 de febrero de 2021 a las 9:02

@VonC Es correcto, actualicé a fedora 33 y me encontré con este problema de permisos.

ejecutando el siguiente comando lo arregló:

update-crypto-policies --set DEFAULT:FEDORA32

Gracias por compartir ese artículo.

  • Actualicé a Fedora 33 y encontré el mismo problema. Esta solución me funcionó al usar un repositorio en bitbucket

    – hormiga2009

    5 de noviembre de 2020 a las 15:50

  • Esta solución, en Fedora 33, funcionó para mí usando el repositorio en gitlab

    –Bruno Morais

    16 de noviembre de 2020 a las 18:26

  • Para ser claros, esta solución dice “Estoy de acuerdo con usar criptografía débil”, mientras que la solución de VonC soluciona el problema de raíz y usa criptografía fuerte para hacer feliz a Fedora 33.

    – Jetski tipo S

    19 de noviembre de 2020 a las 2:53

  • Es mucho mejor usar PubkeyAcceptedKeyTypes=+ssh-rsa para los servidores que necesita, en lugar de cambiar globalmente la política. Esto es de stackoverflow.com/a/65007312/520567

    – akostadinov

    30 de noviembre de 2020 a las 16:37

En lugar de cambiar globalmente las políticas criptográficas, es mejor degradar la seguridad por host.

Puede actualizar la configuración para el host heredado específico en su .ssh/config archivo agregando:

Host legacy.host
    PubkeyAcceptedKeyTypes +ssh-rsa

Para más detalles, echa un vistazo a este discusión en Bugzilla.

  • Seguí el enlace, gracias por eso, y tenía PubkeyAcceptedKeyTypes ssh-rsa – tan ligeramente diferente, pero funcionó para mí en Fedora 34.

    – colin0117

    26 mayo 2021 a las 17:59

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad