On 11/03/2021 23:06, Kevin Fenzi wrote: > On Thu, Mar 11, 2021 at 03:50:57PM +0100, Daniel Pocock wrote: >> >> >> On 11/03/2021 12:13, Florian Weimer wrote: >>> * Richard W. M. Jones: >>> >>>> I really hope we don't remove the ability to connect to old servers >>>> (eg. running RHEL 5). At the moment you have to opt-in by setting the >>>> crypto-policy to LEGACY and running update-crypto-policies(8), which >>>> is bearable. >>> >>> In the past (long, long ago), I had to enable Telnet on target devices >>> to work around incompatible cryptography policies. I hope we are not >>> going to return to that. >> >> Giving people an option to use broken crypto on-demand may appear >> reasonable at first glance. In practice, there are sites where people >> turn it on to meet a deadline or end a service outage and then they >> never go back to remove it. > > Yeah. ;( > However, a command line version might be ok... at least then it's pretty > clear what you are doing and you want it to go away so you don't have to > type as much. :) > >> Nonetheless, all I'm really looking at in this thread is to parse what >> the OpenSSH releases say into specific advice for current and recent >> Fedora releases. > > I think we will need to wait for the openssh maintainers here. > Ultimately it's their call how much we diverge from upstream, but I > suspect the answer will be 'as little as possible'. :) One piece of advice that we could put on a wiki about OpenSSH: recommending that people familiarize themselves with the Fedora security announcements, etc https://fedoraproject.org/wiki/SecurityBasics#Subscribing_to_Security_Announcement_Services This always makes sense for any distribution. Based on the thread here and on the other list, I think it is safe to put some basic facts on a wiki page too: - the values stored on disk are only keys and not hashes. Therefore, only the minimum key size (e.g. RSA 2048) is a concern for existing keys on disk. The hash issues are not a concern for the values in known_hosts. - SHA1 in Key exchange is not the same as HMAC-SHA1 message authentication. The former is a concern, the latter is not. People don't need to change MACs - people who want to remove SHA1 on their server need to change KexAlgorithms in /etc/ssh/sshd_config (??) and be aware that legacy clients will no longer connect - people who want to disable SHA1 from their client can do so in ~/.config/ssh or /etc/ssh/ssh_config as they prefer, modifying KexAlgorithms (??) and be aware that they can no longer connect to really old servers and appliances, unless they workaround (next point) - people who want to enable SHA1 for a single client connection attempt can do so on the command line (example) - Fedora (34? 35?) will have OpenSSH with "UpdateHostKeys yes" by default - people on any older Fedora who want to proactively update the known_hosts entries on their clients can do so in ~/.config/ssh or /etc/ssh/ssh_config as they prefer - maybe a sample script to poll all the servers in known_hosts - sample ssh client command with debug output _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
