How IPAuth Works — Real Use Cases

// SYSTEM BOUNDARIES

IPAuth never touches your server.

Both connections initiate from your side — your browser hits IPAuth, your server polls IPAuth. We never push anything inbound. The firewall change happens entirely inside your own boundary, by code you control.

① outbound from you

Clicking the auth URL is a normal HTTPS GET from your browser. IPAuth sees your public IP and stores it under your key.

② outbound from your server

Cron polls the server URL on a schedule you choose. Reads the IP IPAuth has stored. Nothing on your box accepts incoming connections from IPAuth.

③ entirely local

Your shell script updates ufw / pf / Windows Firewall. The change never leaves the server. Your control plane stays yours.

// PICK A USE CASE — TAP TO EXPLORE

Two ways teams use IPAuth today.

PORT 22

Lock SSH to your laptop IP

Stop brute-force noise. One bookmark to click when you switch networks. ufw allows only you.

See the SSH flow →

PORTS 80 · 443

Gate dev / staging HTTPS without a VPN

Self-service team allowlist for staging domains. Each member gets their own pair. No VPN client.

See the Web flow →

// USE CASE

Lock SSH to your laptop, even on the road.

You run 5+ servers. Exposing port 22 means constant brute-force noise in auth.log and the risk that a stolen key gets used from anywhere. IPAuth locks 22 to a single IP — yours — and follows you when you move.

Before IPAuth

Open SSH + key auth

Port 22 open to 0.0.0.0/0
Constant scanner traffic in auth.log
fail2ban does some work, but the surface is still global
Lost key = global compromise window until you notice

With IPAuth

Port 22 closed except your current IP

ufw default-deny on 22
One bookmark to click when networks change (coffee shop, hotel, home)
Within 2 minutes, ufw allows your new IP
Brute-force surface drops to one IP — your own

The script (Linux + ufw)

#!/bin/sh
SERVER_URL="https://ipauth.net/serverquery/?key=YOUR_KEY"
CURIP=$(curl --max-time 5 -fsS "$SERVER_URL" | grep -oE '"ipaddress":"[0-9.]+' | cut -d'"' -f4)
[ -n "$CURIP" ] && ufw allow from "$CURIP" to any port 22 proto tcp comment "ipauth"

Drop it in cron every 2 minutes. Done. Combine with a bastion failsafe rule (a stable IP you control as a backup recovery path) so you never lock yourself out.

Full setup for all OSes →

// USE CASE

Gate dev / staging HTTPS without a VPN.

You're running staging.mycompany.com on ports 80/443 for previews — a half-built feature your QA team wants to see, a customer demo, a marketing review URL. You don't want it indexed, scraped, or screenshotted by anyone outside the team. A VPN feels heavy. IPAuth gives each team member a personal auth URL; the staging server allows only their current IPs.

Common alternatives

VPN, basic auth, manual allowlist

VPN: heavy setup, license costs, agent installs, support burden when it breaks
Basic auth: still indexable, password gets shared / leaks, browser-blocking prompts
Manual IP list: goes stale the moment anyone hops networks

With IPAuth

Self-service team allowlist

Each team member generates their own pair
Server's firewall rule for 80/443 is driven by an ipset / multi-IP table
Anyone who hops networks just clicks their auth URL — back in within 2 min
No browser prompt, no shared password, no VPN client

Multi-user variant: ipset + iptables

Each team member has their own pair. The script reads all their server URLs and rebuilds an ipset that's referenced by an iptables rule on ports 80 + 443. Replace the KEYS list with each member's server key.

#!/bin/sh
SET=ipauth_team
KEYS="key_alice key_bob key_carol"

ipset create $SET hash:ip -exist
ipset flush $SET

for K in $KEYS; do
    IP=$(curl --max-time 5 -fsS "https://ipauth.net/serverquery/?key=$K" \
         | grep -oE '"ipaddress":"[0-9.]+' | cut -d'"' -f4)
    [ -n "$IP" ] && ipset add $SET "$IP" -exist
done

Reference the set once in iptables (paired with a default-deny for those ports):

iptables -I INPUT -m set --match-set ipauth_team src \
  -p tcp -m multiport --dports 80,443 -j ACCEPT

Cron every 2 minutes. Works the same way with nftables sets, pf tables, or Windows Firewall remote-address lists — pick the primitive your stack uses.

Full setup for all OSes →

// THE FLOW

Same three steps for any use case.

①

You click the auth URL

From any browser. IPAuth records the IP that hit it.

→

②

Your server polls the server URL

Cron / scheduled task hits it every few minutes. Reads the current registered IP.

→

③

The firewall updates

Your shell script swaps the allow rule. Any port you choose, any service.

// READY

Give it a try. It's free.

Generate a pair and wire up your first server in under 5 minutes.

Create a key pair →

Two URLs. One allowlist that follows you.