What’s your go too (secure) method for casting over the internet with a Jellyfin server.

I’m wondering what to use and I’m pretty beginner at this

  • Sgt_choke_n_stroke@lemmy.worldEnglish
    4·
    6 个月前

    Synology worked for me. They have built in reverse proxy. As well as good documentation to install it on their machine. Just gotta configure your wifi router to port forward your device and bam you’re ready to rock and roll

  • HeyJoe@lemmy.worldEnglish
    3·
    6 个月前

    Synology with Emby (do not use the connect service they offer) running behind my fortinet firewall. DDNS with my own domain name and ssl cert. Open 1 custom port (not 443) for it, and that’s it. Geoblock every country but my own, which basically eliminated all random traffic that was hitting hit. I’ve been running it this way for 5 years now and have no issues to report.

  • PieMePlenty@lemmy.worldEnglish
    12·
    6 个月前

    I access it through a reverse proxy (nginx). I guess the only weak point is if someone finds out the domain for it and starts spamming the login screen. But I’ve restricted access to the domain for most of the world anyway. Wireguard would probably be more secure but its not always possible if like on vacation and want to use it on the TV there…

  • borax7385@lemmy.worldEnglish
    6·
    6 个月前

    I have had Jellyfin directly open to the Internet with a reverse proxy for years. No problems.

    • pHr34kY@lemmy.worldEnglish
      3·
      6 个月前

      If your reverse proxy only acknowledges jellyfin exists if the hostname is correct, you won’t get discovered by an IP scanner.

      Mine’s on jellyfin.[domain].com and you get a completely different page if you hit it by IP address.

      If it does get found, there’s also a fail2ban to rate-limit someone brute-forcing a login.

      I’ve always exposed my home IP to the internet. Haven’t had an issue in the last 15 years. I’m running about 10 public-facing services including NTP and SMTP.

  • bl_r@lemmy.dbzer0.comEnglish
    8·
    6 个月前

    Tailscale, with nginx for https.

    Very easy, very simple, just works, and i can share my jellyfin server with my friends

  • status6@lemmy.worldEnglish
    1·
    6 个月前

    I use mTLS by adding a reverse proxy between Jellyfin and the Inet. This makes it hard to use the app, but works perfect with a browser. If you still want to use the app. There is a solution by using stunnel (termux) between te app and the Inet or better, a wireguard VPN.

    • SapphironZA@sh.itjust.worksEnglish
      4·
      6 个月前

      Why would you need to expose SSH for everyday use? Or does Jellyfin require it to function?

      Maybe leave that behind some VPN access.

      • Dataprolet@lemmy.dbzer0.comEnglish
        9·
        6 个月前

        Take a look at Nginx Proxy Manager and how to set it up. But you’ll need a domain for that. And preferably use a firewall of some sort on your server and only allow said ports.

          • Midnight Wolf@lemmy.worldEnglish
            10·
            6 个月前

            This isn’t a guide, but any reverse proxy allows you to limit open ports on your network (router) by using subdomains (thisPart.website.com) to route connections to an internal port.

            So you setup a rev proxy for jellyfin.website.com that points to the port that jf wants to use. So when someone connects to the subdomain, the reverse proxy is hit, and it reads your configuration for that subdomain, and since it’s now connected to your internal network (via the proxy) it is routed to the port, and jf “just works”.

            There’s an ssl cert involved but that’s the basic understanding. Then you can add Some Other Services at whatever.website.com and rinse and repeat. Now you can host multiple services, without exposing the open ports directly, and it’s easy for users as there is nothing “confusing” like port numbers, IP addresses, etc.

            • scoobydoo27@lemmy.zipEnglish
              1·
              6 个月前

              So I’m another newbie dummy to reverse proxies. I’ve got my jellyfin accessible at jellyfin.mydomain.com but I can only access it through the web. How do I share with other people who want to use the apps? I can’t get my apps to find my instance.

              • pory@lemmy.worldEnglish
                1·
                6 个月前

                Can “your apps” access it when their device isn’t on your home LAN?

                • scoobydoo27@lemmy.zipEnglish
                  1·
                  6 个月前

                  That was the problem, I couldn’t access anything away from my LAN. I finally figured it out though. I’m using Pangolin to access my services outside of my LAN and by default it adds a SSO option. Once I turned that off, my iPhone app was able to find my server through my domain name just fine. Thanks!

    • Novi@sh.itjust.worksEnglish
      707·
      6 个月前

      I would not publicly expose ssh. Your home IP will get scanned all the time and external machines will try to connect to your ssh port.

      • Auli@lemmy.caEnglish
        1·
        6 个月前

        Ssh has nothing to do with scanning. Your IP and everyone else up is being scanned constantly. In ipv4 space at least.

          • fuckwit_mcbumcrumble@lemmy.dbzer0.comEnglish
            11·
            6 个月前

            In 3 years I haven’t had a single attempted connection that wasn’t me. Once you get to the ephemeral ports nobody is scanning that high.

            I’m not saying run no security or something. Just nobody wants to scan all 65k ports. They’re looking for easy targets.

      • Everyday0764@lemmy.zipEnglish
        2·
        6 个月前

        i have ssh on a random port and only get so many scan, so low that fail2ban never banned anyone that was not myself (accidentally).

      • drkt@scribe.disroot.orgEnglish
        154·
        6 个月前

        They can try all they like, man. They’re not gonna guess a username, key and password.

          • Thaurin@lemmy.worldEnglish
            11·
            6 个月前

            I remember that one. Those are pretty rare and usually involve a specific configuration that is often not the default, though, right? When such a vulnerability is found, is it rightly so major news.

            • Ptsf@lemmy.worldEnglish
              2·
              6 个月前

              “This race condition affects sshd in its default configuration.” direct quote from the linked article, paragraph like… 3. I linked it so people could read, not speculate.

                • Ptsf@lemmy.worldEnglish
                  21·
                  6 个月前

                  Agreed, but best practices are meant to deal with the very rare. They didn’t put the vulnerabilities in the software due to negligence or malice, it’s just an ever evolving arms race with cracks that show up due to layer upon layer of abstraction. Again I’m not saying to never expose ssh to the net, quite the opposite, but as a best practice you should never do it unless you fully understand the risk and are prepared to deal with any potential consequences. That’s just a core tenant of understanding security posture.

          • drkt@scribe.disroot.orgEnglish
            344·
            6 个月前

            If you’re going to open something, SSH is far, far more battle-tested than much other software, even popular software. Pragmatically, If someone is sitting on a 0-day for SSH, do you genuinely think they’re gonna waste that on you and me? Either they’re gonna sell it to cash out as fast as possible, or they’ll sit on it while plotting an attack against someone who has real money. It is an unhealthy level of paranoia to suggest that SSH is not secure, or that it’s less secure than the hundreds of other solutions to this problem.

            Here is my IP address, make me eat my words.
            2a05:f6c7:8321::164 | 89.160.150.164

            • Ptsf@lemmy.worldEnglish
              62·
              6 个月前

              I linked a relevant vulnerability, but even ignoring that, pragmatically, you feel they’d be targeting specific targets instead of just what they currently do? (That, by the way, is automating the compromise of vulnerable clients in mass scale to power botnets). Any service you open on your device to the internet is inherently risky. Ssh best practices are, and have been since the early days, not to expose it to the internet directly.

              • drkt@scribe.disroot.orgEnglish
                71·
                6 个月前

                You did link a vulnerability! That is true. I didn’t claim SSH had a clean track record, I claimed it had a better track record than most other software. That vulnerability is hard to exploit, and generates a lot of noise if you were to try, which nobody has because it’s never been found in the wild.

                People who sit on 0-days for critical software like SSH don’t go out and try to mass-exploit it because it will be found within the day and patched within the week once they start making noise. This is not a quiet exploit. If they’re smart, they sell it. If they’re ambitious, they build an elaborate multi-chain attack against a specific target. Only 0.14% of devices vulnerable to this exploit are EoL versions of OpenSSH, so once this was patched, it was no longer a useful attack vector.

                It would also have been completely negated by fail2ban, which is prominently deployed on internet facing SSH, as it required thousands and thousands of connection attempts to trigger the condition. It could also have been mitigated by not running sshd as root, though I understand that most people don’t want to deal with that headache even though it is possible.

                There are thousands of independent honeypots that sit quietly and sniff all the mass-attacks and they earn their daily bread by aggregating and reporting this data. If you run a mass exploit, you will be found within the day. Trust me, I burned an IP address by regularly scanning the whole IPv4 space. You are going to end up on blacklists real fuckin’ fast and whatever you were doing will be noticed and reported.

                If you’re going to open something, SSH is a very safe choice. But yes, don’t open it if you don’t need it. We are discussing how to open a service to the internet safely, though, so we need it.

                • Ptsf@lemmy.worldEnglish
                  34·
                  6 个月前

                  🤔🤔🤔🤔🤔

                  https://arstechnica.com/information-technology/2022/02/after-lying-low-ssh-botnet-mushrooms-and-is-harder-than-ever-to-take-down/

                  Are we living in the same universe? In mine software doesn’t get patched all the time, in fact it’s usually a lack of patches that lead to any significant system compromise… Which happens time and time again. Also you’re on a thread that is advising hobbiests on how to configure and maintain their personal server, not the engineering meeting for a fortune 500. Yes, you can make ssh very secure. Yes, it’s very secure even by default. In the same regard, new vulnerabilities/exploits will be found, and it remains best practice not to expose ssh to raw internet unless absolutely necessary and with the considerations required to mitigate risk. Ssh isn’t even implemented identically on every device, so you literally cannot talk about it like you are. Idk why you’re arguing against the industry standard for best practices decided by people who have far more experience and engineering time than you or I.

            • pm_me_your_puppies@infosec.pubEnglish
              141·
              6 个月前

              You got balls to post you public addresses like that… I mean I agree with you wholeheartedly and I also have SSH port forwarded on my firewall, but posting your public IP is next-level confidence.

              Respect.

        • adr1an@programming.devEnglish
          41·
          6 个月前

          Only the failed attempts could be a Denial Of Service and throw you out. So, at least add an ever increasing delay to those. Fail2ban is important.

      • Ptsf@lemmy.worldEnglish
        2·
        6 个月前

        Honestly you can usually just static ip the reverse proxy and open up a 1:1 port mapping directly to that box for 80/443. Generally not relevant to roll a whole DMZ for home use and port mapping will be supported by a higher % of home routing infrastructure than DMZs.

        • cm0002@lemmy.worldEnglish
          2·
          6 个月前

          It’s beginner level, the hard part is the reverse proxy, once you have a grasp on that just having it on a dedicated box in a segmented portion on your firewall designated as the DMZ is easy. Id even go so far as to say its the bare minimum if you’re even considering exposing to the internet.

          It doesn’t even need to be all that powerful since its just relaying packets as a middleman

    • WhyJiffie@sh.itjust.worksEnglish
      13·
      6 个月前

      and a local reverse proxy that can route through wireguard when you want to watch on a smart tv.

      its not as complicated as it sounds, it’s just a wireguard client, and a reverse proxy like on the main server.

      it can even be your laptop, without hdmi cables

      • phx@lemmy.caEnglish
        9·
        6 个月前

        You can also use a router that can run wireguard/openvpn and have that run the tunnel back to home for you. I’ve got a portable GL-Inet router with OpenWRT that I use for this when I’m on the road

        • WhyJiffie@sh.itjust.worksEnglish
          1·
          6 个月前

          or that yes, but I often don’t want to give the whole network access to my home network for security reasons, so that’s something to consider

        • WhyJiffie@sh.itjust.worksEnglish
          1·
          6 个月前

          what do you mean by off network? on the wifi of a different home’s network, that has internet access?

          the wireguard client on your laptop is supposed to give the laptop (and the laptop only) access to your home network, and the reverse proxy running on the laptop is supposed to give local devices access to services at home selectively, by listening on port 443 on the local network, and processing requests to services that you defined, by forwarding them through the vpn tunnel.
          this requires that a machine at home runs a wireguard server, and that its port is forwarded in your router