Menu
i have been trying many answers on this Stackoverlow questions same like i am asking now, but still can't resolve my problem, i am trying to clone by ssh but always got Permission denied (publickey)
when i run GIT_SSH_COMMAND="ssh -vvv" git clone [email protected]:myusername/my-api.git
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: [email protected] need=64 dh_need=64
debug1: kex: [email protected] 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.
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.
after i upgrade Fedora 33, i got this issue, it was no issue on Fedora 32
685
If you want to use a password to access the SSH server, a solution for fixing the Permission denied error is to enable password login in the sshd_config file. In the file, find the PasswordAuthentication line and make sure it ends with yes . Find the ChallengeResponseAuthentication option and disable it by adding no .
Short description. "Permission denied (publickey)" and "Authentication failed, permission denied" errors occur if: You're trying to connect using the wrong user name for your AMI. The file permissions within the operating system are incorrect on the instance.
Permission denied > (publickey,keyboard-interactive). This should be moved to serverfault. The SOLUTION in my case: Remove spaces around comma separators and everything will work fine. I was trying to get a command="... entry in authorized_keys to work.
To generate an SSH private/public key pair for your use, you can use the ssh-keygen command-line utility. You can run the ssh-keygen command from the command line to generate an SSH private/public key pair. If you are using Windows, by default you may not have access to the ssh-keygen command.
This could be related to "Changes/StrongCryptoSettings2 in Fedora33"
The changes for default policy are:
- Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols and move the TLS 1.x, x<=1 to legacy level.
- Require finite field parameters (RSA, Diffie-Hellman) of 2048 and more in the default settings
- Disable SHA1 support for use in signatures (X.509 certificates, TLS, IPSEC handshakes)
The "Upgrade/compatibility impact" section of the aforementioned link clearly mentions:
It may be that the new settings break software that connects to servers which utilize weak algorithms.
Compatibility can be obtained by switching the system to Fedora 32 policy level:update-crypto-policies --set DEFAULT:FEDORA32
NOT RECOMMENDED though: if you can use an ed25519, this is better.
As mentioned in Peque's answer, you can add on your ~/.ssh/config an option initially found in sshd_config
PubkeyAcceptedKeyTypes
Specifies the key types that will be accepted for public key
authentication as a list of comma-separated patterns.
So if you cannot use ed25519, you can, for one specific host, allow the use of id_rsa keys with:
Host aHost
Hostname a.hostname.com
PubkeyAcceptedKeyTypes +ssh-rsa
Finally: Double-check your permissions after upgrade:
~/.ssh is 775 drwxrwxr-x.~/.ssh/id_rsa is 600 -rw-------.~/.ssh/id_rsa.pub is 644 -rw-r--r--.~/.ssh/config is 600 -rw-------.~/.ssh/authorized_keys on remote server is 600 -rw-------
But using ssh-keygen -t ed25519 keys seems to be recommended now.
124
@VonC Is correct, I upgraded to fedora 33 and ran into this permission issue.
running the following command fixed it :
update-crypto-policies --set DEFAULT:FEDORA32
Thank you for sharing that article
12
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
