Can we just hardcode these values instead? They won't be useful to any programs that read them as the IP address is not an actual routable IP address (as the networking is happening in process and not through the host).

If we're just trying to expose these variables so software can detect if it's running in an SSH connection then hardcoding them seems easier and not prone to random format changes in the future

I was thinking that might not necessarily be the case with WireGuard/Tailscale.

I guess we could hardcode them, but what would we hardcode them to?

Hardcode to0.0.0.0? It's a reserved address for "this host" and is not a valid destination, so no one will try to dial it (or will fail if they do)

Typically it'd be:

SSH_CONNECTION=[client_ip] [client_port] [server_ip] 22

@spikecurtis Are you suggesting0.0.0.0 for both client and server (semantically it'd only be correct for the server)? So essentially:

SSH_CONNECTION=0.0.0.0 0 0.0.0.0 0

A bit weird, but I don't have strong feelings on what the value should be (unless wecan make it right in the wg-case, then I think we should do it).

I don't think we can make it "right" in the Wireguard case because unlike a typical Wireguard VPN, our use of it is implemented entire in-process (agent), so anything reading the IP addresses would be unable to route to them.

I don't think we can make it "right" in the Wireguard case because unlike a typical Wireguard VPN, our use of it is implemented entire in-process (agent), so anything reading the IP addresses would be unable to route to them.

That makes sense, yeah. I do think there's a chance for this to change, depending on what we want to do with wg/tailscale. For instance, direct workspace->workspace communication in a tailnet would be pretty cool.

I'll go with the hard-coded values for now, though. 👍🏻