Test a RADIUS server from Docker

You've got Docker on a NAS or a utility VM and you'd rather not install a binary on it just to check RADIUS. The probe ships as a small multi-arch image, so one docker run gives you the same real authentication test — reachability, shared secret, certificate, BlastRADIUS, and an optional login — with nothing left behind afterwards.

1. Run the test

The image is ghcr.io/authhound/probe (amd64 and arm64, so it runs on an Intel VM or an ARM NAS alike). Pass the shared secret through an environment variable so it stays off the command line:

# multi-arch distroless image — nothing installed on the host
# --network host so the server sees the host's IP, not a bridge address
docker run --rm --network host \
  -e AUTHHOUND_RADIUS_SECRET="the-secret-you-registered" \
  ghcr.io/authhound/probe radius test --server radius.corp.com

2. Add a login

A container has no terminal to prompt at, so pass the password too — still off the command line. The probe reads it from AUTHHOUND_RADIUS_PASSWORD, which is the simplest form for a throwaway --rm run:

# add a login — a container isn't interactive, so pass the password too.
# Simplest: the probe reads it from AUTHHOUND_RADIUS_PASSWORD (a bare --peap user)
docker run --rm --network host \
  -e AUTHHOUND_RADIUS_SECRET="the-secret-you-registered" \
  -e AUTHHOUND_RADIUS_PASSWORD="the-account-password" \
  ghcr.io/authhound/probe radius test --server radius.corp.com --peap alice

An environment variable is visible to anyone who can run docker inspect on the container. On a box you run this on regularly, mount the password as a file instead so it never enters the container's environment:

# more locked-down: mount the password as a file (chmod 600 on the host) so it
# isn't visible in `docker inspect` / the container's environment
docker run --rm --network host \
  -e AUTHHOUND_RADIUS_SECRET="the-secret-you-registered" \
  -v /etc/authhound/alice.pw:/run/pw:ro \
  ghcr.io/authhound/probe radius test --server radius.corp.com \
    --peap alice --password-file /run/pw

Do the same for the shared secret if you'd rather not keep it in an env var:

# or mount a secret file read-only (must not be world-readable on the host)
docker run --rm --network host \
  -v /etc/authhound/secret:/run/secret:ro \
  ghcr.io/authhound/probe radius test --server radius.corp.com \
    --secret-file /run/secret

The probe refuses a world-readable secret file on unix, so chmod 600 /etc/authhound/secret on the host first. EAP-TLS works the same way — mount the PEM cert and key and pass --client-cert/--client-key at the mounted paths.

3. Reading the result

Output is identical to the native binary — one verdict line per check. A couple of Docker-specific gotchas when it doesn't go clean:

• Everything times out. Almost always the source-IP point above: on bridge networking you registered the container's address instead of the host's. Switch to --network host, or register the host IP the server actually sees.
• DNS won't resolve inside the container. A NAS with split DNS may not pass its resolver into the container — pass the server as an host:port IP, or add --dns to the docker run.
• A real FAIL or reject is a finding about the server, not Docker — follow the next-check line, and if you have the server log, paste it into the analyzer.

For an unattended check, add --json --strict and read the exit code — see wiring the probe into scripts.

Related

• Quickstart

  Install options, registering the probe as a client, and reading verdicts and exit codes.

• Monitor from a Raspberry Pi

  The same idea, scheduled: a standing liveness check at a branch site.

• RADIUS server not responding

  When the timeout is the server or the path, not the container — how to tell them apart.