Files
alknet/docs/architecture/decisions/006-no-logging-of-tunnel-destinations.md
glm-5.1 596c89ce24 refactor!: rebrand wraith to alknet
Rename all crates, CLI commands, constants, type names, doc comments,
and documentation from wraith to alknet. Includes wire-protocol changes:
ALPN wraith-ssh -> alknet-ssh, reserved destination prefix wraith- ->
alknet-, SSH auth username wraith -> alknet.
2026-06-05 10:04:32 +00:00

2.1 KiB

ADR-006: No Logging of Tunnel Destinations

Status

Accepted

Context

An SSH tunnel server sees every destination that clients connect to — hostnames, IP addresses, port numbers. This is extremely sensitive information. Logging it creates:

  • Privacy risks: Tunnel destinations reveal what services users access (internal databases, APIs, etc.)
  • Legal concerns: Server operators may be pressured to produce logs showing what clients accessed
  • Data retention liability: Stored destination logs are an attack surface (data breaches, subpoenas)

However, the server does need to log some information for operational purposes — particularly for fail2ban integration to detect and block abusive connections.

Decision

The server does NOT log:

  • channel_open_direct_tcpip destinations (host, port)
  • DNS resolutions performed by the server on behalf of clients
  • Bytes transferred through tunnel channels
  • Connection duration or throughput

The server DOES log (ADR-013):

  • Auth attempts (remote_addr, user, key_fingerprint, accept/reject)
  • Connection opened (remote_addr, transport kind)
  • Connection closed (remote_addr, duration)

This separation ensures fail2ban has enough data to detect abusive IPs while destination privacy is maintained.

Consequences

  • Positive: Tunnel destinations are never written to disk or any observable log. This is the same guarantee OpenSSH makes with LogLevel VERBOSE or below.
  • Positive: Reduces legal and privacy exposure for server operators.
  • Positive: fail2ban can still work — it needs source IPs and auth failures, not destinations.
  • Negative: Server operators cannot audit what destinations clients are accessing. If an operator needs this for compliance, they must implement it outside alknet (e.g., network-level logging at the target host).
  • Negative: Debugging connectivity issues is harder without destination logs. Mitigated by client-side logging (the client knows what it's connecting to).

References