upvote
Well, you can at least run "freebsd-update IDS" on this system to verify the base system, "pkg check -s -a" would check the integrity of files installed via pkg also.

It will only take a few min..

reply
Neat! Haven’t tried either of those before.

While I’m at it I also took a quick look now at output of `top` and it’s sitting at 27 MB free RAM lol. So from that, out of memory is very likely the reason I keep having sshd die on me.

reply
Not familiar with BSD but does it not syslog oom kills like linux?
reply
After rebooting the VM now, sshd died even when there was hundreds of megabytes free RAM available. So it seems I spoke too soon when I said it seemed to be for that reason.

Previously I haven't seen much detailed reason for why it dies in system messages. But this time it said something very specific:

> sshd[2036]: fatal: pack_hostkeys: serialize hostkey private: string is too large

Which kind of sounds like one of the sshd hostkey files might be corrupt? And maybe it only triggers after a while becuase it happens when scanners try to connect to it and during ssh negotiation sshd ends up selecting a different hostkey type than the one it uses when I connect to the machine myself?

I'm going to regenerate all of the three hostkey files on the server, and after that also disable the two that I can do without anyway.

reply
Try adding this to your /etc/rc.conf:

    sshd_oomprotect=YES

Then run

   service sshd restart
reply
I have run OpenBSD on Vultr for probably a decade at this point, and never seen that behaviour.
reply