Chisel is a fast TCP/UDP tunnel, transported over HTTP, secured via SSH.

Overview

chisel

GoDoc CI

Chisel is a fast TCP/UDP tunnel, transported over HTTP, secured via SSH. Single executable including both client and server. Written in Go (golang). Chisel is mainly useful for passing through firewalls, though it can also be used to provide a secure endpoint into your network.

overview

Features

  • Easy to use
  • Performant*
  • Encrypted connections using the SSH protocol (via crypto/ssh)
  • Authenticated connections; authenticated client connections with a users config file, authenticated server connections with fingerprint matching.
  • Client auto-reconnects with exponential backoff
  • Clients can create multiple tunnel endpoints over one TCP connection
  • Clients can optionally pass through SOCKS or HTTP CONNECT proxies
  • Reverse port forwarding (Connections go through the server and out the client)
  • Server optionally doubles as a reverse proxy
  • Server optionally allows SOCKS5 connections (See guide below)
  • Clients optionally allow SOCKS5 connections from a reversed port forward
  • Client connections over stdio which supports ssh -o ProxyCommand providing SSH over HTTP

Install

Binaries

Releases Releases

See the latest release or download and install it now with curl https://i.jpillora.com/chisel! | bash

Docker

Docker Pulls Image Size

docker run --rm -it jpillora/chisel --help

Fedora

The package is maintained by the Fedora community. If you encounter issues related to the usage of the RPM, please use this issue tracker.

sudo dnf -y install chisel

Source

$ go get -v github.com/jpillora/chisel

Demo

A demo app on Heroku is running this chisel server:

$ chisel server --port $PORT --proxy http://example.com
# listens on $PORT, proxy web requests to http://example.com

This demo app is also running a simple file server on :3000, which is normally inaccessible due to Heroku's firewall. However, if we tunnel in with:

$ chisel client https://chisel-demo.herokuapp.com 3000
# connects to chisel server at https://chisel-demo.herokuapp.com,
# tunnels your localhost:3000 to the server's localhost:3000

and then visit localhost:3000, we should see a directory listing. Also, if we visit the demo app in the browser we should hit the server's default proxy and see a copy of example.com.

Usage

$ chisel --help

  Usage: chisel [command] [--help]

  Version: X.Y.Z

  Commands:
    server - runs chisel in server mode
    client - runs chisel in client mode

  Read more:
    https://github.com/jpillora/chisel

$ chisel server --help

  Usage: chisel server [options]

  Options:

    --host, Defines the HTTP listening host – the network interface
    (defaults the environment variable HOST and falls back to 0.0.0.0).

    --port, -p, Defines the HTTP listening port (defaults to the environment
    variable PORT and fallsback to port 8080).

    --key, An optional string to seed the generation of a ECDSA public
    and private key pair. All communications will be secured using this
    key pair. Share the subsequent fingerprint with clients to enable detection
    of man-in-the-middle attacks (defaults to the CHISEL_KEY environment
    variable, otherwise a new key is generate each run).

    --authfile, An optional path to a users.json file. This file should
    be an object with users defined like:
      {
        "": ["",""]
      }
    when  connects, their  will be verified and then
    each of the remote addresses will be compared against the list
    of address regular expressions for a match. Addresses will
    always come in the form ":" for normal remotes
    and "R::" for reverse port forwarding
    remotes. This file will be automatically reloaded on change.

    --auth, An optional string representing a single user with full
    access, in the form of . It is equivalent to creating an
    authfile with {"": [""]}. If unset, it will use the
    environment variable AUTH.

    --keepalive, An optional keepalive interval. Since the underlying
    transport is HTTP, in many instances we'll be traversing through
    proxies, often these proxies will close idle connections. You must
    specify a time with a unit, for example '5s' or '2m'. Defaults
    to '25s' (set to 0s to disable).

    --backend, Specifies another HTTP server to proxy requests to when
    chisel receives a normal HTTP request. Useful for hiding chisel in
    plain sight.

    --socks5, Allow clients to access the internal SOCKS5 proxy. See
    chisel client --help for more information.

    --reverse, Allow clients to specify reverse port forwarding remotes
    in addition to normal remotes.

    --tls-key, Enables TLS and provides optional path to a PEM-encoded
    TLS private key. When this flag is set, you must also set --tls-cert,
    and you cannot set --tls-domain.

    --tls-cert, Enables TLS and provides optional path to a PEM-encoded
    TLS certificate. When this flag is set, you must also set --tls-key,
    and you cannot set --tls-domain.

    --tls-domain, Enables TLS and automatically acquires a TLS key and
    certificate using LetsEncypt. Setting --tls-domain requires port 443.
    You may specify multiple --tls-domain flags to serve multiple domains.
    The resulting files are cached in the "$HOME/.cache/chisel" directory.
    You can modify this path by setting the CHISEL_LE_CACHE variable,
    or disable caching by setting this variable to "-". You can optionally
    provide a certificate notification email by setting CHISEL_LE_EMAIL.

    --tls-ca, a path to a PEM encoded CA certificate bundle or a directory
    holding multiple PEM encode CA certificate bundle files, which is used to 
    validate client connections. The provided CA certificates will be used 
    instead of the system roots. This is commonly used to implement mutual-TLS. 

    --pid Generate pid file in current working directory

    -v, Enable verbose logging

    --help, This help text

  Signals:
    The chisel process is listening for:
      a SIGUSR2 to print process stats, and
      a SIGHUP to short-circuit the client reconnect timer

  Version:
    X.Y.Z

  Read more:
    https://github.com/jpillora/chisel

$ chisel client --help

  Usage: chisel client [options]   [remote] [remote] ...

   is the URL to the chisel server.

  s are remote connections tunneled through the server, each of
  which come in the form:

    :::/

    ■ local-host defaults to 0.0.0.0 (all interfaces).
    ■ local-port defaults to remote-port.
    ■ remote-port is required*.
    ■ remote-host defaults to 0.0.0.0 (server localhost).
    ■ protocol defaults to tcp.

  which shares : from the server to the client
  as :, or:

    R::::/

  which does reverse port forwarding, sharing :
  from the client to the server's :.

    example remotes

      3000
      example.com:3000
      3000:google.com:80
      192.168.0.5:3000:google.com:80
      socks
      5000:socks
      R:2222:localhost:22
      R:socks
      R:5000:socks
      stdio:example.com:22
      1.1.1.1:53/udp

    When the chisel server has --socks5 enabled, remotes can
    specify "socks" in place of remote-host and remote-port.
    The default local host and port for a "socks" remote is
    127.0.0.1:1080. Connections to this remote will terminate
    at the server's internal SOCKS5 proxy.

    When the chisel server has --reverse enabled, remotes can
    be prefixed with R to denote that they are reversed. That
    is, the server will listen and accept connections, and they
    will be proxied through the client which specified the remote.
    Reverse remotes specifying "R:socks" will listen on the server's
    default socks port (1080) and terminate the connection at the
    client's internal SOCKS5 proxy.

    When stdio is used as local-host, the tunnel will connect standard
    input/output of this program with the remote. This is useful when 
    combined with ssh ProxyCommand. You can use
      ssh -o ProxyCommand='chisel client chiselserver stdio:%h:%p' \
          [email protected]
    to connect to an SSH server through the tunnel.

  Options:

    --fingerprint, A *strongly recommended* fingerprint string
    to perform host-key validation against the server's public key.
	Fingerprint mismatches will close the connection.
	Fingerprints are generated by hashing the ECDSA public key using
	SHA256 and encoding the result in base64.
	Fingerprints must be 44 characters containing a trailing equals (=).

    --auth, An optional username and password (client authentication)
    in the form: ":". These credentials are compared to
    the credentials inside the server's --authfile. defaults to the
    AUTH environment variable.

    --keepalive, An optional keepalive interval. Since the underlying
    transport is HTTP, in many instances we'll be traversing through
    proxies, often these proxies will close idle connections. You must
    specify a time with a unit, for example '5s' or '2m'. Defaults
    to '25s' (set to 0s to disable).

    --max-retry-count, Maximum number of times to retry before exiting.
    Defaults to unlimited.

    --max-retry-interval, Maximum wait time before retrying after a
    disconnection. Defaults to 5 minutes.

    --proxy, An optional HTTP CONNECT or SOCKS5 proxy which will be
    used to reach the chisel server. Authentication can be specified
    inside the URL.
    For example, http://admin:[email protected]:8081
            or: socks://admin:[email protected]:1080

    --header, Set a custom header in the form "HeaderName: HeaderContent".
    Can be used multiple times. (e.g --header "Foo: Bar" --header "Hello: World")

    --hostname, Optionally set the 'Host' header (defaults to the host
    found in the server url).

    --tls-ca, An optional root certificate bundle used to verify the
    chisel server. Only valid when connecting to the server with
    "https" or "wss". By default, the operating system CAs will be used.

    --tls-skip-verify, Skip server TLS certificate verification of
    chain and host name (if TLS is used for transport connections to
    server). If set, client accepts any TLS certificate presented by
    the server and any host name in that certificate. This only affects
    transport https (wss) connection. Chisel server's public key
    may be still verified (see --fingerprint) after inner connection
    is established.

    --tls-key, a path to a PEM encoded private key used for client 
    authentication (mutual-TLS).

    --tls-cert, a path to a PEM encoded certificate matching the provided 
    private key. The certificate must have client authentication 
    enabled (mutual-TLS).

    --pid Generate pid file in current working directory

    -v, Enable verbose logging

    --help, This help text

  Signals:
    The chisel process is listening for:
      a SIGUSR2 to print process stats, and
      a SIGHUP to short-circuit the client reconnect timer

  Version:
    X.Y.Z

  Read more:
    https://github.com/jpillora/chisel

Security

Encryption is always enabled. When you start up a chisel server, it will generate an in-memory ECDSA public/private key pair. The public key fingerprint (base64 encoded SHA256) will be displayed as the server starts. Instead of generating a random key, the server may optionally specify a key seed, using the --key option, which will be used to seed the key generation. When clients connect, they will also display the server's public key fingerprint. The client can force a particular fingerprint using the --fingerprint option. See the --help above for more information.

Authentication

Using the --authfile option, the server may optionally provide a user.json configuration file to create a list of accepted users. The client then authenticates using the --auth option. See users.json for an example authentication configuration file. See the --help above for more information.

Internally, this is done using the Password authentication method provided by SSH. Learn more about crypto/ssh here http://blog.gopheracademy.com/go-and-ssh/.

SOCKS5 Guide

  1. Start your chisel server
docker run \
  --name chisel -p 9312:9312 \
  -d --restart always \
  jpillora/chisel server -p 9312 --socks5 --key supersecret
  1. Connect your chisel client (using server's fingerprint)
chisel client --fingerprint 'rHb55mcxf6vSckL2AezFV09rLs7pfPpavVu++MF7AhQ=' <server-address>:9312 socks
  1. Point your SOCKS5 clients (e.g. OS/Browser) to:
:1080
  1. Now you have an encrypted, authenticated SOCKS5 connection over HTTP

Caveats

Since WebSockets support is required:

  • IaaS providers all will support WebSockets (unless an unsupporting HTTP proxy has been forced in front of you, in which case I'd argue that you've been downgraded to PaaS)
  • PaaS providers vary in their support for WebSockets
    • Heroku has full support
    • Openshift has full support though connections are only accepted on ports 8443 and 8080
    • Google App Engine has no support (Track this on their repo)

Contributing

Changelog

  • 1.0 - Initial release
  • 1.1 - Replaced simple symmetric encryption for ECDSA SSH
  • 1.2 - Added SOCKS5 (server) and HTTP CONNECT (client) support
  • 1.3 - Added reverse tunnelling support
  • 1.4 - Added arbitrary HTTP header support
  • 1.5 - Added reverse SOCKS support (by @aus)
  • 1.6 - Added client stdio support (by @BoleynSu)
  • 1.7 - Added UDP support
Issues
  • Add encrypted password support

    Add encrypted password support

    Currently supports two encryption method: sha256 and sha512. Can be added on compile time.

    User can create a hashed password with mkpasswd --method=sha-512, Server will get the usernames and password as usual, client will supply a hashed password: chisel client --auth user:'$6$QYGHuvnm1c29b0cm$IzOCBgI39CrAphCfRHSwWkpYLGW0f7/gUUXyzjG6W6gjKdggZ3qh4x6CD7H9ixmyOHYwZaYqGdqJKSZpeSw9J1'

    Server will try to create a Crypter with the given password prefix ($5$ is sha256 and $6$ is sha512) and try to decrypt it. If a Crypter not available, it will try a plaintext authentication.

    opened by cagdasbas 18
  • add client-outbound SOCKS support

    add client-outbound SOCKS support

    In some situations, it may be useful to utilize the chisel tunnel to access the internal network of the connected client. With the recent addition of reverse port forward remotes, we can simply start a SOCKS5 server on the client and remote port forward to it.

    ~~Example:~~ (see comment below for latest syntax)

    server

    chisel server --reverse
    2019/02/09 12:54:50 server: Reverse tunnelling enabled
    2019/02/09 12:54:50 server: Fingerprint a7:39:0e:a3:78:87:9e:ba:12:12:b0:42:62:75:99:e3
    2019/02/09 12:54:50 server: Listening on 0.0.0.0:8080...
    2019/02/09 12:54:52 server: proxy#1:R:127.0.0.1:5000=>127.0.0.1:1081: Listening
    

    client

    chisel client --socks5 http://chisel-server:8080 R:127.0.0.1:5000:127.0.0.1:1081
    2019/02/09 12:54:52 client: client-side SOCKS5 server enabled
    2019/02/09 12:54:52 client: Connecting to ws://localhost:8080
    2019/02/09 12:54:52 client: Fingerprint a7:39:0e:a3:78:87:9e:ba:12:12:b0:42:62:75:99:e3
    2019/02/09 12:54:52 client: Connected (Latency 404.322µs)
    
    opened by aus 18
  • Undetected client disconnects

    Undetected client disconnects

    Hello sir Is there any Default time out from the Client as it stops working from time to time If internet connection reset it doesn't reconnect automatically can you please clarify Please.Thanks for the software is quite faster than FRP.I'm more impressed with its stability from server end.If you can help with UDP and Port Mapping for Port forwarding that would be my ultimate software with good speed more than KCP i guess keep your hard work going thanks again

    bug need-more-info 
    opened by gvsurenderreddy 13
  • every minute: client: Connection error: websocket: close 1006 (abnormal closure): unexpected EOF

    every minute: client: Connection error: websocket: close 1006 (abnormal closure): unexpected EOF

    First of all, thanks for this nice, compact, fast, stable and easy-to-use tool.

    However, there's a little issue: I use the client on a workstation which I hibernate overnight. The next day, new connections work as expected. But there seems to be a problem that the interrupted connection doesn't completely terminate:

    2019/05/28 15:49:11 client: Connection error: websocket: close 1006 (abnormal closure): unexpected EOF 2019/05/28 15:49:11 client: Retrying in 100ms... 2019/05/28 15:49:11 client: Handshaking... 2019/05/28 15:49:11 client: Fingerprint aa:bb:cc:dd:7d:44:5e:36:82:0e:9e:66:f4:f5:62:1b 2019/05/28 15:49:11 client: Sending config 2019/05/28 15:49:11 client: Connected (Latency 34.1538ms)

    The above block of messages repeats every minute

    Client: 1.3.1 chisel_windows_amd64.exe Server: have to look at home but is self-built from sources on Linux ~ same version

    opened by daald 9
  • [QUESTION] Running in Kuberneters

    [QUESTION] Running in Kuberneters

    Has anyone messed around with running chisel in kubernetes? I have a use case where pods need to securely connect to remote resources, without the use a VPN. I am able to make this work in docker, so i think I should be able to do something here.

    My thoughts were some sort of init container, which modifies outbound traffic destined for certain IP:PORTS to get redirected to the chisel container in the same pod.

    No luck so far, but was curious if anyone else had did anything remotely similar with chisel.

    opened by jseiser 8
  • Investigate issues with Minecraft

    Investigate issues with Minecraft

    Hello, I'm trying to use chisel to transport Minecraft packets (TCP-based game) over HTTP. Here's what I'm currently doing:

    # On the virtual machine running the Minecraft server:
    java -jar server.jar nogui &
    chisel server -v --port 25566 --proxy tcp://localhost:25565
    
    # On the local machine running the Minecraft client:
    chisel client -v http://server-host:25566 25567
    

    At first, the client runs out of files:

    2019/07/23 01:52:07 client: Connecting to ws://localhost:25566
    2019/07/23 01:52:07 client: proxy#1:0.0.0.0:25567=>0.0.0.0:25567: Listening
    2019/07/23 01:52:07 client: Fingerprint e1:44:44:9d:10:b1:b1:2b:fd:88:f6:9b:13:50:55:d0
    2019/07/23 01:52:07 client: Connected (Latency 1.436858ms)
    2019/07/23 01:52:43 client: proxy#1:0.0.0.0:25567=>0.0.0.0:25567: Accept error: accept tcp4 0.0.0.0:25567: accept: too many open files
    

    I increase the number of allowed open files with ulimit -n 4096, but then the client and server just "spam" open and close connections when trying to connect to the server.

    2019/07/23 02:06:16 client: proxy#1:0.0.0.0:25567=>0.0.0.0:25567: conn#1001: Open
    ... omitted
    2019/07/23 02:06:16 client: proxy#1:0.0.0.0:25567=>0.0.0.0:25567: conn#1250: Open
    2019/07/23 02:06:16 client: proxy#1:0.0.0.0:25567=>0.0.0.0:25567: conn#1250: Close (sent 34B received 0B)
    ... omitted
    2019/07/23 02:06:16 client: proxy#1:0.0.0.0:25567=>0.0.0.0:25567: conn#1001: Close (sent 34B received 0B)
    

    Is this a bug in chisel? a limitation? or some protocol kink in Minecraft? I'm trying to get to the bottom of this, but it's difficult to figure out why this is happening. It would be great if chisel could work out-of-the-box with any TCP application, Minecraft included.

    opened by Electroid 8
  • Can I utilize multiple dynos in Heroku?

    Can I utilize multiple dynos in Heroku?

    I ran across chisel today and had some spare time to try it on Heroku.

    I have 100 dynos running with different IPs but when I connect my app via Heroku Router with chisel client, it simply establishes a conn with a random dyno. I want to take advantage of multiple IPs attached to my dynos. Is there a way to instruct chisel to establish a new conn whenever a req hits the local socks, in a multitenant environment avoiding the possibility of overlapping reqs?

    Thanks.

    opened by berkant 8
  • How expose local website to internet

    How expose local website to internet

    Hi, I would like to expose my local web application (http://localhost: 8000/index.html) to internet address http://185.52.2.166:80/index.html.

    I'm trying to use chisel to do it but I'm probably wrong in the configuration.

    I ran chisel server on a cloud VM with public IP 185.52.2.166

    server

    [[email protected] tmp]# chisel server --port 80
    2020/03/19 15:58:44 server: Fingerprint a7:d9:a5:93:4d:86:d5:75:62:b4:72:93:b1:31:49:9f
    2020/03/19 15:58:44 server: Listening on 0.0.0.0:80...
    

    client (my laptop)

    [[email protected] tmp]#  ./chisel client http://185.52.2.166 8000
    2020/03/19 17:00:58 client: Connecting to ws://185.52.2.166:80
    2020/03/19 17:00:58 client: proxy#1:0.0.0.0:8000=>0.0.0.0:8000: Listening
    2020/03/19 17:00:58 client: Fingerprint 8c:f6:15:9b:f8:c6:11:f0:8f:22:b4:dc:7c:d5:8c:af
    2020/03/19 17:00:59 client: Connected (Latency 45.672614ms)
    

    I wish my application was visible on the internet with address http://185.52.2.166:80/index.html

    It's possible to do it ?

    opened by teopost 7
  • Autoroute like meterpreter

    Autoroute like meterpreter

    A autoroute feature like the one on metasploit would be really great. For example:

    1. For each client many clients are connected to the chisel server configure on a reverse proxy socks
    2. We register a route for a specific session (i.e: route 192.168.1.0/24 session 1
    3. On chisel server, there is only one port available for the socks5 and chisel we decide on which client the traffic will be sent according to the routing table.
    opened by nodauf 6
  • Server reverse mode, cannot reconnect when agent network disconnects

    Server reverse mode, cannot reconnect when agent network disconnects

    It looks like when running in reverse proxy mode, the port stays open on the server when a client abruptly disconnects (network change). When restarting the server, it can connect again. This is ofcourse not what you want do in production.

     2020/11/18 20:40:55 client: Connecting to ws://104.155.68.201:8000
     2020/11/18 20:40:56 client: Fingerprint xItxPXkfNwvTMcCl6Mgzd+SgRQVC2eLu7bTG8bxRywI=
     2020/11/18 20:40:57 client: Connection error: server: Server cannot listen on R:52081=>192.168.0.78:554
     2020/11/18 20:40:57 client: Give up
    
    opened by cedricve 6
  • 1.7.0-rc9 out and err streams are mixed up

    1.7.0-rc9 out and err streams are mixed up

    Hello!

    I tried 1.7.0-rc9 version cause of TLS ignore feature (that is important for me, thanx for it!) And I noticed that out and err streams are mixed up on win 10 I tired with the next command:

    chisel client -v --tls-skip-verify --auth test:test https://my-test.host.local 127.0.0.1:2222:127.0.0.1:3333 1> d:\out.txt 2> d:\err.txt
    
    opened by nosf3rat 6
  • Crash with port scanner

    Crash with port scanner

    When running chisel as a reverse socks proxy with a port scanner, the server crashes with the following messages:

    accept4: too many open files and Stream error: ssh: unexpected packet in response to channel open: <nil> The server runs with: chisel server -p PORT --reverse --socks5 The client: chisel client IP:PORT R:socks

    and the port scanner is naabu (https://github.com/projectdiscovery/naabu) running with:

    naabu -s connect -p - --exclude-ports 22 -host IP -proxy 127.0.0.1:1080

    The chisel's server version is 1.7.4-0kali1, the client's one is 1.7.7_linux_386.

    Here is a more complete stack trace:

    `➜ ~ chisel server -p 443 --reverse --socks5 2022/08/03 20:17:59 server: Reverse tunnelling enabled 2022/08/03 20:17:59 server: Fingerprint 6wKlRlcflpJKXqpdABDOc8GANiXRlavVxtbNbcWYQqM= 2022/08/03 20:17:59 server: Listening on http://0.0.0.0:443 2022/08/03 20:18:01 server: session#1: Client version (1.7.7) differs from server version (0.0.0-src) 2022/08/03 20:18:01 server: session#1: tun: proxy#R:127.0.0.1:1080=>socks: Listening

    2022/08/03 20:20:10 server: session#1: tun: proxy#R:127.0.0.1:1080=>socks: Accept error: accept tcp 127.0.0.1:1080: accept4: too many open files 2022/08/03 20:20:10 server: session#1: tun: proxy#R:127.0.0.1:1080=>socks: conn#80847: Stream error: ssh: unexpected packet in response to channel open: 2022/08/03 20:20:10 server: session#1: tun: proxy#R:127.0.0.1:1080=>socks: conn#80852: Stream error: ssh: unexpected packet in response to channel open: 2022/08/03 20:20:10 server: session#1: tun: proxy#R:127.0.0.1:1080=>socks: conn#80846: Stream error: ssh: unexpected packet in response to channel open: ...`

    Interestingly enough, the same kind of scan doesn't crash when using nmap (I am guessing there is less threads).

    opened by alexploit 1
  • runtime error: invalid memory address or nil pointer dereference

    runtime error: invalid memory address or nil pointer dereference

    v1.7.7

    2022/06/30 09:36:28 http: panic serving 127.0.0.1:35814: runtime error: invalid memory address or nil pointer dereference
    goroutine 2786 [running]:
    net/http.(*conn).serve.func1()
            net/http/server.go:1802 +0xb9
    panic({0x7faa80, 0xba68b0})
            runtime/panic.go:1047 +0x266
    github.com/jpillora/chisel/server.(*Server).handleWebsocket(0xc0000a8320, {0x8fff80, 0xc00019c460}, 0xc00010ae00)
            github.com/jpillora/chisel/server/server_handler.go:94 +0x463
    github.com/jpillora/chisel/server.(*Server).handleClientHandler(0xc0000a8320, {0x8fff80, 0xc00019c460}, 0xc00010ae00)
            github.com/jpillora/chisel/server/server_handler.go:24 +0x129
    net/http.HandlerFunc.ServeHTTP(0x0, {0x8fff80, 0xc00019c460}, 0x46204e)
            net/http/server.go:2047 +0x2f
    net/http.serverHandler.ServeHTTP({0xc00037f860}, {0x8fff80, 0xc00019c460}, 0xc00010ae00)
            net/http/server.go:2879 +0x43b
    net/http.(*conn).serve(0xc00007c280, {0x9021a0, 0xc0000720c0})
            net/http/server.go:1930 +0xb08
    created by net/http.(*Server).Serve
            net/http/server.go:3034 +0x4e8
    
    opened by xtqxk 0
  • Ldap authentication

    Ldap authentication

    This PR is to allow LDAP authentication of chisel client. The chisel server ldap configuration is maintained in a file pointed by the --ldap-config option The ldap-config file structure is as follow: BindDN for non anonymous search BindPassword for non anonymous search Url ldap server url BaseDN for search Filter ldap objects filter IDMapTo ldap attribute used as id CA file containing the PEM formatted certificates to trust when connecting to ldap server Insecure true if we skip the certificates validation

    The users are authentication against the ldap server. The authorization pattern is unchanged (in authfile) In the auth file we maintain the userid and the remotes. The password is left to an empty string

    opened by jdoucerain 0
  • Require/generate --auth username:$(random password...) by default

    Require/generate --auth username:$(random password...) by default

    Considering the power of the tunnel that chisel creates (it gives access to all localhost ports by default, without authentication!) it would be prudent to force users to supply some sort of credentials by default when starting the chisel server.

    When starting the server without --auth, it should autogenerate some credentials.

    Alternatively, maybe there could be a simpler way to specify authorization rules than the users.json file. I think whiltelisting should be used for ports, so that by default, no ports are accessible.

    We can use chisel to ssh into servers from within restrictive networks that only allow http traffic. But for that purpose, we only need access to port 22 on the server running chisel server, not all the rest of ports.

    enhancement 
    opened by Masterxilo 1
Releases(v1.7.7)
Owner
Jaime Pillora
Jaime Pillora
Go HTTP tunnel is a reverse tunnel based on HTTP/2.

Go HTTP tunnel is a reverse tunnel based on HTTP/2. It enables you to share your localhost when you don't have a public IP.

Michal Jan Matczuk 2.9k Jul 29, 2022
UDP Transport: compress, encrypt and send any data reliably over unreliable UDP connections

udpt UDP Transport Compresses, encrypts and transfers data between a sender and receiver using UDP protocol. Features and Design Aims: Avoid the overh

Ali Bala 41 Jul 30, 2022
UDP output for beats to send events over UDP.

beats-udp-output How To Use Clone this project to elastic/beats/libbeat/output/ Modify elastic/beats/libbeat/publisher/includes/includes.go : // add i

ichx 0 Dec 11, 2021
GO Simple Tunnel - a simple tunnel written in golang

GO Simple Tunnel GO语言实现的安全隧道 English README !!!V3版本已经可用,欢迎抢先体验!!! 特性 多端口监听 可设置转发代理,支持多级转发(代理链) 支持标准HTTP/HTTPS/HTTP2/SOCKS4(A)/SOCKS5代理协议 Web代理支持探测防御 支

ginuerzh 9.3k Aug 1, 2022
Send network packets over a TCP or UDP connection.

Packet is the main class representing a single network message. It has a byte code indicating the type of the message and a []byte type payload.

Aero 71 Jul 15, 2022
Golang pow implementation client <-> server over UDP and TCP protocols

Client <-> server over UDP and TCP pow protocol Denial-of-Service-attacks are a typical situation when providing services over a network. A method for

Nikita Kryuchkov 0 Jan 13, 2022
Simple HTTP tunnel using SSH remote port forwarding

Simple HTTP tunnel using SSH remote port forwarding

Skye L. 20 Apr 17, 2022
HTTP tunnel over Websocket

WS PROXY This is a reverse HTTP proxy over websockets. The aim is to securely make call to internal APIs from outside. How does it works a WSP client

root.gg 77 Jun 8, 2022
Multiplexer over TCP. Useful if target server only allows you to create limited tcp connections concurrently.

tcp-multiplexer Use it in front of target server and let your client programs connect it, if target server only allows you to create limited tcp conne

许嘉华 3 May 27, 2021
TCP output for beats to send events over TCP socket.

beats-tcp-output How To Use Clone this project to elastic/beats/libbeat/output/ Modify elastic/beats/libbeat/publisher/includes/includes.go : // add i

ichx 1 May 20, 2022
Gogrok is a self hosted, easy to use alternative to ngrok. It uses SSH as a base protocol, using channels and existing functionality to tunnel requests to an endpoint.

gogrok A simple, easy to use ngrok alternative (self hosted!) The server and client can also be easily embedded into your applications, see the 'serve

Tyler Stuyfzand 5 Jun 15, 2022
Toy gRPC Tunnel over CloudFlare (Proof of Concept)

gun You know what it means. Guide Server Go to your domain in CloudFlare. In "Network" tab, turn on gRPC.

Qv2ray Workgroup 142 Aug 2, 2022
🤘 The native golang ssh client to execute your commands over ssh connection. 🚀🚀

Golang SSH Client. Fast and easy golang ssh client module. Goph is a lightweight Go SSH client focusing on simplicity! Installation ❘ Features ❘ Usage

Mohamed El Bahja 1.1k Jul 27, 2022
Extended ssh-agent which supports git commit signing over ssh

ssh-agentx ssh-agentx Rationale Requirements Configuration ssh-agentx Configuration ssh-gpg-signer Linux Windows Signing commits after configuration T

Wim 10 Jun 29, 2022
Golang `net/rpc` over SSH using installed SSH program

Golang net/rpc over SSH using installed SSH program This package implements a helper functions to launch an RPC client and server. It uses the install

null 0 Nov 5, 2021
one simple git ssh server (just for learning git over ssh )

wriet one simple git ssh server use golang write one simple git ssh server how to running starting service docker-compose up -d add authorized_keys i

rong fengliang 2 Mar 5, 2022
The devs are over here at devzat, chat over SSH!

Devzat Where are the devs at? Devzat! Devzat is chat over SSH Try it out: ssh sshchat.hackclub.com Add this to ~/.ssh/config: Host chat HostName s

Ishan Goel 1.4k Jul 29, 2022
Gsshrun - Running commands via ssh on the server/hosting (if ssh support) specified in the connection file

Gsshrun - Running commands via ssh on the server/hosting (if ssh support) specified in the connection file

Məhəmməd 3 Jun 9, 2022