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

How reproducible is this bug?:

reliable

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

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:

localhost IN SSHFP 4 2 0feb1aa0e1458368c3634dfe3aafc0ba84267475265f263fefd1be440d7e46ea

Actual results

localhost IN SSHFP 4 1 87e51de1fb04caff47243792534981c05b4ddbcb
localhost IN SSHFP 4 2 0feb1aa0e1458368c3634dfe3aafc0ba84267475265f263fefd1be440d7e46ea