(Author here) So, I've been running this exact same setup for my dev box and I think you're overestimating how often the whole IPv4 space is being scanned. Wha

(Author here) So, I've been running this exact same setup for my dev box and I think you're overestimating how often the whole IPv4 space is being scanned. What helped me at first was that I only set up an IPv6 address, since I have IPv6 at home. Scanning the whole IPv6 space is impractical, I've never seen an IPv6 address of mine being hit randomly (unless there's a public DNS record for it, or it's leaked some other way). But then I had to access my remote work environment from a laundromat (don't ask..) and I added an IPv4. I can see in the logs it's been woken up by some scans (some IP in the Baltics). Moving the SSH server to a non-standard port won't really help here. Using a VM of the smallest size to act as a bastion would essentially solve the cost problem - that's something you can do on fly today. For even better solutions... there'd need to be some collaboration from fly-proxy. I've been wanting to add /some/ firewall capabilities to it. If there were an API for that, you could run "knock" on another service, which would allowlist your address for a while on your actual "remote work VM" service. I also wanted to suggest "just using ipv6" (set up wireguard, boom, you're now in the VPN of your organization, where your VM lives, so just don't allocate a public IP for it and you're good), but the problem there is that it currently doesn't wake it up. Anyway this comment is a rich source of feature ideas, please keep them coming.