1. Adding client cert and key to Chisel client.
2. Adding trusted CAs to Chisel server.
3. Adding TLS/mTLS e2e test case and test certs and keys.
4. Adding flag and help comments.
* split out share/ package into multiple subpackages
* added share/compat.go to keep backward compatibility(ish)
* moved shared tunnelling logic from client/server packages into share/tunnel/
* added remote protocol "<host>:<port>/<protocol>", currently supporting tcp and udp
* added an end-to-end test suite
* added TODO e2e tests as contribution targets
* added deep context integration for improved cleanup and cancellation
Now we can use the following command to connect to an SSH server through a chisel tunnel.
```bash
ssh -o ProxyCommand='/path/to/chisel client https://chisel.boleyn.su stdio:%h:%p' me@boleyn.su
```
- @aus's branch also includes PR for
custom headers, thanks @AkeemMcLennon (closes#90)
- support client connections via socks
- add more architectures to the built releases
- remove vendor (go.sum will enforce correct deps)
Normal port forwarding shares server ports to the client, allowing the
client to access ports on the server (or ports on other machines
accessible from the server). Sometimes, however, it is necessary to
share ports in the opposite direction, allowing the server to access
ports on the client (or ports on other machines accessible from the
client). Reverse port forwarding is analogous to ssh's -R forwarding
which complements normal -L forwarding.
Reverse port forwarding remotes are specified as
"R:<local-interface>:<local-port>:<remote-host>:<remote-port>", where
<local-interface> and <local-port> refer to the server side, and
<remote-host> and <remote-port> refer to the client side. For instance,
"R:2222:localhost:22" forwards port 2222 on the server to port 22 on the
client.
An upcoming enhancement will add reverse port forwarding support (client
sharing its ports to the server) to complement the existing port
forwarding (server sharing its ports to the client). As a first step,
introduce notation for specifying a remote for reverse port forwarding;
i.e. "R:<local-interface>:<local-port>:<remote-host>:<remote-port>".
At this stage, reverse port forwarding remotes are recognized but never
actually created. A subsequent change will flesh out the functionality.
Once started, a TCPProxy never stops listening on the specified port.
This typically isn't a problem for the command-line chisel client since
the only time a proxy should stop listening is when the client itself
terminates. However, it will become a problem when chisel eventually
supports reverse port forwarding since the proxy will instead be running
on the server side, and the server will need to tear down those
listeners when the client disconnects. Therefore, teach TCPProxy to
shutdown via context.Context cancellation.
chclient.tcpProxy is sufficiently general to handle TCP port
forwarding for both client and server. Therefore, move it to share/ so
it can be re-used by the server when chisel learns to support reverse
port forwarding, in which case the proxy will be listening on the
server rather than the client as with normal port forwarding.
Aside from minor dependencies upon chclient.Client, chclient.tcpProxy is
sufficiently general to handle TCP port forwarding beyond the client
itself. For instance, when chisel learns to support reverse port
forwarding, in which case the proxy will be listening on the server
rather than the client, it will make sense to re-use the existing proxy
code rather than duplicating it. Therefore, divorce the proxy code from
chclient.Client, freeing it up for use by the server too.
When keep-alive is enabled, Client.loop() creates a go-routine to
provide the functionality, however, the go-routine never exits, not even
when the client's SSH connection to the server has been torn down, thus
leaking the go-routine.
This typically isn't a problem for the command-line chisel client since
it is single-use; the SSH connection is torn down only when the client
is terminating anyway. However, such a go-routine leak could become
problematic if the client ever learns to manage multiple SSH connections
(perhaps, say, via an interactive mode) or when chisel is used as a
library by some other program which manages multiple connections.
Therefore, ensure that the go-routine terminates when the SSH connection
is torn down.
guangwu