• 1 Post
  • 95 Comments
Joined 2 years ago
cake
Cake day: July 8th, 2023

help-circle

  • No problemo.

    Thanks for pointing out the reverse proxy comment. I think I was wrong to say simply putting jellyfin behind a reverse proxy will increase your security.

    The benefits may only be minute or non-existent if you don’t use the reverse proxy for handling other stuff like HTTPS (and redirects to https, etc), restricting access or adding extra authentication requirements (mainly https).

    It may also be good to note that Jellyfins docs explicitly do not recommend directly exposing jellyfin ports to the internet (a reverse proxy or using a vpn are recommended instead).

    Still I will continue to feel safer always using a reverse proxy when I expose to the internet (maybe my misconceptions).


  • Your SSH setup is good.

    ssh is a very resilient piece of software so I doubt with your setup you would encounter any issues.

    Enforcing use of a VPN to get into your network before being able to ssh into a machine is mostly just an extra layer of defense, though using a non-standard port, only allowing key logins and disabling root user login are all layers of defense you have already added.

    I thinj you’ll be fine, but if you are worried, you could setup a VPN or alternatively something like Fail2Ban if you notice any brute-force attacks (which may be unlikely with the use of a non-standard port).

    What I meant with the Jellyfin question was kind of, how is having it exposed via a reverse proxy different from exposing its port right away? Is it because the only allowed connection would be HTTPS/encrypted etc, maybe?

    It’s down to how secure the software is really.

    Jellyfins (and other software) don’t use really secure web servers for getting themselves accessible via the network.

    Caddy (a reverse proxy, for example) is made to be exposed to the internet and so it is more resilient and safe to use.

    So putting the resilient software (a good reverse proxy) infront of Jellyfin (or most other software) simply increases your security by having the more safe web server be the one interfacing with end users.

    Have fun on your journey!



  • If you don’t want to worry too much, you can setup a vpn (like wireguard) on your server for ssh access.

    Using a non standard port is a good idea, but not entirely foolproof because bots might still port scan (even if unlikely that they do that for ssh I’m not sure). At a mininum, you probably want to use keys for login like the other commenter on the main comment said.

    Personally, using a vpn for when I want access to SSH when I’m out is worth the couple hours setting it up the one time (very simple setup with wireguard-easy for example). Maintenence time spent on upgrading is very low.

    (Tl;dr personally I’d use a vpn to access ssh specifically rather than exposing it to the internet)

    Same thing for Jellyfin?

    Not 100% sure what you mean, but to clarify: Don’t accidentally expose jellyfins port to the internet (eg the default port 8096). Make sure it is only accessible from outside your network through your reverse proxy.


  • I agree, there is a lot of paranoia, but honestly that’s probably a good thing, because the people who are paranoid might not know that much, so a good amount of paranoia is healthy there.

    The chance of being exploited is very low for me to care too too much. Why spend countless days locking up my entire infra when there’s a very low low chance anyone could exploit me in the first place (obviously get your setup to a good standard, I don’t recommend not reading up on anything and exposing server, etc. Just for me, I don’t need to over do it).

    That being said, personally I have ssh behind a vpn because that’s a very important service that only I am accessing anyways, so it makes sense for me to disable that attack vector.








  • Most people still only have 16gb of ram (like me).

    Electron is net good, but only for small teams that need to ship fast or solo devs etc who already know js and just want something to work.

    Billion dollar companies using it instead of paying more for native apps is a horrible use case (that’s mainly where my complaints live).

    At the very least, I hope we move to something that can use webviews on our system rather than bundling their own which would save on resources (but opens the possibility for version mismatches i guess, I dunno if you can “peg” that sorta stuff to a working version… but i guess thats just how browsers work so…).




  • It’s nice to hear you didn’t see a drop in engagement, that gives me hope.

    I think I might do as you say and make something small to try out codeberg, see if everything works for me (dev to release).

    motivation for my migration was just wanting to use services that support what i support

    Very true, if it works I should just do it. It’s not like I’m losing paying customers hehe.

    p.s. thanks for the link, I hadn’t looked it up yet :)


  • Yeah, I think Letsencrypt (and others) are one of the best things to happen for the internet.

    You used to have to cough up a good chunk of monies for a certificate.

    Now it’s easily accessible and you (i) never have to think about it after the first setup because a robot automatically renews expiring certificates for me.

    Generally this is one of the best improvements: a more secure web that is easier to achieve.


  • I guess I have a slightly different problem in that I use GitHub Container Registry to host release images.

    I haven’t looked, but I would think Codeberg might have something similar.

    I would use Docker’s registry, but that feels like stepping sideways instead of forwards for some reason.

    Yes, you will lose some “driveby” error reports from people who don’t want to make a codeberg account to report the bug on. But then they don’t actually “need” need it solved either.

    That’s a very good point. I had thought of keeping the github repo mirrored so that it could be used for issues (and maybe prs?) still, but your point has me rethinking the need.

    Make it a single source of truth, point to the new repo in the old one and update the descriptions in the distributing websites/services and that’s it.

    I will certainly consider this. It would definitely be easier than setting up a mirror in addition to moving.

    I guess I’m worried that without an “active” side on github, the project will lose any traction it has gained since I didn’t advertise it, I think github naturally brought people in.

    Thank you for your reply, it is very helpful!


  • That’s a good point, I guess I already practice this with everything else, I just waited too long for this specifically and now there’s a lot of (+new) people I’d potentially be parting with.

    Still going to think about this and maybe test the waters, see if it’s viable.

    Thank you for the response, I feel more confident in the idea!