Support port forwarding directives toward Chronitons
The Chronode host should accept SSH port forwarding requests toward Chroniton containers.
This would allow developing TCP networking enabled applications, and provide a limited (though effective) capability to reach them from the outside.
For security reasons:
- Only "local" forwards are supported (i.e.
-L
arguments to the user's SSH client) - Access to port 22 on the Chroniton is prohibited (could bypass SSH access controls on the Chroniton, and create sessions that are non-recorded and non-tracked by the Chronode)
- Only forwards directed to Chronitons (by timestream name) are permitted. All other requests must be rejected to prevent use of a Chronode as an uncontrolled data relay
- "Dynamic" forwarding requests should be rejected; though recent versions of OpenSSH appear to translate these requests into sets of local forward requests on the client side, rather than transmitting those requests to the SSH server
Open questions:
- Should this be opt-in, by the owner of a Chroniton?
- Would it make sense to optionally limit forwards to the owner?
- UDP support? Not a supported mode by the SSH protocol, as far as I know.
It should be reasonably safe to automatically enable port forwarding for the Chroniton owner. There could be situations where the owner would prefer not to have unauthorized clients connect, and where that ability could violate the principle of least surprise.
Current plan is to default enable port forwarding, but restrict it to the owner. The on/off and open/owner-only modes can initially be controlled via SSH escape sequences in session control mode.
Established port forwarding sessions should be logged, and perhaps even visible as first class entities in the timestream details session view/history.
Perhaps support capturing and inspecting packet traces for these forwarded sessions (and general Chroniton generated network traffic).
From the documentation standpoint, should describe that users should probably use a separate SSH client instance to define port forwarding, and utilize the -N
client argument to the OpenSSH client, so they can see tunnel status/errors without it drawing on top of the Chronode user interface.