Fedora Account System
Red Hat Associate
Red Hat Customer
What were you trying to do that didn't work? I wanted to create SSHFP record after reading https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ But even latest RHEL version makes omitting SHA1 difficult. I can use -O hashalg=sha256, but why should I have? Isn't SHA1 known to be too weak to provide attestation for keys, especially those of ssh-ed25519 algorithm? ssh-keyscan has the same problem. Are there still cases, when I would like to produce records with SHA1 fingerprint? This contrasts with default crypto policy even forbidding SHA1 digest signature verification we have already since RHEL9. What is the impact of this issue to you? It creates records I need actively modify to make them more secure. I am not blocked on this, but it should be modified to provide secure records by defalt. Please provide the package NVR for which the bug is seen: openssh-9.9p1-4.el10.1.x86_64 Reproducible: Always Steps to Reproduce: 1. ssh-keygen (generate most secure algorithm key) 2. ssh-keygen -r localhost -f ~/.ssh/id_ed25519.pub 3. ssh-keyscan -D localhost has similar problem Actual Results: Actual results me.localhost IN SSHFP 4 1 87e51de1fb04caff47243792534981c05b4ddbcb me.localhost IN SSHFP 4 2 0feb1aa0e1458368c3634dfe3aafc0ba84267475265f263fefd1be440d7e46ea Expected Results: Just secure digest records are generated. Untrusted SHA1 might be provided when requested explicitly via -O hashalg=sha1, but not always. I would expect just: me.localhost IN SSHFP 4 2 0feb1aa0e1458368c3634dfe3aafc0ba84267475265f263fefd1be440d7e46ea
Tested also latest rawhide openssh, the result is the same. # rpm -q openssh openssh-9.9p1-5.fc42.x86_64 # ssh-keygen -r localhost -f ~/.ssh/id_ed25519.pub localhost IN SSHFP 4 1 07e4f58e19017e2fb22de493d2f3f94ee83a8bbf localhost IN SSHFP 4 2 e8469f680492463a87b432a72720ecc111f5e976db0c67d08c899642bccb9126
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
Don't consider it to be a problem, speaking frankly.
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key command will print only SHA256 digest. ssh-keygen -r localhost -f /etc/ssh/ssh_host_ed25519_key command generates also SHA1 digests. These are used on some signed zones and for example fedora distgit has those SHA1 digests generated also. Using SHA1 should be discouraged for any security usage. I know you are not in favor of DNSSEC, but some people are using it. Default should be only trusted digests, just like for key fingerprints.
This message is a reminder that Fedora Linux 42 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '42'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 42 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27. Fedora Linux 42 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.