I've been considering https://openbsd.amsterdam/ as it seems like a nice way to donate to the project as well. For now I am using a lowest tier Hetzner instance. That gives more RAM but less disk space (which is pretty inconvenient for OpenBSDs automatic partitioning IMO).

OBSD Amsterdam is pretty cool. I am currently running an instance on it. One feature that could also be considered a bug is that the VPSes run on the native OpenBSD virtualization scheme. My instance has suffered a few crashes over the years. It's been solid more recently. I suspect that OBSD Amsterdam and users have contributed to improvements to the native virtualization.

So you control your instance by sshing into a BSD account on the server. You configure your reverse DNS the same way. It's OpenBSD all the way down. So, as mentioned, pretty cool. Possibly not for the OBSD user who prefers some sort of web based configuration for their VPS.

It comes with access to a server you can copy your backups to. You of course do that from your instance using ssh.

You could also manually partition.

As an OpenBSD noob I prefer not to until I get a good feel for how much will end up in them across a few sysupgrades.

If you run it as a server mostly, I think the home partition at least can be shrunk to like 2GB or something.

I remember when Vultr was new and had a single rack with a handful of boxes. Their site has no graphics apart from an ASCII logo. They had low prices but you often had to wait for them to build a new box before you could sign up. Their whole schtick at the time was, "we are building this for people who know what they are doing, don't bother us for support, we don't have any."

But they are not that small anymore. They are now VC-funded, operate in 36 datacenters worldwide and are currently spending $1 billion to build an AI datacenter in Ohio.

Have been using vultr with very good stability for BSD systems since 2015 or so, highly recommend.

I have a couple of FreeBSD VMs on Vultr. For quite some time sshd regularly dies on one of them and I am not sure why.

A couple of theories I’ve had is that maybe

a) my VM was compromised and there is a persistent rootkit installed that kills sshd, or

b) file corruption after previous unclean shutdown has left some file needed by sshd corrupted and it leads to this behaviour, or

c) maybe it’s running out of memory sometimes

Each time I want to ssh into the machine I usually have to first connect with the VNC from the vultr dashboard to start sshd up again.

It’s running the latest FreeBSD, as every now and then I log in and do an upgrade on it some time after a new version has been released.

A persistent rootkit may have been installed if it was compromised between when some vulnerability became known and when I later upgraded next time.

If a file was corrupted in an unclean shutdown in the past maybe it’s a file that has not been changed between FreeBSD versions so even though upgrades replace some files maybe it’s the same corrupted file all along.

Ideally I’d just reinstall the machine, but that’s always more of a hassle than it should be so I continue running the VM in this broken state where sshd keeps dying every now and then.

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..

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.

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

    sshd_oomprotect=YES

Then run

   service sshd restart

Not familiar with BSD but does it not syslog oom kills like linux?

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.

Sounds like a you problem I've had multiple FreeBSD systems on vultr for over a decade and never had sshd issues. Of course I also use an alternate port and active fail2ban to block those who insist on any brute force for any protocol. 128K active blocks currently.

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

I used buyvm.net for BSD a while back. Didn't have any issues, and the few times I contacted their support they were quick to respond and helpful.

rootbsd.net before that, but they don't seem to exist anymore.

The admins have access to your data and unless things have changed, that isn't monitored. They also bend to NSLs like any other provider. What they charge vs what things cost hurts.

Any cloud compute vendor will have access to your data unless you encrypt it.

> unless you encrypt it

And to clarify, this means encrypt it before it gets to the VPS. Just having full-disk encryption is not enough because cloud providers can dump RAM. There are tools that easily extract encryption keys from RAM.

So, really, you need to trust the cloud provider unless everything is encrypted on computers you own.

> And to clarify, this means encrypt it before it gets to the VPS. Just having full-disk encryption is not enough because cloud providers can dump RAM. There are tools that easily extract encryption keys from RAM.

True, but at the very least, you won't have to worry about discarded SSDs having your data in plaintext.

They were very helpful when one of the AMD firmware patches in 7.3 caused my VPS to not boot. They even offered to apply a manual fix until patch -015 was available which fixed it.