Skip to content
  • MangoFly

    A self-hosted WireGuard mesh. Devices connect straight to each other; the coordination server is one binary and a SQLite file, and never sees their traffic.

    encrypted WireGuard · peer to peerLaptopbehind home NATServerin a datacentrePhoneon mobile datacoordination serverone binary · one SQLite filecontrol plane only (TLS)keys · tunnel addresses · peer lists · sealed ICE candidatesholds no private keys · carries no traffic · cannot decryptdatacontrol
  • MangoDock

    Docker management with nothing on the hosts. Reaches each daemon over an ordinary SSH session — no agent to install, no port to open.

    The MangoDock dashboard showing three host cards with container state counts, CPU and memory gauges, a usage history and recent events
  • MangoWiFi

    A Wi-Fi 6/7/8 test bench. One binary runs as Console or Agent either side of the access point under test, measuring latency under real load.

    AP under testWi-Fi 6 / 6E / 7Agentstation side · real radioLAN receiveriperf3 -sConsoleUI · orchestrates · probes
  • Blog
  • Nothing phones home

    No telemetry, no analytics, no crash reporter, no account login. Check it with a packet capture on your own network.

    Download MangoSSH
  • Project
  • Download
  • Security

    Threat model

    What MangoSSH is designed to defend, what it deliberately does not, and where the trust boundary sits. Written so the limits are as easy to find as the guarantees.

    What is being protected

    • Stored credentials — Passwords, passphrases, PINs, tokens and private keys for the hosts you save.
    • The host inventory — Hostnames, usernames, groups and per-host settings — sensitive on its own, because it is a map of your estate.
    • Live session content — Terminal, desktop and file-transfer traffic in flight between your machine and the target.
    • The evidence trail — Audit log, session recordings, terminal exports and command history, whose value depends entirely on their not having been edited.

    Where the trust boundary sits

    MangoSSH trusts your operating system user account and the machine it runs on. Everything below that line is defended; everything above it is assumed sound. This is the same boundary every desktop credential store draws, and stating it explicitly is what makes the rest of the model meaningful.

    • Inside the boundary — Files on disk, the host list, exported evidence, secrets handed to the OS credential store, and traffic leaving the machine.
    • Outside the boundary — Your logged-in session while unlocked, any process already running as you, the OS credential store's own integrity, and the target host itself.

    Threats in scope, and what answers them

    • Device loss or disk theft — The host list is AES-256-GCM encrypted at rest by Personal Vault, on by default from first launch. Secrets are never written to it — they live in Windows Credential Manager, macOS Keychain or the Linux Secret Service.
    • Network interception downgrade — strict-kex is advertised on every handshake, mitigating Terrapin (CVE-2023-48795). Strict mode removes ssh-rsa, SHA-1 key exchange, CBC ciphers and HMAC-SHA1 rather than merely deprioritising them.
    • Server impersonation — Host keys are trusted on first use and pinned; a later mismatch refuses the connection outright. Fleets running a CA can use revocation lists.
    • Credential sprawl to operators — The PAM broker connects a user without handing them the password. Just-in-time access is approved per use and expires, and policy can require a ticket reference and a one-time code from the approver.
    • Evidence tampering — Each audit line is hash-chained to the one before it, so insertion, deletion or edit is detectable. Verify Integrity re-walks the chain on demand.
    • Silent egress — Neither edition contains telemetry or crash reporting. In the Secure edition the outbound code is not compiled in, and each release greps the shipped binary for fourteen external hostnames — one match fails the build.
    • Egress via the embedded webview — A webview can egress independently of the backend, so the Secure build ships a locked content-security policy: local sources only, no outbound fetch, no framing, no form posts.

    Explicitly out of scope

    These are not oversights. They are threats a desktop client cannot answer, and claiming otherwise would make the rest of this page worth less.

    • A compromised user session — Malware running as your logged-in user can ask the OS credential store for the same secrets MangoSSH can. Encryption at rest does not help once the attacker is already you.
    • Physical access to an unlocked machine — Sensitive actions can be placed behind a Windows Hello or Touch ID gesture, but an unlocked, unattended session is not a state the application can recover from.
    • A compromised target host — If the server you connect to is owned, MangoSSH will faithfully carry your session to it. Host key pinning detects a substituted server, not a compromised legitimate one.
    • A compromised operating system — Kernel-level compromise, a malicious OS credential store or tampered platform crypto are all beneath the layer this application operates at.

    Independent assessment

    This section is intentionally empty of findings. No penetration test report or third-party security audit is published for MangoSSH at the time of writing, and summarising one that has not been published would defeat the purpose of the page. It will be filled in with the assessor, the scope, the date and the disposition of findings when there is a report to point at.

    • SOC 2 Type II — In progress.
    ← Back to security