Remote Development with Rust on Fly.io | Hacker News Reader

Remote Development with Rust on Fly.io

fasterthanli.me

53 pointsmfrw7 comments

I'd be surprised if that method of determining Idleness works in practice. With port 22 exposed to the internet the VM will start being hit by brute force scans.

If the code watching for new connections doesn't ignore new short lived connections it will just keep the VM running 24/7.

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

It gets worse the longer the IPv4 address is up, in my experience. Eventually, your address ends up in some log that is inadvertently made public.

Increased my understanding of what fly actually is and what makes it special from 20% to 50%.

> cat /proc/cpuinfo | grep -i mhz

Completely ignoring the test, why use cat when grep accepts filename as argument?

The reason is that it takes me longer to remember the order of arguments for "grep" than it takes me to write the pipe. I also find that order more natural.

I'm also trying to carbon-offset all my useless uses of cat by writing ops glue in Rust instead of bash. Hopefully I'm net positive.

Reply on news.ycombinator.com