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
  • Chapter 10 of 12

    Network Tools, Zero Trust, Import & Appearance

    The remaining features: local test servers for validating network gear, an IP scanner, a dedicated Zero Trust broker-tunnel panel, Wake-on-LAN, importing sessions from other tools, and the theme system.

    Local Test Servers (HTTP, iPerf3, RADIUS)

    Purpose

    Spin up a throwaway HTTP file server, an iPerf3 bandwidth-test server, or a real RADIUS AAA server directly from MangoSSH — for validating network gear/firewall rules/switch AAA config without standing up FreeRADIUS or a separate web server.

    How to do it

    1. Open More → Servers .
    2. HTTP : pick a Document root folder and Port (8080 default), click Start .
    3. iPerf3 : pick a Port (5201 default), click Start , then point a real iPerf3 client at this machine.
    4. RADIUS : pick a Port (1812 default) and Shared secret , add one or more Test users (username/password), click Start .
      • Supports both plain PAP and full PEAPv0/EAP-MSCHAPv2 (real 802.1X-style enterprise Wi-Fi testing, deriving real MPPE keying material, not just an Access-Accept), auto-detected by whether the incoming request carries an EAP-Message attribute.

    How to verify

    1. HTTP: browse to http:// < this-machine > :8080 from another device and confirm the document root's files list.
    2. iPerf3: run iperf3 -c < this-machine > from another device and confirm a real throughput result.
    3. RADIUS (PAP): point a switch/AP's AAA config at this server and secret, and confirm a test user's login succeeds with an Access-Accept.
    4. RADIUS (PEAP/802.1X): configure an enterprise or guest Wi-Fi SSID to use this server, and confirm the full 802.1X handshake and the WPA2/3 4-way handshake both complete — not just a RADIUS-level accept, since that's the actual proof MPPE keys came through correctly.

    Troubleshooting

    • RADIUS client gets no response at all — confirm the shared secret matches exactly on both sides and that UDP 1812 (or whatever port you set) isn't blocked by a local firewall.
    • RADIUS accepts the login but the Wi-Fi 4-way handshake fails — this points at the PEAP/MPPE path specifically rather than basic auth; confirm the AP/controller is actually configured for PEAPv0/EAP-MSCHAPv2, not a different EAP method entirely.

    IP Scanner

    Purpose

    Quickly find which hosts in a range are alive and have a given TCP port open — before adding them as saved connections, or while mapping an unfamiliar network.

    How to do it

    1. Open More → IP Scan .
    2. Enter a Range (CIDR like 192.168.1.0/24 , or a hyphenated range like 192.168.1.1-254 ), a TCP port to probe (22 for SSH, 80 for web, 445 for SMB, etc.), and a per-host Timeout .
    3. Click " n Scan" .
      • Results stream in live as a row per responding host — only hosts that actually answer appear; unresponsive addresses are simply never listed, there is no per-row "closed"/"refused" status.

    How to verify

    1. Scan a range containing a host you know is up with that port open.
      • Expect a row for it reading < port > open , the progress bar to show "done / total (pct%)" while scanning, and the summary above the results to read "N alive" as hits stream in.
    2. Let the scan finish.
      • Expect the progress bar to read "Done — N scanned in Xs" and the summary to settle on "N alive / M scanned" , and the Scan button to re-enable.
    3. Scan the same range for a port you know is closed on every host in it.
      • Expect the result list to stay empty (or show only hosts that respond to plain ping if no port narrows it down) — not rows labeled "Refused" or "Closed", since only responding hosts are ever listed at all.

    Troubleshooting

    • Nothing appears for a host you know is up — raise the Timeout value on a slow/flaky network before concluding it's down; a too-aggressive timeout drops real, reachable hosts silently rather than reporting them as "closed".

    Zero Trust Broker Tunnels (Dedicated Panel)

    Purpose

    • Set up and test a cloud-broker tunnel (AWS SSM, GCP IAP, Azure Bastion, Cloudflare Access, Teleport, Tailscale SSH) in its own panel — including a live cluster/node browser for Teleport — then push the working command straight into a saved SSH host's Delegate tab.
    • This is the setup/test workbench for the same brokers the SSH chapter's ProxyCommand quick-presets cover — use whichever entry point is more convenient; both end up configuring the same field.

    How to do it

    1. Open More → Zero Trust and pick a broker tab (AWS, GCP, Azure Bastion, Cloudflare, Teleport, or Tailscale).
    2. Fill in that broker's specific fields (e.g. AWS Instance ID + Region, or Teleport's Proxy host + a live Cluster/Node picker).
    3. Click Test to verify the tunnel actually works, then Use in SSH host to copy the resulting command into the Delegate tab of a new or existing SSH host.

    How to verify

    1. Fill in a broker's fields with real values (e.g. a real AWS Instance ID + Region, or a Teleport Proxy host with a cluster/node picked from the live picker) and click Test .
      • Expect a clear success indicator before you rely on it inside a saved host — this catches a broker-login/permission problem early, separately from any SSH-auth troubleshooting.
    2. Click " → Use in SSH host" .
      • Expect it to open (or jump to) an SSH host's Delegate tab with the resulting ProxyCommand already filled in, matching what the SSH chapter's ProxyCommand quick-presets would have produced for the same broker.
    3. Deliberately break one field (e.g. a wrong AWS Region or Teleport Proxy host) and click Test again.
      • Expect a clear failure indicator rather than a false success.

    Troubleshooting

    • Test fails — this isolates the problem to the broker CLI/login itself (see the SSH chapter's ProxyCommand troubleshooting) before you've even touched a saved host.

    Wake-on-LAN

    Purpose

    Power on a machine remotely that's configured to listen for a WoL magic packet — useful for waking a server before connecting to it.

    How to do it

    1. Open More → Wake-ON-LAN .
    2. Enter the target's MAC Address and, if needed, a specific Broadcast Address (leave blank for the default).
    3. Click Send Magic Packet .

    How to verify

    1. Enter the correct MAC address for a machine you know has Wake-on-LAN enabled and is currently powered off, leave Broadcast Address blank, and click "Send Magic Packet" .
      • Expect the machine to power on within a few seconds.
    2. Send the same packet again while the machine is already on.
      • Expect no error and no adverse effect — sending a magic packet to an already-running machine is a harmless no-op, not something that needs guarding against.
    3. Deliberately mistype one octet of the MAC address and send again.
      • Expect the target machine to stay off — confirming the packet actually is MAC-specific and not just broadcasting a generic wake-everything signal.

    Troubleshooting

    • Nothing happens — WoL must be enabled in that machine's BIOS/UEFI and its OS network adapter settings; also confirm the broadcast address actually reaches that machine's subnet (a magic packet sent to the wrong broadcast address/VLAN never arrives).

    Importing Sessions from Other Tools

    Purpose

    Bring an existing connection list in from OpenSSH's own config file, PuTTY, or MobaXterm, instead of re-typing every saved host by hand.

    How to do it

    1. Toolbar → More → Import sessions… .
    2. Pick a provider: OpenSSH (reads ~/.ssh/config ), PuTTY (reads its saved sessions from the registry on Windows, or its config files on macOS/Linux), or MobaXterm (reads MobaXterm.ini — auto-detected, or point at a specific path).
    3. Review the scanned list (one checkbox row per discovered session) and confirm which ones to bring in.

    How to verify

    Import from a tool with a known session list and confirm the count and host/port/username values match the source exactly for a few spot-checked entries.

    Troubleshooting

    • Provider finds zero sessions — confirm the source tool's config actually exists at the expected location; for MobaXterm specifically, try pointing directly at its .ini file rather than relying on auto-detect.

    Appearance — UI Mode & Themes

    Purpose

    Match MangoSSH's look to your preference or environment — a dense "Classic" mode vs. a more spacious "Modern" layout, and any of 14 built-in themes (including two glass-style themes, Nebula Glass and Daylight Glass — the default), plus a full custom theme editor.

    How to do it

    1. Open Settings → Appearance.
    2. Pick a UI mode (Modern/Classic) and a Theme from the swatch grid.
    3. For a fully custom look, open the Theme editor to override individual colors; its " n Reset" button clears your overrides back to the selected theme's own defaults.

    How to verify

    1. Switch themes from the swatch grid and confirm every open view (not just Settings itself) picks up the new colors immediately, with no leftover styling from the previous theme.
    2. Open the Theme editor, change the accent color, and click Apply .
      • Confirm the new color shows up across the app immediately.
    3. Click " n Reset" in the Theme editor.
      • Confirm your custom override is cleared and the app returns to the selected theme's original color, not a blank/unstyled state.

    Troubleshooting

    • Custom theme looks broken somewhere — use the Theme editor's " n Reset" button rather than trying to manually restore every color back to a known-good state.