Ingress rules for SSH stop working when using path

Trying to setup browser SSH through a Cloudflare Tunnel and running into issues if I use a path in my config.yml.

Browser SSH works when I do this:

tunnel: ${TUNNEL_UUID}

ingress:
  # hostname for SSH, best as tname.domain.tld/ssh
  - hostname: "sub.domain.tld"
    service: ssh://host.docker.internal:22
  
  # hostname for root domain in form domain.tld
  - hostname: "domain.tld"
    service: https://caddy:443
    originRequest:
      originServerName: "domain.tld"
  
  # hostname for everything else in form *.domain.tld
  - hostname: "*.domain.tld"
    service: https://caddy:443
    originRequest:
      originServerName: "domain.tld"
  - service: http_status:404

Browser SSH yields a 404 when I do this:

tunnel: ${TUNNEL_UUID}

ingress:
  # hostname for SSH, best as tname.domain.tld/ssh
  - hostname: "sub.domain.tld"
    path: /ssh
    service: ssh://host.docker.internal:22
  
  # hostname for root domain in form domain.tld
  - hostname: "domain.tld"
    service: https://caddy:443
    originRequest:
      originServerName: "domain.tld"
  
  # hostname for everything else in form *.domain.tld
  - hostname: "*.domain.tld"
    service: https://caddy:443
    originRequest:
      originServerName: "domain.tld"
  - service: http_status:404

Only able to put one image in my post since I’m a new user, so just trust me when I say that I’ve added ssh to the application URL in Access as well.

The only difference is the addition of a path to the first Ingress rule as well as to the Access Application.

I’m using this Docker image for cloudflared.

Using loglevel: debug, I see successes reported whenever a connection to SSH is made using the first setup or when connections to the other ingress rules are made in either setup, but nothing seems to be logged when I access sub.domain.tld/ssh in the second setup. Please let me know if any other logs would be useful.

Thanks!

And here’s the picture I couldn’t include above. Obviously in both cases I’ve inspect elemented the actual domain name out, but that’s the only change I’ve made.

ssh isn’t http, so it doesn’t have a path. The SSH session is being tunneled from Cloudflare’s edge to the origin as the SSH protocol and so the first directive works because it directs the encapsulated outer shell host and sends it to the ssh port.

Access supports 1 protocol per host, that limitation is (generally) a function of how things are unwrapped on the tunnel side.

Hmm I see, that’s unfortunate but makes sense. Guess I’ll just have to use ssh.sub.domain.tld instead.

ssh-sub.domain.tld is still a first level domain and solves issues related to SSL certificates (and also can simplify ssh.conf for using cloudflared on the client side). But yeah some kind of format for the specific hot/protocol combination can make sense.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.