My OctoPrint instance is protected by credentials and these credentials are send encrypted thanks to the SSL certificate issued by let's encrypt. (HTTPS is enforced on the whole nginx server)
Is this a safe way to access my OctoPrint instance?
Most of the time my printer PSU is switched off so I'm mostly safe
If you are referring to something like HTACCESS/HTPASSWD then you are certainly better off than simply being publicly accessible. You are however still vulnerable to denial of service attacks which could affect the outcome of your print.
In my opinion from a security perspective I would say it is best to not have OctoPrint (or any 3D printer controller for the matter) publicly accessible. Either use a secure tunnel that is provided by some other device/environment or one of the plugins mentioned above that essentially does the same.
Another option that's quick and easy is simply using some RDC/VNC solution to connect to a computer on your network. I set up one of my machines with Chrome Remote Desktop and now I can access octoprint from anywhere by simply logging into my machine on the network and visiting it locally. Sure, this requires my home computer to be on all the time, but it was anyways. Great article and thanks for sharing
since you are aware of the fact that everyone just does this port-forwarding stuff, why don't you reinforce the access control in octoprint. At least an option where this read-only part is disabled.
@marvinmarmelade: I think some items have to be left in the responsibility of the users. They should be grows ups and know what they do. There are warnings enough.
If you signup to sponsor foosel at the corporate level, I'm sure she might consider doing so. Otherwise, remember that this is free, open-sourced software that you're using to control your printer.
Hardening any computer (like an OctoPrint server) so that it's safe to be on the Internet itself involves more work than you could ever imagine. It would probably take three to six months of dedicated work just to accomplish that. And even then, you'd have to constantly be on the lookout for all sorts of unseen exploits both in your own code as well as in all your dependencies.
I find that SSH access works well (public/private key access, password attempts are simply rejected and the offending IP address banned). Port tunnelling via SSH to get to the Octoprint server gives me some comfort as the only devices that can access the network are effectively pre-approved.
Search terms to get you started:
"ssh remote access linux public key"
"ssh-keygen"
".ssh/authorized_keys"
"ssh tunnel"
...aka newbie Octoprint/CR10s user, but reasonably seasoned linux convert.
So Im one of those listed in the report, Im one of the ones with a direct port forward to my Octopi instance. I have a synology vpn, and a trusted cert from lets encrypt running on it. I would love a guide to setting up the reverse proxy and lets encrypt cert on the octopi image.
Alas, my bigger concerns are the lack of authentication/logging to access Octopi without credentials(everything you can do without even logging in), and the attack vectors Octopi might have from the UI and plugins themselves (i.e. code injection/redirection, credential/session trickery etc)
Maybe someone can write a plugin to enforce login prior to access of anything.
Some extra info for people who don't know some of the terminology.
A VPS is a virtual server offered by a hosting company.
So basically, the OctoPi instance is coupled with that server via ssh port-forwarding (a.k.a. "SSH Tunneling"). The server uses haproxy and authentication to make sure that only Patrick can get to it.
Since nobody has mentioned it, I will... OctoPrint 1.4 (currently in development) will have improved access control. See OctoPrint.org - OctoBlog specifically the OctoPrint On Air entries that include updates on 1.4 progress.
Having said that, even with OctoPrint 1.4, direct port forwarding to OctoPi / OctoPrint is strongly discouraged. There are just too many good ways to accomplish remote access to your printer to consider direct port forwarding.
Is there an actual list of exposed OctoPrint instances? If so, I'd like to see if I'm on it.
Secondly, I use port forwarding with a spoofed external port pointing to internal port 5000. Is that sufficient? I know I should follow your instructions, but I don't have a Discord account, don't use Telegram, and other excuses.
Don't forget you can also use putty and create a tunnel to your octoprint web server. I create an ssh session to my main home server and that sets up a tunnel that when ever I go to port 8080 on 127.0.0.1(http://127.0.0.1:8080/), my windows laptop, it actually gets forwarded over the tunnel to the optoprint server behind my firewall. It gives me remote access via my ssh session so it is not available on the Internet at all unless you open an ssh session first..
And does this require an Internet firewall which allows a certain sort of traffic (without configuration)? I know that my Netgear router doesn't pass-through VPN traffic, for example. Or was it necessary to configure something like a port forward on the router?
All you need to to allow is ssh through the firewall. So if you already have ssh enable you don't need to do add anything else. It will be handled directly via putty and ssh. When you configure putty you will configure the putty session with the destination port and ip adress for the local port. So say you configure local port 8080.
It looks like this in putty under ssh/tunnels L8080 192.168.100.149:80
Which means when you connect to local 127.0.0.1:8080 Putty will then forward that via the ssh connection that is actively connected to your home server to ip 192.168.100.149 port 80. The ip is the octoprint server on your local network at home. This all goes over ssh and is not in the clear. No DNS entries are needed as it is going from ip to ip directly over ssh via the connected ssh session already established.
@Jimbrown719 I'll spend some time to add some graphics to all this so that people will better understand what's going on. I'm reading from here, btw.
This approach usually relies upon a known external (static) IP address so that the internal box ("my main home server") can initiate an outbound tunnel via ssh. People typically have a Linode or similar resource for this. (Many of the remote-my-PC softwares have your PC initiate a connection to their server, which then is the cloud-based connection point for the client side of their solution.)
Since 8080 is above 1024, less restrictions are given to it from the router's or the computer's standpoint.
To me, this sounds a little fishy. The safe solution involves your home computer initiating the session outbound. Anything where an inbound connection is initiated implies to me some sort of router-forwarding.
Let's say that I'm at Starbuck's and I want to connect to my own local server. If I try to simply ssh back to the private IP address of my local server, that won't route and fails. Any inbound attempt needs to know my router's public IP address. *
Reversing this, I note my Starbuck's-issued IP address and leave my laptop there. I go home and initiate an outbound connection to the laptop. Assuming that Starbuck's router is okay with this, I now have the tunnel active. I assume that I return to Starbuck's and can see my server at home.
* I could manually add a route on my laptop which directs traffic to that private IP address range at home to go through my router's public IP address, assuming that the router will forward it.
You start off with a good document but you lost me at everything after you say my ssh connection sounds fishy?. You never have to have a route on your laptop at star bucks to the home server running sshd. Everything is statically setup within the tunnel no routes are needed. The port you setup never gets used outside of the laptop when you hit the port the tunnel is using it gets sent out the ssh connection on port 22. SO if someone was watching the traffic leaving your laptop all that would be seen is secure ssh traffic going out port 22.