#sshfp — Public Fediverse posts

@samuel #SSHFP #DNS Record and #DNSSEC are also missing. And that with #SSH being the most important service protocol, besides HTTPS.

@ruawhitepaw #Github is also missing #SSHFP DNS records and #DNSSEC, which would help protect there users accessing it via git over SSH!

Really proud of this code generating SSHFP records for @c3d2
https://gitea.c3d2.de/c3d2/dns/src/commit/e0b8638f13281cee7080be0f86650fa250f73b43/flake.nix#L203-L241

#dns #knot #ci #devops #ssh #sshfp

Special thanks to @gehaxelt, who is the co-author of the paper that is based on his previous work on identifying #SSHFP misconfigurations, and Peter Mayer. Also many thanks to the organizers and the great audience at #ACSAC for an overall great conference!

🔗 full paper can be read here: https://publikationen.bibliothek.kit.edu/1000186330

@kitcybersec @SECUSO_Research @kastel @KIT_Karlsruhe

The #paper “Fix It - If you Can! Towards Understanding the Impact of Tool Support and Domain Owners’ Reactions to SSHFP Misconfigurations" by Anne Hennig, Sebastian Neef, and Peter Mayer has been accepted for presentation at the @ACSAC_Conf! The paper sent notifications to domain owners with misconfigured #SSHFP records, investigating the effect of tool support. While the sender of the #notification itself has no effect, the results suggest that tool support might increase remediation when the sender of the notification is different than the institution providing the tool. By analyzing domain owners’ responses to the authors' notification, multiple reasons for non-remediation were identified, supporting the argument that remediation rate should not be considered a success measure for a notification campaign but instead individual challenges faced by domain owners should be taken into account. ACSAC will take place December 8 to 12, 2025, in Honolulu, Hawaii, USA: https://www.acsac.org/
@Aryderwood @gehaxelt

Как FreeIPA защищает SSH от MITM-атак

Привет, Хабр! Сегодня мы предлагаем погрузиться во внутреннюю кухню протокола SSH, заострив особое внимание на его интеграции с доменом FreeIPA. Настройка такого взаимодействия будет интересна администраторам, привыкшим к централизованному управлению Windows-серверами и рабочими местами, входящими в состав MS AD. Развитие нашей продуктовой линейки включает глубокий анализ технологического стека, и мы хотим поделиться с читателями результатами своих исследований. Как известно, время — деньги, поэтому инженеры стараются настраивать удаленный доступ везде, где только можно, чтобы ничего не администрировать ногами.

https://habr.com/ru/companies/astralinux/articles/946002/

#ssh #freeipa #ald_pro #mitm #ключи #dh #sshfp #kerberos #sssd #диффихеллман

@letoams Similarly may publish #SSHFP record of #gitlab users. Both gitlab.isc.org and gitlab.nic.cz are on DNSSEC signed domains. Gitlab knows SSH keys of their users, very often used. They could export them for outer verification, just some way of mapping SSH key to username is required. We have that concepts for OPENPGPKEY and SMIMEA records. Would a new draft for SSHFP make sense too? Should it include public key directly in DNSKEY/KEY record?

@soatok @letoams For example mastodns.net is a Fedi server on #DNSSEC signed zone, algorithms 13 or 8 used only. I see no weakness if they would allow publishing of keys, RFC 7929 style. But with #SSHFP RR digests, to prove my identity of git ssh signed software, just like you have proposed. Just choose well your TLD and that's it. Append only log is important to prove no other CA made cert for my name. But we have just one parent domain key in #DNS. Give it a chance, it is not so bad. 😀

@letoams @soatok Hmm, perhaps we could map SSH keys identity to people very similar way as OPENPGPKEY record in #DANE, but with #SSHFP instead. We could reuse the algorithm for owner name creation, just use different record. But does not match how I use my SSH keys. I have each per machine, not one per person. I think I do them how I should, right?

Hmmm. I was playing with #OpenSSH's Host Key Rotation feature (https://blog.djm.net.au/2015/02/key-rotation-in-openssh-68.html) and publishing the new and old keys as #SSHFP in the #dns.

However, I noticed that the OpenSSH client would only check the primary key offered, and if _any_ of the SSHFP keys didn't match (which, they would not by definition), then it would shout that the already-cached host keys didn't match.

This seems to be intentional, but did surprise me a bit. I was hoping to preload all of the keys, so clients would have an easier upgrade process.

(OpenSSH server 9.5, client 9.6; both as part of #OpenBSD)

I took years’ worth of knowledge and finally condensed it all into one article. #SSH is everywhere, and it’s pretty secure out of the box, but why not improve on those defaults? From stronger ciphers to #SSHFP records, from IP filtering to #TOTP #MFA — yes, really! — there’s no reason why you can’t do it better. https://colincogle.name/ssh #tutorial #sysadmin #smallweb #windowsserver #linux #macos #blogging #selfhosted

What’s the point of having Internet standards if implementations can do whatever the hell they want with them…

RFC 4255 clearly states that a match between the key sent by the server and one of the #SSHFP records published in the #DNS is enough for the #SSH client to consider accepting the key.

Well, apparently that’s not good enough for the #OpenSSH folks, as their implementation considers that the key verification fails (resulting in the “IT'S POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!!!” message) unless the key matches all the SSHFP records for a given key type.

Want to pre-publish a SSHFP record for a future key in order to facilitate key rotation? OpenSSH developers decided that you can’t do that.

And it’s not a bug, that behaviour was implemented purposefully, and is not configurable.

@guenther @ewenmcneill @nova @mekkaokereke

#SSH has a mechanism specifically designed to avoid things like posting SSH server fingerprint on blogs etc

> dig sshfp test1.krvtz.net +short +dnssec
4 2 C152312CEB6FDB9B2DAE13B2A3D738628A30BFB5C04F9C546D258C3B E8DAD29E

Accompanied with VerifyHostKeyDNS yes in .ssh/config, the #SSHFP record will confirm server’s identity without the need for TOFU (trust on first use) and will verify it on any subsequent connection.

Of course, github.com does not have SSHFP 🤷‍♂️

Learned today about #SSHFP #DNS records where you can publish hashes of server host #SSH keys. Helps to solve the #trustonfirstuse (#tofu) problem.

@jk for TOFU cert checking, you might also find this #SSHFP related proposal by @tomasino interesting: gemini://tilde.team/~tomasino/journal/20210331-sshfp-and-the-tofu-issue.gmi