Hacker News Reader

Comment by linsomniac | Hacker News Reader

>Because all of my services share the same IP address, my password manager has trouble distinguishing which login to use for each one.

In Bitwarden they allow you to configure the matching algorithm, and switching from the default to "starts with" is what I do when I find that it is matching the wrong entries. So for this case just make sure that the URL for the service includes the port number and switch all items that are matching to "starts with". Though it does pop up a big scary "you probably didn't mean to do this" warning when you switch to "starts with"; would be nice to be able to turn that off.

View on HN

Just giving them hostnames is easier.

In homelab space you can also make wildcard DNS pretty easily in dnsmasq, assuming you also "own" your router. If not, hosts file works well enough.

There is also option of using mdns for same reason but more setup

How do I edit the hosts file of an iPhone?

You don't have to if you use mDNS. Or configure the iPhone to use your own self-hosted DNS server which can just be your router/gateway pointed to 9.9.9.9 / 1.1.1.1 / 8.8.8.8 with a few custom entries. You would need to jailbreak your iPhone to edit the hosts file.

I have a real domain name for my house. I have a few publicly available services and those are listed in public DNS. For local services, I add them to my local DNS server. For ephemeral and low importance stuff (e.g. printers) mDNS works great.

For things like Home Assistant I use the following subdomain structure, so that my password manager does the right thing:

  service.myhouse.tld
  local.service.myhouse.tld

Exactly, you don't. My qualm was with the "hosts file works well enough" claim of the person I responded to.

This is what i do.

> Just giving them hostnames is easier

Bitwarden annoyingly ignores subdomains by default. Enabling per-sudomain credential matching is a global toggle, which breaks autocomplete on other online service that allow you to login across multiple subdomains.

Tell me about it... that infinite Ctrl + Shift + L sequence circling through all credentials from all subdomains. Then you brain betrays you making you skip the right credential... ugh, now you'll circle the entire set again. Annoying.

You can override the matching method on an individual basis though, just using the setting button next to the URL entry field.

Seriously? That sounds incredibly awful - my keepass setup has dozens of domain customizations, there's no way in hell you could apply any rule across the entire internet.

You can set that globally but override at the individual entry.

"Because all of my services share the same IP address"

DNS. SNI. RLY?

That's a bit weird to read for me as well. DNS and local DNS were the first services I've been self-hosting since 2005.

On Debian/Ubuntu, hosting local DNS service is easy as `apt-get install dnsmasq` and putting a few lines into `/etc/dnsmasq.conf`.

These modern-day homelabbers will do anything to avoid DNS, looks like to them it's some kind of black magic where things will inevitably go wrong and all hell will break loose.

Not to diminish having names for everything but that just shifts the Bitwarden problem to "All of my services share the same base domain."

One cool trick is having (public) subdomains pointing to the tailscale IP.

This is what I do. Works great! And my caddy setup uses the DNS mode to provision TLS certs (using my domain provider's caddy plugin).

Could also use Cloudflare tunnels. That way:

1. your 1password gets a different entry each time for <service>.<yourdomain>.<tld>

2. you get https for free

3. Remote access without Tailscale.

4. Put Cloudflare Access in front of the tunnel, now you have a proper auth via Google or Github.

Yeesh, the last thing I want is remote access to my homelab.

Tunnels go through Cloudflare infrastructure so are subject to bandwidth limits (100MB upload). Streaming Plex over a tunnel is against their ToS.

Pangolin is a good solution to this because you can optionally self-host it which means you aren't limited by Cloudflare's TOS / limits.

Another vote for Pangolin! Been using it for a month or so to replace my Cloudflare tunnels and it's been perfect.

Also achievable with Tailscale. All my internal services are on machines with Tailscale. I have an external VPS with Tailscale & Caddy. Caddy is functioning as a reverse proxy to the Tailscale hosts.

No open ports on my internal network, Tailscale handles routing the traffic as needed. Confirmed that traffic is going direct between hosts, no middleman needed.

You can also use cloudflare to create a dns record for each local service (pointed to the local IP) and just mark it as not proxied, then use Wireguard or Tailscale on your router to get VPN access to your whole network. If you set up a reverse proxy like nginx proxy manager, you can easily issue a wildcard cert using DNS validation from your NAS using ACME (LetsEncrypt). This is what I do, and I set my phone to use Wireguard with automatic VPN activation when off my home WiFi network. Then you’re not limited by CF Tunnel’s rules like the upload limits or not being able to use Plex.

Yup doing this with Caddy and Nebula, works great!

This is the way

This is exactly what I do. I have a few operators set up in k8s that handle all of this with just a couple of annotations on the Ingress resource (yeah, I know I need to migrate to Gateway). For services I want to be publicly-facing, I can set up a Cloudflare tunnel using cloudflare-operator.

For my homelab, I setup a Raspberry Pi running PiHole. PiHole includes the ability to set local DNS records if you use it as your DNS resolver.

Then, I use Tailscale to connect everything together. Tailscale lets you use a custom DNS, which gets pointed to the PiHole. Phone blocks ads even when im away from the house, and I can even hit any services or projects without exposing them to the general internet.

Then I setup NGINX reverse proxy but that might not be necessary honestly

I wonder why each service doesn’t have a different subdomain.

This is the way. You can even do it with mDNS.

That's what I do, but you still have to change the default Bitwarden behavior to match on host rather than base domain.

Matching on base domain as the default was surprising to me when I started using Bitwarden... treating subdomains as the same seems dangerous.

It's probably a convenience feature. Tons of sites out there that start on www then bounce you to secure2.bank.com then to auth. and now you're on www2.bank.com and for some inexplicable reason need to type your login again.

Actually it's mostly financial institutions that I've seen this happen with. Have to wonder if they all share the same web auth library that runs on the Z mainframe, or there's some arcane page of the SOC2 guide that mandates a minimum of 3 redirects to confuse the man in the middle.

Setup AdGuard-Home for both blocking ads and internal/split DNS, plus Caddy or another reverse proxy and buy (or recycle/reuse) a domain name so you can get SSL certificates through LetsEncrypt.

You don't need to have any real/public DNS records on that domain, just own the domain so LetsEncrypt can verify and give you SSL certificate(s).

You setup local DNS rewrites in AdGuard - and point all the services/subdomains to your home servers IP, Caddy (or similar) on that server points it to the correct port/container.

With TailScale or similar - you can also configure that all TailScale clients use your AdGuard as DNS - so this can work even outside your home.

Thats how I have e.g.: https://portainer.myhome.top https://jellyfin.myhome.top ...etc...

This is always annoying me with 1Password, before that I just always added subdomains but now I'm usually hosting everything behind Tailscale which makes this problem even worse as the differentiation is only the port.

You can still have subdomains with Tailscale. Point them at the tailscale IP address and run a reverse proxy in front of your services

Good point, but for simplicity i'd still like 1Password to use the full hostname + port a the primary key and not the hostname.

You can use tailscale services to do this now:

https://tailscale.com/docs/features/tailscale-services

Then you can access stuff on your tailnet by going to http://service instead of http://ip:port

It works well! Only thing missing now is TLS

This would be perfect with TLS. The docs don't make this clear...

> tailscale serve --service=svc:web-server --https=443 127.0.0.1:8080

> http://web-server.<tailnet-name>.ts.net:443/ > |-- proxy http://127.0.0.1:8080

> When you use the tailscale serve command with the HTTPS protocol, Tailscale automatically provisions a TLS certificate for your unique tailnet DNS name.

So is the certificate not valid? The 'Limitations' section doesn't mention anything about TLS either:

https://tailscale.com/docs/features/tailscale-services#limit...

I think maybe TLS would work if you were to go to https://service.yourts.net domain, but I've not tried that.

It works, I’m using tailscale services with https

Thanks for clarifying :) I'll try it out this weekend.

tailscale serve 4000 --BG

Problem solved ;)

Pangolin handles this nicely. You can define alias addresses for internal resources and keep the fully private and off the public internet. Also based on WireGuard like Tailscale.

In the 1Password entry go to the "website" item. To right right there's an "autofill behavior" button. Change it to "Only fill on this exact host" and it will no longer show up unless the full host matches exactly

Not entirely true. It can't seem to distinguish between ports..

because ports don't indicate a different host.

Omg thank you, I had no idea they added this feature!

Is this a per-item behaviour or can this be set as a global default?

I'm guessing this is 1Password 8 only, as I can't see this option in 1Password 7.

I've looked in the settings on 1p8, and didn't find a setting for a global default.

Ah nice! Didn’t know that. I’ll try that out next time.

or just use the same password for everything. ;)

If it is like 12 characters non dictionary and PW you use only in your homelab - seems like perfectly fine.

If you expose something by mistake still should be fine.

Big problem with PW reuse is using the same for very different systems that have different operators who you cannot trust about not keeping your PW in plaintext or getting hacked.

not really a solution (as others have pointed out already) but it also tells me you are missing a central identity provider (think Microsoft account login). You can try deploying Kanidm for a really simple and lightweight one :)

Reply on news.ycombinator.com