4

I tried to clone a git repository after a migration from centos to fedora 33, then I got this error:

git clone [email protected]:abc/myproject.git
Cloning into 'myproject'...
sign_and_send_pubkey: no mutual signature supported
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I have checked permissions, the keys, even created new keys and still error remains.

2 Answers 2

Reset to default
8

After googling a while, I found the answer in other related error: SSH keeps skipping my pubkey and asking for a password

The new openssh version (7.0+) deprecated DSA keys and is not using DSA keys by default (not on server or client). The keys are not preferred to be used anymore, so if you can, I would recommend to use RSA keys where possible.

If you really need to use DSA keys, you need to explicitly allow them in your client config using

PubkeyAcceptedKeyTypes +ssh-dss

Should be enough to put that line in ~/.ssh/config, as the verbose message is trying to tell you.

thanks Jackuje

addendum: It is possible to adding this line in /etc/ssh/ssh_config but at very end, after Include, and still works too.

2
  • yes. it worked right away for me. I had to touch a config file inside .ssh folder and then add that line inside it. After trying the connection again it worked fine.
    – GrigoreasP
    Jun 14, 2021 at 11:32
  • Thanks for the straight forward answer. I just had to do the following: echo "PubkeyAcceptedKeyTypes +ssh-dss" >> /etc/ssh/ssh_config As apolinux said the verbose output of the command -vvv will show which ssh config file you are using. In otherwords, your config file may not be at the same location as mine /etc/ssh/ssh_config, change it accordingly.
    – Copy and Paste
    Sep 27, 2022 at 23:32
2

It looks like you're using a DSA SSH key, and modern versions of OpenSSH don't support those by default because they're insecure. Here's why:

  • DSA keys, as used in OpenSSH, are limited to 1024 bits. For the kind of algorithm they are, this is equivalent to an 80-bit level of security, whereas the lowest acceptable level of security these days is 128 bits.
  • DSA keys can only use the insecure SHA-1 algorithm for signing. SHA-1 is known to be very weak and provide only 61 bits of security, so it should not be used any longer. It is so weak that any reasonably well-paid software developer can afford to attack SHA-1.

Your best bet is to generate a new key using something like the following:

$ ssh-keygen -t ed25519

Ed25519 keys are considered the best option these days and are recommended by Mozilla for all developers. It is possible to use RSA keys as well, but they should be at least 3072 bits in size and you must configure them not to use SHA-1 either by adding PubkeyAcceptedTypes -ssh-rsa. Unless you are sure you know what you're doing or you have a compelling need otherwise, Ed25519 keys are the best option.

Note that Bitbucket does not offer any secure host key algorithms on their side (only SHA-1-based algorithms), so you're probably better off using HTTPS if you're using Bitbucket.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .