Previously, authfile ACL restrictions were only checked during the
initial config handshake. This adds ACL enforcement at the tunnel
layer when processing SSH channel requests, ensuring that each
outbound connection is validated against the user's allowed addresses.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* 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.
server/handleTCPStream() is sufficiently general to handle TCP stream
functionality for both the client and server. Therefore, move it to
share/ so it can be re-used by the client when chisel learns to
support reverse port forwarding, in which case TCP stream handling
will be done by the client rather than the server.
Presently, only the server maintains connection statistics, however,
when reverse port forwarding is eventually supported by chisel, the
client will also want to do so. Rather than duplicating this
functionality in the client, generalize the existing functionality as
chshare.ConnStats, allowing it to be used by both client and server.
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.
The current implementation does not permit the reload on server configuration, this PR adds the feature permiting uses to dynamically reload config. Note, at the moment this does not kill off connection already authentication, I'll leave that to another PR
Jaime Pillora