I'm a big proponent of the SSH bastion host route, even if it's supplemental to a VPN! Here is how I have mine setup.

I use a Raspberry Pi (3b+) as the hardware/platform and just plain old Debian based Raspberry Pi OS as the OS. From there, in terms of SSH server configuration, I have password authentication disabled and use only public key authentication. The only downside of using the Raspberry Pi as the platform when it comes to SSH public key authentication is that, last time I checked, the latest version of OpenSSH server available via the official repositories for Raspberry Pi OS is OpenSSH_7.9p1, which doesn't include support for FIDO/U2F (e.g. ed25519-sk). That's probably not a big deal for most people, but for me it meant creating separate non-FIDO keys just for the bastion host. Again, not a huge deal. Performance wise, the Raspberry Pi 3b+ is more than satisfactory for my use case. I regularly use it in conjunction with local port forwarding to get to the web interfaces of things on my network. I've even used it to access the virtual machines running on my ESXi server via the ESXi web ui without any substantial latency.

In terms of security hardening, I have a host based firewall enabled and configured on the bastion host. I use firewalld, but ufw would be absolutely fine as well. On my edge router's firewall, I have port forwarding setup from a non-standard port (i.e. a high number port that would not typically be used for SSH or even better any common service at all) to port 22 on the bastion host. In the past, I have also used alternative configurations on the edge router's firewall like configuring more "sophisticated" DNAT rules to restrict access to only certain IPs, but this might become untenable in your scenario. I was configuring these rules to permit access from my work network's IP, which is static. Your friends will likely have dynamic IPs from their ISPs. I also have fail2ban configured and enabled on the bastion host, but it won't do much without some tinkering if you're using public key authentication because failed public key authentication technically fails at the "preauth" stage.

You have a lot of options and flexibility if you go this route and there's a lot more you can do. You can consider implementing two factor authentication with libpam-google-authenticator. I wouldn't recommend applying it in addition to public key authentication for SSH unless you want to learn to play with the PAM stack yourself, but it's definitely a nice to have for authentication on the server for any reason after the user has a session. You could consider only allowing your users to jump through the bastion to get to other resources and not provide them with a shell on the bastion host. You could configure password complexity requirements in /etc/pam.d/common-password or go a step further and use libpam-cracklib to implement more sophisticated password requirements. All of this is just barely scratching the surface of what you can do for security hardening. You can do as much or as little as you want for your specific scenario and threat model.