Implement DevTunnel SSH-based reverse tunneling service for *.tunnel.devplace.net

Summary

Implement a new product called devtunnel that provides SSH-based reverse tunneling for *.tunnel.devplace.net. Users connect via standard OpenSSH client (no custom download) to tunnel.devplace.net:4242, authenticate with DevPlace.net credentials, and expose local services through public HTTPS subdomains. The system uses Caddy for TLS termination and reverse proxying, with a Swift backend on Linux for control plane, authentication, metrics, and session management.

Steps to Reproduce

1. User runs ssh us******@tunnel.devplace.net -p 4242 from any machine with OpenSSH.
2. SSH server prompts for DevPlace.net password and validates against DevPlace.net auth API.
3. If no remote port forwarding is specified, the server interactively asks: "What local port do you want to forward?"
4. Optionally, user can claim or auto-generate a *.tunnel.devplace.net subdomain.
5. Server generates and displays the exact SSH command to execute, including randomly allocated remote port, subdomain mapping, and keep-alive options.
6. User executes the provided command (e.g., ssh -R <random_remote_port>:localhost:<local_port> ...).
7. Server maps the public HTTPS subdomain (via Caddy) through the SSH tunnel to the user's local port.
8. Traffic flows: HTTPS request → Caddy (TLS termination) → Swift control layer → SSH tunnel → user's local service.

Expected Behaviour

• Users can expose local services via *.tunnel.devplace.net subdomains using only standard SSH commands.
• Authentication uses DevPlace.net credentials, validated server-side via API.
• Subdomains are uniquely claimed and cannot be duplicated.
• Caddy terminates TLS for *.tunnel.devplace.net and proxies to the control layer based on Host header.
• All configuration is in .env.json (ports, rate limits, max bandwidth, auth cache TTL, SSH settings, storage paths).
• Backend is server-side Swift on Linux using Vapor or equivalent with SwiftNIO.
• SSH on port 4242 handles password auth securely, interactive guidance, and command generation.
• Random remote ports are allocated per session and linked to claimed domain names.
• Public HTTPS traffic is streamed through the SSH tunnel to the user's local port (not raw port exposure).
• Auth cache stores only valid results; invalid results trigger recheck; wrong login imposes 3-second delay.
• DevPlace API returns user role; admins can view live sessions, inspect/kill tunnels.
• Rate limiting, max bandwidth per client/tunnel, and connection limits are configurable.
• Metrics endpoint and dashboard APIs expose active tunnels, bandwidth, requests, errors, per-user metrics, and live session views for admins.
• File storage uses two- or three-level hash or date/user prefix sharding for scalability.
• Users can publish applications and claim subdomains (uniqueness enforced).

Actual Behaviour

Not implemented yet.

Environment

• Product name: devtunnel
• Primary domain: *.tunnel.devplace.net
• SSH port: 4242
• Backend: Server-side Swift on Linux (Vapor or equivalent with SwiftNIO)
• TLS termination: Caddy (no restart required for new subdomains)
• Authentication: DevPlace.net username + password via SSH, validated against DevPlace.net auth API
• Configuration: .env.json
• Client requirement: Standard OpenSSH client (no custom download)

Reported by retoor via DevPlace.