Dockge allows you to start/stop containers and edit your compose files from a handy ui.
Pros: if something goes wrong while you’re away, it would give you a tool to restart a service or make some changes if necessary.
Cons: exposing that much control to the outside world (even behind a log in) can potentially be catastrophic for your stack if someone gets in.
I wouldn’t trust anything like that to the open internet. It would be better to access the system over a VPN when you’re outside the network.
I could see that, but I would also have to ask ‘what exactly do we gain by having access to these tools when we aren’t home?’
I used to try to do all of that but I started to realize, I spend too much time dealing with broken shit. Coming to the mindset of if I’m not home and it doesn’t work then oh well has been one hell of a stress relief for me
Yeah, I think it really depends on use case. Like, I’m trying to imagine what aspect of my home lab could go so wrong, while I’m out of the house, that it would need fixed right away, and there’s nothing. I only leave my house for work or maybe a week of vacation, though, and I can imagine someone who’s occasionally away from home/house for 6-month deployments, or has a vacation home they only visit four weekends a year, might want more extensive remote maintenance. I’d still want to do that via ssh or vpn, but that’s me.
This is pretty much my situation. “Away from home” for me isn’t just a trip to the shops, it means being away for weeks at a time. I need to be able to fix things remotely if needed.
I’ve seen people recommend SSH, which seems worse because that would give potential hackers access to the whole system.
VPN is a very good suggestion, and what I’ve implemented now. Thank you to everyone who contributed
No - ssh is very easy to secure, while an exposed web-service is very hard to secure. Theres no difference in the security of ssh without password and for example WireGuard.
I do ssh because I’m more comfortable with it: it’s ubiquitous and as close to bulletproof as any security. Put it on a nonstandard port, restrict authentication to public keys, and I have no qualms.
Stick to strong keys and keep it on 22 for ease of use
I just don’t like my logs filling up with scripted login attempts. Even with fail2ban, for a while there I was getting 100+ login attempts every day, and it upset my sense of order.
One thing to consider, as well, is that SSH is extremely well reviewed, audited, and battle tested.
If you get “hacked” via SSH, it’s almost certainly because you had a bad password (don’t use passwords!), and not due to an exploitable bug in SSH.
Some random Docker management tool? Eh, I wouldn’t wager any money on you getting hacked, either through missing a configuration step, or a permission being too lose, or a flat out stupid decision made somewhere in the code that’s exploitable.
SSH + lazydocker is a reasonable choice if you want to go the SSH route and is my ‘oh shit, portainer-via-vpn is fucked’ backup.
Use wireguard
I’m using tailscale (which I hear is just a wrapper for wireguard) and love it.
It would mean you’re entrusting the entire security of your network to Dockge’s authentication system.
… and for that reason, I’m out.
Should be fine I have never used it in a man. I think it would be difficult to use it in a man with all the blood and other stuff.
I use portainer behind tail scale. Easy management anywhere and no publicly available access.
Indeed, tailscale/wireguard/zerotier are excellent options to keep only the bare minimum (or even nothing!) exposed to the world.
I have my portainer behind an oath proxy, using keycloak as the Auth provider
I’ll take “big red flags” for $1000
I would much prefer to just ssh
Don’t
Also I find it easy to just write a docker compose.
I have no issue writing a compose file. Dockge offers a bit more than that with logs and buttons for common commands which makes it easier and quicker to manage than through SSH.
To each their own 🙂
Yeah. I just forward SSH with keys only on a nonstandard port + fail2ban. Plus you can access local only services with an SSH port forward.
That’s also why I don’t use cockpit. It looks cool, but opens up vulnerabilities for very little benefit.
