Hello all! Yesterday I started hosting forgejo, and in order to clone repos outside my home network through ssh://, I seem to need to open a port for it in my router. Is that safe to do? I can’t use a vpn because I am sharing this with a friend. Here’s a sample docker compose file:

version: "3"

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:7
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - FORGEJO__database__DB_TYPE=postgres
      - FORGEJO__database__HOST=db:5432
      - FORGEJO__database__NAME=forgejo
      - FORGEJO__database__USER=forgejo
      - FORGEJO__database__PASSWD=forgejo
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22" # <- port 222 is the one I'd open, in this case
    depends_on:
      - db

  db:
    image: postgres:14
    restart: always
    environment:
      - POSTGRES_USER=forgejo
      - POSTGRES_PASSWORD=forgejo
      - POSTGRES_DB=forgejo
    networks:
      - forgejo
    volumes:
      - ./postgres:/var/lib/postgresql/data

And to clone I’d do

git clone ssh://git@<my router ip>:<the port I opened, in this case 222>/path/to/repo

Is that safe?

EDIT: Thank you for your answers. I have come to the conclusion that, regardless of whether it is safe, it doesn’t make sense to increase the attack surface when I can just use https and tokens, so that’s what I am going to do.

  • N0x0n@lemmy.mlEnglish
    162·
    5 months ago

    Opening ports on your router is never safe ! There’re alot of bots trying to bruteforce opening ports on the web (specially ssh port 22)

    With SSH I would disable the password authentication a only used key based authentication. Also disable root access. (Don’t know how it works with forgero though)

    I would recommend something like wireguard, you still need to open a port on your router, but as long as they don’t have your private key, they can’t bruteforce it. (You can even share the wireguard tunnel with your friend :))

    Also use a reverse proxy with your docker containers.

    There are a lot of things you could do to secure everything, but If you relatively new to selfhosting, there’s a steep learning curve and a lot of time needed to properly secure everthing up. You could be safe by doing nothing for a few months but as soon as someone got into your system, you’re fucked !

    But don’t discourage yourself, selfhosting is fun !

    • atzanteol@sh.itjust.worksEnglish
      20·
      5 months ago

      Opening ports on your router is never safe !

      This is both true and highly misleading. Paranoia isn’t a replacement for good security.

      I would recommend something like wireguard, you still need to open a port on your router, but as long as they don’t have your private key, they can’t bruteforce it.

      The same is true of ssh when using keys to authenticate.

      • N0x0n@lemmy.mlEnglish
        1·
        5 months ago

        You’re right, but only if you are an experienced IT guy in enteprise environnement. Most users (myself included) on Lemmy do not have the necessary skills/hardware to properly configure and protect their networking system, thats way I consider something like wireguard way more secure than opening an SSH port.

        Sure SSH key based configuration is also doing a great job but there is way more error prone configuration with an SSH connection than a wireguard tunnel.

        • atzanteol@sh.itjust.worksEnglish
          2·
          5 months ago

          You’re right, but only if you are an experienced IT guy in enteprise environnement. Most users (myself included) on Lemmy do not have the necessary skills/hardware to properly configure and protect their networking system, thats way I consider something like wireguard way more secure than opening an SSH port.

          But it doesn’t help to just tell newbs that “THAT’S INSECURE” without providing context. It 1) reinforces the idea that security “is a thing” rather than “something you do” and 2) doesn’t give them any further reference for learning.

          It’s why some people in this community think that putting a nginx proxy in front of their webapp somehow increases their security posture. Because you don’t have “direct access” to the webapp. It’s ridiculous.

          Sure SSH key based configuration is also doing a great job but there is way more error prone configuration with an SSH connection than a wireguard tunnel.

          In this case it’s handled by forgejo.

    • gurapoku@lemmy.worldOPEnglish
      4·
      5 months ago

      The reason why I am asking this question is because I think that the ssh port I am opening only has access to my repos (which means that even if I somehow get hacked the damage is minimal) and it doesn’t accept any keys aside from mine and my friend’s, which we set up through the web interface :).

      I have wireguard setup and I’d also thought about sharing a tunnel with my friend, but it seemed much more hasslesome than simply opening the port, not to mention the fact that if anyone wanted to join too I’d have to do that again.

      It is exactly because I am afraid of getting fucked that I am asking this and being careful. For now, my idea is to only open the port when someone is about to use it, since I am not absolutely sure that it won’t somehow accept a request from a person with less than noble intentions. (either that, either simply use tokens)

      Reverse proxying was also my intention at first, but I just couldn’t get it to work with cloudflare for some reason!

      Thanks for the insight!

  • rutrum@lm.paradisus.dayEnglish
    8·
    5 months ago

    You can also use p2p mesh vpn services like zerotier or tailscale to establish a direct connection without opening any port in the router at all.

    • gurapoku@lemmy.worldOPEnglish
      2·
      5 months ago

      A good suggestion, but it would still be hasslesome to setup. Plus, my friend would have to connect to the vpn whenever he wants to push/pull the repo

      • BearOfaTime@lemm.eeEnglish
        3·
        5 months ago

        Tailscale has the Funnel feature which doesn’t require your friends use the client.

      • rutrum@lm.paradisus.dayEnglish
        1·
        5 months ago

        Yes everyone would need a client (probably?) but after having recently set it up the first time, its incredibly simple.

  • atzanteol@sh.itjust.worksEnglish
    5·
    5 months ago

    I have come to the conclusion that, regardless of whether it is safe, it doesn’t make sense to increase the attack surface when I can just use https and tokens, so that’s what I am going to do.

    Are you already exposing HTTPS? Because if not you would still be “increasing your attack surface”.

      • atzanteol@sh.itjust.worksEnglish
        6·
        5 months ago

        Wait, so you have the full website exposed to the Internet and you’re concerned about enabling ssh access? Because of the two ssh would likely be the more secure.

        But either are probably “fine” so long as you have only trusted users using the site.

        • gurapoku@lemmy.worldOPEnglish
          1·
          5 months ago

          Yes, hosting the site seems much safer (at least in theory) since I am proxying it through cloudflare and I am planning on putting ngynx too on top of that this afternoon

          (And signup is disabled, so hopefully only trusted users can access it)

          • 486@kbin.social
            81·
            5 months ago

            I am not sure where this idea comes from, but putting a service behind a reverse-proxy does not increase its security in any way, unless you’d do authentication right at the reverse-proxy.

            • Miaou@jlai.luEnglish
              2·
              5 months ago

              I spent my day today setting up nginx with mtls at work, and I actually think it’s a great approach for what op is trying

              • 486@kbin.social
                2·
                5 months ago

                Oh, I didn’t want to suggest that there is no value in using a reverse-proxy, there certainly is. Just don’t expect it to do anything for you in terms of application security. The application behind it is just as exposed as it would be without a proxy. So if there was a security flaw in that application, the reverse-proxy does not help at all.

  • Decronym@lemmy.decronym.xyzBEnglish
    31·
    5 months ago

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

    Fewer Letters More Letters
    Git Popular version control system, primarily for code
    HTTP Hypertext Transfer Protocol, the Web
    HTTPS HTTP over SSL
    SSH Secure Shell for remote terminal access
    SSL Secure Sockets Layer, for transparent encryption
    VPN Virtual Private Network
    nginx Popular HTTP server

    [Thread #764 for this sub, first seen 27th May 2024, 10:05] [FAQ] [Full list] [Contact] [Source code]

  • h3ndrik@feddit.deEnglish
    42·
    5 months ago

    As of now all advice here is kinda missing the point or wrong… (Exept the one recommendation to do updates ;-) I wouldn’t use Cloudflare as it’s really bad for freedom, watches your traffic and most interesting things aren’t even in the free/cheap plans… You can’t restrict connections to the “Established state” or you can’t ever connect to your server… And SSH is a safe protocol. Just depends on the strength of your passwords… And yeah, opening ports is never 100% safe. Neither is using computers. They can be hacked but that’s not helping… And I’d agree using Wireguard or Tailscale would help. But you already said you don’t want a VPN…

    I didn’t have a proper look at the Forgejo Docker container. I’d say it’s safe. It’s probably using keys instead of passwords(?!) I hope they configured it properly if they ship it per default. And it’s running sandboxed in your Docker container anyways and not running a system shell on the machine.

    The issue with SSH is, there are lots of bots scanning the internet for SSH servers and testing passwords all day. Your server will be subject to a constant stream of brute-forcing attempts. Unless you take some precautions. Usually that’s done by blocking attackers after some amount of failed login attempts. This is either preconfigured in your Docker container (you should check, or watch the logs.) Or you’d need to use something like fail2ban on top. Or ignore the additional load and have all your users use good passwords.

    (What I do is use Git over https. That worked out of the box while ssh would have required additional work. But I also have lots of other ports forwarded to several services on my home-server. Including ssh. No VPN, no Cloudflare … I have fail2ban and safe passwords. I’m happy with that.)

  • adr1an@programming.devEnglish
    21·
    5 months ago

    Yes, as safe as SSH can be. Why not use https with cloudfare tunnels? For SSH, depends on security config and ofuscation measures… Like disabling root login, use encryption keys instead of plain password, pick a “hidden” port number, and so on. There were many posts here and all over the web about this. I would add either crowdsec or fail2ban to the mix… That’s prettt much all that there is.

    • gurapoku@lemmy.worldOPEnglish
      2·
      5 months ago

      I am still very much a noob to self-hosting, but I am not the one managing this ssh port, forgero is. Is there not any difference between the two? I think you can only access the forgejo ssh if you have a matching private key for one of the user’s public keys…

      (And although it surprised me too, I couldn’t find information about the safety of specifically this online)

      • poVoq@slrpnk.netEnglish
        4·
        5 months ago

        Git works fine over https though, no need to increase the attack surface by enabling SSH access in Forgejo.

        • gurapoku@lemmy.worldOPEnglish
          2·
          5 months ago

          That’s also a possibility, yes. Probably what I should do, taking the rest of the answers into account

      • i_am_not_a_robot@discuss.tchncs.deEnglish
        3·
        5 months ago

        There’s a lot of wrong advice about this subject on this post. Forgejo, and any other Git forge server, have a completely different security model than regular SSH. All authenticated users run with the same PID and are restricted to accessing Git commands. It uses the secure shell protocol but it is not a shell. The threat model is different. Anybody can sign up for a GitHub or Codeberg account and they will be granted SSH access, but that access only allows them to push and pull Git data according to their account permissions.

  • Guadin@k.fe.derate.me
    22·
    5 months ago

    If your forgejo host needs to connect to the outside world, you can open the port for incomming traffic only for related and established traffic. That way when somebody wants to connect to your port as a new connection it will fail. So when somebody has bad intentions, it will not work unless you’ve already connected to them in the first place. You need to permit outgoing traffic from forgejo if you block outgoing traffic.

    • gurapoku@lemmy.worldOPEnglish
      1·
      5 months ago

      I see, only allowing established traffic to connect sounds like something that could work. But I don’t know how I can do this, do you have some pointers :)?

      Blocking outgoing traffic and having to whitelist forgejo seems a bit extreme though

      • Guadin@k.fe.derate.me
        2·
        5 months ago

        Blocking outgoing traffic isn’t needed. But was mere a headsup if that is something you’ve alread setup. What router do you have? Usually when you open a port there is a dropdown menu or checkboxes for what kind of connection the port opening is allowed.

        • gurapoku@lemmy.worldOPEnglish
          1·
          5 months ago

          I’d rather not say which router I have since it would reveal quite a bit of information about me. However, I do know that the connections that my router allows are tcp and udp