upvote
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

reply
> 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.

reply
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.
reply
This is what i do.
reply
How do I edit the hosts file of an iPhone?
reply
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.
reply
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
reply
"Because all of my services share the same IP address"

DNS. SNI. RLY?

reply
Not to diminish having names for everything but that just shifts the Bitwarden problem to "All of my services share the same base domain."
reply
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`.

reply
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.
reply
One cool trick is having (public) subdomains pointing to the tailscale IP.
reply
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).
reply
or just use the same password for everything. ;)
reply
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.

reply
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.

reply
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.
reply
Yup doing this with Caddy and Nebula, works great!
reply
Tunnels go through Cloudflare infrastructure so are subject to bandwidth limits (100MB upload). Streaming Plex over a tunnel is against their ToS.
reply
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.
reply
Yeesh, the last thing I want is remote access to my homelab.
reply
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.
reply
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

reply
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...

reply
I think maybe TLS would work if you were to go to https://service.yourts.net domain, but I've not tried that.
reply
It works, I’m using tailscale services with https
reply
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
reply
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.
reply
You can still have subdomains with Tailscale. Point them at the tailscale IP address and run a reverse proxy in front of your services
reply
Good point, but for simplicity i'd still like 1Password to use the full hostname + port a the primary key and not the hostname.
reply
tailscale serve 4000 --BG

Problem solved ;)

reply
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...

reply
I wonder why each service doesn’t have a different subdomain.
reply
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.

reply
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.

reply
This is the way. You can even do it with mDNS.
reply
Ah nice! Didn’t know that. I’ll try that out next time.
reply