Admin ports that open only when you do.
DE:TECTOR keeps your servers' admin ports dark until an enrolled device proves who it is. It detects who is knocking, then admits that identity, to the service it asked for, for a limited time.
Identity-aware network admission for your servers.
Most infrastructure is reachable by anyone who can guess an address. DE:TECTOR changes the starting position: the protected port stays silent. A scan finds nothing on ssh, and the services behind the firewall are not part of the public internet.
When you need in, your device asks. The request is signed with the device's key, so the server can tell who is knocking before it opens anything. It opens the service for your source address, for a limited time, and closes it again by itself. Access is something you are granted for a purpose, not a door left ajar. DE:TECTOR reduces exposure; it does not replace strong authentication on the services behind it.
The problem
Admin ports are scanned all day. Passwords and fail2ban slow attackers down, but the port is still reachable by everyone. A VPN fixes that, but it is heavy for a handful of servers and gets in the way when you travel or your home address changes. Teams end up with ssh open to the world and a log full of strangers.
DE:TECTOR gives you a door that is closed by default and, where the machine has the hardware, a key that lives in it.
Who it is for
IT and operations leads at small and mid-size EU organizations that run their own servers (VPS, on-premises, Proxmox) and expose ssh to the internet today.
How it works
A small agent runs on each Linux server and keeps ssh closed to the public internet by default. Clients (a desktop client, or a phone web page with a passkey) send signed, replay-protected admission requests.
- STEP 1Enroll
A device gets a signing key. Where the machine has a TPM 2.0 or Secure Enclave, the key is created there and cannot be exported.
- STEP 2Knock
The client sends a signed request to the server. From a phone, you sign in to the DE:TECTOR page with a passkey.
- STEP 3Open
The server verifies the request and adds your address to a firewall allow-set with an expiry.
- STEP 4Work
Your sessions run as usual. Sessions already open stay open when the admission ends.
- STEP 5Close
The entry expires on its own. Re-knock any time, or revoke a device and its admissions end.
A door closed by default
The gate lives in the server's own firewall, in a separate table that only ever adds drop rules for the protected ports. WireGuard, internal ranges and your fixed addresses always pass.
Closed by default
New ssh connections from the public internet are dropped unless the source address was admitted. Existing rules stay in place; the gate cannot weaken them.
Expiry the kernel enforces
Each entry carries a timeout enforced by the kernel. A crashed daemon does not extend access, and no one has to remember to close the door.
Quiet to strangers
The protected port stays silent. Refusals on the HTTPS endpoint are indistinguishable from an unknown page, and requests are rate limited.
Safe rollout
Start in observe mode, then enforce. Firewall changes revert on their own if you lose access, and your provider console remains the way back in.
IPv4 and IPv6
Both address families are recorded and admitted.
Fan-out across servers
One admission can be sent to your other servers over WireGuard, with no central server. A server that is down misses it; knock again when it is back.
Identity, in hardware where it exists
A device is its key. Where the machine has a TPM 2.0 or a Secure Enclave, the key is created there and cannot be exported. Machines without one use a file key, which the server flags as weaker.
Hardware-bound keys
TPM 2.0 on Windows and Linux, Secure Enclave on macOS. A copied disk does not carry the key.
Honest fallback
A file key is the fallback on machines without hardware support, and the audit log marks it as weaker.
Hardware fingerprint as a second signal
Hardware identifiers are recorded alongside the key as a signal, never as the credential.
Phone access with a passkey
A phone-friendly page shows which addresses are allowed and until when. Open, extend, or revoke with a passkey.
Follows your address
The desktop client notices when your public IP changes and re-knocks your servers, so moving from office to train to hotel does not lock you out.
Enroll and revoke
Enroll a device with a short-lived code. Revoke a device on each server; fleet-wide revocation is planned.
Starting with ssh
Version 1 protects ssh. Webmail and admin consoles are next in line.
ssh first
The first protected service is ssh, in front of whatever authentication the server already requires.
Webmail and admin consoles next
The same gate is planned for webmail and for management consoles such as Proxmox.
Audit
Every admission leaves a record.
Logged events
Every admission, refusal and expiry is logged. Passkey approvals keep their signed assertion.
Per-device history
See which device was admitted to which server, from which address, and until when.
Runs on your own servers
DE:TECTOR runs entirely on the servers it protects.
No cloud dependency
No account to create and nothing that phones home.
Specified protocol
The admission protocol is specified in an internal RFC; publication is planned.
Roadmap
These are directions, not features of the current build. Nothing here is available.
Per-service, per-person policy
Rules for who may reach which service from which kind of device, plus break-glass access with a full trail.
Second-person approval
For sensitive admissions, a second person approves through DE:SIGN.
Ledger anchoring
Optionally anchoring the audit trail in an epher ledger.
Fleet-wide revocation
Revoke a device once and have every server honor it.
Automation access (idea)
Scoped, short-lived grants for CI jobs and AI agents, so automation does not need standing credentials. Under consideration.
Planned integrations
Each Decent Edge product solves one concern and composes with the rest. None of these integrations is built or part of version 1; this is the intended direction.
- DE:PLOY
- Planned: roll DE:TECTOR out to every server by recipe.
- DE:FENDER
- Planned: receive its signals (failed knocks, anomalies) and respond with bans and alerts.
- DE:RAC
- Planned: remote access sessions start behind a DE:TECTOR admission.
- DE:SIGN
- Planned: second-person approvals and signing.
- DE:LIVER
- Planned: keep publishing access limited to enrolled devices.
- epher
- Planned: optionally anchor the audit trail in a ledger.
Where it fits
Small server estates
A few VPSs or Proxmox hosts that need admin access without a full VPN.
Travel and changing addresses
Admins who work from different networks every week re-admit themselves in seconds.
Contractors with expiring access
Admit a named person for a limited time; it ends without anyone remembering to remove it.
Audit questions
Answer "who could reach this server, from where, and until when?" from one log.
Where it sits
- Port knocking and fail2ban
Reactive and guessable. The port still exists, and a sequence or a ban list is the whole defense.
- VPN-only access
Strong, but heavy for a handful of servers: every user needs a client and a tunnel, and access is all-or-nothing once inside. It can sit alongside DE:TECTOR.
- DE:TECTOR
Identity-based, time-limited, hardware-bound where the hardware exists, and running on your own servers. It admits an identity to ssh for a time, and logs that it did.
Why it is different
- No central server. Each server decides; admissions can fan out to peers over WireGuard.
- Only removes access. The gate never accepts traffic itself; every other rule still applies.
- One new HTTPS endpoint. DE:TECTOR adds one HTTPS endpoint per server for knocks and the phone page.
- EU-built. Made by GINF Systems Kft. in Hungary, running on your own servers.
DE:TECTOR reduces exposure. It does not replace strong authentication on the services behind it: key-only ssh login is still recommended. The door opens for the right identity, and the lock behind it still matters.
Talk to us