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)
Although reverse port forwarding (sharing client ports with the server)
should not generally leak any resources from the server to the client,
the facility may nevertheless be abused if the client is able to open a
server port which is otherwise meant for some other purpose on the
server. (This might happen, for instance, if a service on the server has
crashed or becomes somehow disabled, thus freeing the port which would
otherwise be occupied by the service.)
To mitigate such potential abuse, disable reverse port forwarding by
default and introduce server option --reverse to enable it explicitly.
Additionally, subject reverse port forwarding remotes to server-side
--authfile restrictions (for instance, "^R:0.0.0.0:7000$").
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.