For SSH I would disable login with password and only allow login with a ssh key. The other stuff sounds reasonable.

I may not be able to answer some of the more security-oriented questions, but one of the things I recommend is using a proxy to "hide" your home IP address. IP addresses can contain a lot of information including location data, so it's a good idea to make things harder for attackers to figure out where you live. I'm pretty sure you can do this with a basic VPS setup, but I know for sure you can do this with Cloudflare (as I have it enabled on my server).

As for getting reverse proxies set up from your Docker containers to the outside world using Apache, I can help. I use (rootless) Podman on my Raspberry Pi, meaning when I expose ports from my containers I have to choose port numbers greater than 8000. Once I have a port (let's say 8080), and a subdomain (I'll use subdomain.example.com), I just need to create a file in /etc/apache2/sites-available/ which I'll call site.example.com.conf. The content usually looks something like this:

  ProxyPreserveHost On
  ProxyRequests Off
  ServerName subdomain.example.com
  ServerAlias subdomain.example.com
  ProxyPass / http://localhost:8080/
  ProxyPassReverse / http://localhost:8080/

Then you just need to enter the commands sudo a2ensite subdomain.example.com and sudo systemctl reload apache2 and you should be able to access your container as a subdomain. You should just need to forward port 80 (and 443 if you want to set up Let's Encrypt and HTTPS) on your router.

Hope this helps!

Secure SSH. You should disable all password login capability and tighten the ciphers, KEX and MAC requirements. This will force modern SSH terminal use, something a lot of bots don't do, so they won't even get to the point of key exchange.

https://cipherlist.eu/

On your client, you can define an SSH config with a list of friendly host names that include direct IP addresses, the key to use to initiate login and whatever other properties you need. This way, you can just type in "ssh" and you don't need to specify the key or IP address every time.

Finally, configure Fail2Ban to ban/block on first failed SSH attempt. You won't be falling to login if you've configured a config definition file and are using keys.

YunoHost

This all sounds very reasonable. One question remains: what is the use of a dedicated proxy if cloudflare is connected? I do use nginx proxy manager and host my dockerized services on subdomains via https. I suppose if the reverse proxy gets attacked, the main server stays online and hidden. Does cloudflare not hide your ip and prevent (some) ddos attacks?

I have Nextcloud hosted internally in a podman container environment. To answer some of your more security related questions, here's how I have my environment set up:

1. Cloudflare free tier with my own domain to proxy outside connections to the public domain name, and hide my external IP.

2. A DMZ proxy server with a local traefik container with only ports required to talk to the internal Nextcloud server allowed, and inbound 443 only allowed from the internet (cloudflare).

3. An Authelia container tied to the Nextcloud container using "Two-factor TOTP" app addon. Authelia is configured to point to a free DUO account for MFA. The TOTP addon also allows other methods of you want to bypass Authelia and use a simply Google auth or other app. I'll be honest, this setup was a pain but it works beautifully when finally working.

Note: Using Authelia removes Nextcloud from the authentication process. If you login through Authelia, if set up correctly it will pass the user information to Nextcloud and present thier account. There is a way to have "quadruple" authentication of you really want it, where you log in through Authelia, Authelia MFA, then Nextcloud and Nextcloud MFA, but who would want that? Lol.

Another Note: If Authelia goes down for whatever reason, you can still log in through Nextcloud directly.

1. I have all of my containers set to automatically pull updates with the latest tag. This bites me sometimes of major changes happen, but it's typically due to traefik or mariadb changes and not Nextcloud or Authelia.

2. I have my host operating system set to auto update and reboot once a week in the early morning.

3. My data is shared through an NFS connection from my NAS that only allows specific IPs to connect. I'd like to say I'm using least privileged permissions in the share, but it's a wide open share as my NFS permissions are not my strong suite.

Hope the above helps!