Project

General

Profile

Bug #2440

SSH public key auth broken with Fedora 34

Added by bigfoot65 6 months ago. Updated 3 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
10/31/2020
Due date:
% Done:

0%


Description

New crypto settings in Fedora 33 breaks current public key authentication:

https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2

The proposed fix for now is:

sudo update-crypto-policies --set LEGACY

History

#1 Updated by cpg 6 months ago

  • Status changed from New to Feedback

I re-entered my public key and all worked well as it did before after an upgrade. Also, before re-entering my public key it also worked.

That said, my HDA is an F33 system that comes from a string of OS upgrades, so it's not a clean install.

We'd have to test with a clean install. I do suspect that it may not affect us much.

For one thing, it's mostly about connecting to "legacy (TLS1.0, TLS1.1) servers" which we do not directly support. Users can add a cert, etc., but it may just mean that newer stacks are requires and most browsers have them, so it may not impact a lot.

The other thing is ssh access. In general, we have been using newer or more advanced "curves" for sshd in the Amahi servers that provide online services for Amahi users and it has not been a real problem.

That said, we have to check on a clean install, especially if we want to support Let's Encrypt certs, which, now that they support wildcard certs, is much easier than a little while ago.

#2 Updated by bigfoot65 12 days ago

  • Subject changed from SSH public key auth broken with Fedora 33 to SSH public key auth broken with Fedora 34

This appears to still be a problem in Fedora 34.

#3 Updated by cpg 12 days ago

  • Status changed from Feedback to Assigned
  • Assignee set to bigfoot65

This appears to still be a problem in Fedora 34.

Do you know for sure?

I have been using a clean F34 VM and it seems to be doing ok with the default settings I have been using for a while.

#4 Updated by bigfoot65 12 days ago

  • Assignee changed from bigfoot65 to cpg

I received your key is refused error message. Once I installed the fix, it worked fine.

Not sure if it’s related to how my private key was created. I followed the wiki guidance for creating it.

https://wiki.amahi.org/index.php/Key-Based_SSH_Logins

Fedora 33 & 34 are the only systems that I had this issue.

#5 Updated by cpg 12 days ago

  • Assignee changed from cpg to bigfoot65

Yes, it could be that the method to generate the key is old. 1024 bits for the key may be considered obsolete perhaps.

In f34, this is the way

 ssh-keygen -t rsa

though the default is RSA (so the -t and the option are redundant) and they generate 3072 bit key pairs.

If you can try it against an unpatched system (or a clean one), maybe that works.

I am not sure putty has been updated for this. Maybe we could offer to create and set up all this in our user module, to help users. That would be cool.

#6 Updated by bigfoot65 11 days ago

  • Assignee changed from bigfoot65 to cpg

I think it's the SSH Client (Putty) that is the issue. I regenerated public/private key and still did not work. Then I tried Bitvise SSH Client and it works fine with it.

Not sure the cause, but it appears to be isolated to the client being used. I will have to try a linux client to see if it works for me.

#7 Updated by bigfoot65 11 days ago

So I tried it from my HDA command line. Didn't work until I save the Private Key as new format in Putty. Now it works from the HDA.

The new format however does not work from Putty. It also breaks the authentication for all my other servers with Putty.

So, Putty can't connect to Fedora 34 using a Private Key unless we change the Authentication from default to LEGACY. Really odd behavior and no simple solution other than using a Linux CLI client or Bitvise.

#8 Updated by cpg 11 days ago

  • Assignee changed from cpg to bigfoot65

You did not say if you tried longer keys in Putty. Did you do that?

Also, is there a newer version of Putty perhaps that support these new curves? (though RSA is quite the standard, I think)

#9 Updated by bigfoot65 11 days ago

  • Assignee changed from bigfoot65 to cpg

I did try the longer keys with no luck. I am using the latest version of Putty as well.

This is just an odd one.

#10 Updated by bigfoot65 3 days ago

  • Status changed from Assigned to Closed
  • Assignee changed from cpg to bigfoot65

PuTTY released a new version and this issue now appears corrected. Also Bitvise works well too. Will close this bug as it's resolved.

#11 Updated by cpg 3 days ago

Coool. I felt that within the context of Linux and Mac OS, where I usually operate from, it was working well, so perhaps it was a matter of default length of the key and type of curve used. Good going.

Also available in: Atom