Updated to openssh (8.8p1-1) and git didn't get the keys anymore.
Couldn't pull or push. After reverting back to 8.7p1-2 it works as
intended.
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
Updated system packages (openssh)
What did you expect to happen? (Expected behavior)
Can git pull without issues
What happened instead? (Actual behavior)
Permission Denied due to key error
What's different between what you expected and what actually happened?
I couldn't push pull whatever because the keys haven't been recognized somehow
Anything else you want to add:
I reverted from openssh 8.8p1-1 to 8.7p1-2 to make it work again
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version 2.33.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.14.8-arch1-1 #1 SMP PREEMPT Sun, 26 Sep 2021 19:36:15
+0000 x86_64
compiler info: gnuc: 11.1
libc info: glibc: 2.33
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
On Mon, Sep 27, 2021 at 11:40 PM Kevin Kendzia
[off-list ref] wrote:
Updated to openssh (8.8p1-1) and git didn't get the keys anymore.
Couldn't pull or push. After reverting back to 8.7p1-2 it works as
intended.
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
Updated system packages (openssh)
What did you expect to happen? (Expected behavior)
Can git pull without issues
What happened instead? (Actual behavior)
Permission Denied due to key error
What's different between what you expected and what actually happened?
I couldn't push pull whatever because the keys haven't been recognized somehow
Anything else you want to add:
I reverted from openssh 8.8p1-1 to 8.7p1-2 to make it work again
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
Ultimately this isn't a Git issue; it's an SSH issue. My guess would
be that upgrading to OpenSSH 8.8 picks up the change to stop using RSA
signatures using SHA-1 hashes by default.[1]
You can update your ~/.ssh/config to add these lines to revert that
and allow using those keys again:
Host old-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
With that said, though, if possible a better solution is to generate
new SSH keys using ECDSA, Ed25519 or another stronger signature and
switch to those.
Hope this helps!
Bryan
[1] https://www.openssh.com/releasenotes.html
Something like `ssh -vvv user@host` would probably be useful to see
where the key negotiation breaks for you, but it is unlikely to be a
problem with git.
My guess is that your host key is still using RSA with SHA1 and you
haven't updated it by following the instructions[1] OpenSSH provided
with their 8.3 release
Carlo
PS. I upgraded to OpenSSH 8.8p1 and had no problems connecting, but I
am not on Arch, so that might be another possibility
[1] https://lwn.net/Articles/821544/
On 28/09/21 13.40, Kevin Kendzia wrote:
Updated to openssh (8.8p1-1) and git didn't get the keys anymore.
Couldn't pull or push. After reverting back to 8.7p1-2 it works as
intended.
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
Updated system packages (openssh)
What did you expect to happen? (Expected behavior)
Can git pull without issues
What happened instead? (Actual behavior)
Permission Denied due to key error
What's different between what you expected and what actually happened?
I couldn't push pull whatever because the keys haven't been recognized somehow
Anything else you want to add:
I reverted from openssh 8.8p1-1 to 8.7p1-2 to make it work again
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version 2.33.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.14.8-arch1-1 #1 SMP PREEMPT Sun, 26 Sep 2021 19:36:15
+0000 x86_64
compiler info: gnuc: 11.1
libc info: glibc: 2.33
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
What remote you tried to push or pull from? What key do you use? If
you're connecting to GitHub, see [1].
[1]: https://github.blog/2021-09-01-improving-git-protocol-security-github/
--
An old man doll... just what I always wanted! - Clara
On 2021-09-28 at 07:32:05, Bryan Turner wrote:
Ultimately this isn't a Git issue; it's an SSH issue. My guess would
be that upgrading to OpenSSH 8.8 picks up the change to stop using RSA
signatures using SHA-1 hashes by default.[1]
You can update your ~/.ssh/config to add these lines to revert that
and allow using those keys again:
Host old-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
I should point out that these algorithms are disabled by default because
they are a security risk. This has been announced for a long time now
in OpenSSH and everyone should have either switched key types or enabled
RSA with SHA-2 or both.
With that said, though, if possible a better solution is to generate
new SSH keys using ECDSA, Ed25519 or another stronger signature and
switch to those.
You also need to contact the party operating the server to which you're
trying to push in this case, since it's ultimately the fact that they
don't support RSA with SHA-2 that's the problem.
There are a couple different providers (in my testing just this second,
I found Bitbucket and Azure DevOps) who are still offering only the
ssh-rsa host keys (possibly with ssh-dss as well) and not offering the
rsa-sha2-256 and rsa-sha2-512 algorithms, and only the server operator
can fix those. If the server operator adds support for RSA with SHA-2,
then OpenSSH 8.8 will work just fine. But otherwise, this will continue
to be broken out of the box.
But as for client keys, I do strongly recommend Ed25519 in all cases.
If you have the misfortune of having to use a FIPS-compliant environment
(which I don't recommend in any case), then use RSA with SHA-2.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA