Maybe. You've expressed the same sentiment as you'd have seen for OpenSSL just a few months before everybody decided OpenSSL was unacceptable and they'd fork it (producing BoringSSL, LibreSSL and so on).
OpenBSD has some very peculiar preferences, some of which are in step with modern thinking (e.g. they like sandboxes, privilege dropping and defence in depth very much) but some very much are not (they like C despite its lack of Type Safety, Memory Safety, and generally just Safety)
SecSH (the SSH v2 standard) is a fairly clean modern encrypted protocol design. You do a key exchange, you bring up an encrypted link and then everything else happens inside this, alleviating many of your security concerns, the same way TLS 1.3 works (but TLS 1.3 is much more recent).
But the OpenSSH codebase dates back to even before SSHv2, it's basically the original SSH codebase, from back when encrypted remote shells was an entirely new idea, the mid-1990s, the SSH codebase went proprietary and OpenSSH is the fork. That's some crufty old code, and in C that's not an insignificant problem because problems in code you never read has potentially drastic consequences for unrelated code in the same binary.
> You've expressed the same sentiment as you'd have seen for OpenSSL just a few months before everybody decided OpenSSL was unacceptable and they'd fork it
I remember recurring complaints about the state of OpenSSL for years before e.g. mBed TLS and LibreSSL happened, but granted it's a decent example.
> it's basically the original SSH codebase
Would you be able to prove that by showing a bisection of the current sources and one of the releases from 22 years ago? I'd be surprised if not almost every single function in the code base hadn't seen significant changes.
That would be an obvious reason why their SSH implementation is in C. But for example their ACME implementation (to get certificates from e.g. Let's Encrypt) is also in C, even though various more famous ACME clients that were started earlier and have better features are in more modern languages like Python. That C ACME client complies with OpenBSD's other preferences, it is privilege separated resulting in a bunch of separate programs running to handle different privileges for example, but it is written in C and lacks some obvious security features that aren't platform specific.
Thus on OpenBSD a separate program handles your private key data from the one talking to the network. But, if you used a more capable ACME implementation for other platforms written in say, bash, a completely separate piece of software even on another machine can be talking to the network since that's just how the certificate process works. OpenBSD does not support this (last time I looked).
OpenBSD has some very peculiar preferences, some of which are in step with modern thinking (e.g. they like sandboxes, privilege dropping and defence in depth very much) but some very much are not (they like C despite its lack of Type Safety, Memory Safety, and generally just Safety)
SecSH (the SSH v2 standard) is a fairly clean modern encrypted protocol design. You do a key exchange, you bring up an encrypted link and then everything else happens inside this, alleviating many of your security concerns, the same way TLS 1.3 works (but TLS 1.3 is much more recent).
But the OpenSSH codebase dates back to even before SSHv2, it's basically the original SSH codebase, from back when encrypted remote shells was an entirely new idea, the mid-1990s, the SSH codebase went proprietary and OpenSSH is the fork. That's some crufty old code, and in C that's not an insignificant problem because problems in code you never read has potentially drastic consequences for unrelated code in the same binary.