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

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

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.

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

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.