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.