Giter Site home page Giter Site logo

chisel's Introduction

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

Table of Contents

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 install github.com/jpillora/chisel@latest

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, (deprecated use --keygen and --keyfile instead)
    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).

    --keygen, A path to write a newly generated PEM-encoded SSH private key file.
    If users depend on your --key fingerprint, you may also include your --key to
    output your existing key. Use - (dash) to output the generated key to stdout.

    --keyfile, An optional path to a PEM-encoded SSH private key. When
    this flag is set, the --key option is ignored, and the provided private key
    is used to secure all communications. (defaults to the CHISEL_KEY_FILE
    environment variable). Since ECDSA keys are short, you may also set keyfile
    to an inline base64 private key (e.g. chisel server --keygen - | base64).

    --authfile, An optional path to a users.json file. This file should
    be an object with users defined like:
      {
        "<user:pass>": ["<addr-regex>","<addr-regex>"]
      }
    when <user> connects, their <pass> 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 "<remote-host>:<remote-port>" for normal remotes
    and "R:<local-interface>:<local-port>" 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 <user:pass>. It is equivalent to creating an
    authfile with {"<user:pass>": [""]}. 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 LetsEncrypt. 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] <server> <remote> [remote] [remote] ...

  <server> is the URL to the chisel server.

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

    <local-host>:<local-port>:<remote-host>:<remote-port>/<protocol>

    ■ 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 <remote-host>:<remote-port> from the server to the client
  as <local-host>:<local-port>, or:

    R:<local-interface>:<local-port>:<remote-host>:<remote-port>/<protocol>

  which does reverse port forwarding, sharing <remote-host>:<remote-port>
  from the client to the server's <local-interface>:<local-port>.

    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: "<user>:<pass>". 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).

    --sni, Override the ServerName when using TLS (defaults to the 
    hostname).

    --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 file, using the --keyfile option. 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 with Docker

  1. Print a new private key to the terminal

    chisel server --keygen -
    # or save it to disk --keygen /path/to/mykey
  2. Start your chisel server

    jpillora/chisel server --keyfile '<ck-base64 string or file path>' -p 9312 --socks5
  3. Connect your chisel client (using server's fingerprint)

    chisel client --fingerprint '<see server output>' <server-address>:9312 socks
  4. Point your SOCKS5 clients (e.g. OS/Browser) to:

    <client-address>:1080
    
  5. 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
  • 1.8 - Move to a scratchDocker image
  • 1.9 - Switch from --key seed to P256 key strings with --key{gen,file} + bump to Go 1.21 (by @cmenginnz)

License

MIT © Jaime Pillora

chisel's People

Contributors

anacrolix avatar andres-portainer avatar archimoebius avatar astravexton avatar aus avatar c-f avatar codenoid avatar dependabot[bot] avatar deviantony avatar fabaff avatar fsiegmund avatar gambol99 avatar guillaumesmaha avatar iineva avatar jpillora avatar masterxilo avatar maurerr avatar meteorite avatar nitesculucian avatar noahsbwilliams avatar patrick-othmer avatar pbstriker38 avatar rajpratik71 avatar shawnhwei avatar srueg avatar sunshineco avatar taknok avatar testwill avatar xtyxtyx avatar zuzgon avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

chisel's Issues

[Feature request] Client stdio mode

Hi,
It would be useful to be able to run the client in 'stdio' mode - that way it can be used as a ProxyCommand for SSH, eg

ssh -o ProxyCommand='chisel client mychiselserver stdio:%h:%p' myuser@somehost

Transferring files

I have chisel set up successfully and I've established an SSH tunnel between a remote host and my developer machine. I'm connected to the host using a webterm (https://github.com/chjj/tty.js).

I'm wondering if it's possible to use chisel to transfer files to and from my dev machine to the remote host?

Is it possible to set my machine up so that I can scp files to and from these machines, transferring the files using the tunnel that gets set up?

Option to stop retries after hard timeout limit

It would be nice to have a client option to limit the retries to a specified amount of time, so it does not retry indefinitely.
This is useful to monitor the connection of "daemonized" tunnels; one can set-up a bash script which opens the tunnel, and if chisel exists (because it fails to re-establish the connection in x amount of time) e.g. an alert email could be sent.
Currently chisel does not exit and tries to reconnect forever, which is hard to monitor from bash scripts.

[Feature Request] Remote port forwarding

Hi, Thanks for all your good work. @jpillora and @morikat

Since ssh channels are used, is it possible to add remote port forwarding in the future?
Something like ssh clients do.

 -R [bind_address:]port:host:hostport
         Specifies that the given port on the remote (server) host is to
         be forwarded to the given host and port on the local side.

Problem in OpenShift

I'm trying to run chisel server on an OpenShift application but it fails. I think this is because Apache is listening on port 8080 by default (not sure).

Command:

./chisel server --host $OPENSHIFT_GO_IP --port $OPENSHIFT_GO_PORT --proxy http://example.com

Error:

bind: address already in use

Demo not working

I'm trying to get started with chisel by running the demo but I can't get client to connect.

~> docker run --rm -it jpillora/chisel client https://chisel-demo.herokuapp.com 3000
2016/06/28 10:15:58 client: Connecting to wss://chisel-demo.herokuapp.com:443
2016/06/28 10:15:59 client: Retrying in 100ms...
2016/06/28 10:16:00 client: Retrying in 200ms...
2016/06/28 10:16:01 client: Retrying in 400ms...
2016/06/28 10:16:02 client: Retrying in 800ms...
2016/06/28 10:16:04 client: Retrying in 1.6s...
2016/06/28 10:16:06 client: Retrying in 3.2s...

I can browse to the webpage in browser and get example.com output however.

Binary Installation Issue on Ubuntu

On Ubuntu 16.04 there appears to be a conflict when installing via dpkg -i . The binary tries to install a file named test under /usr/bin but /usr/bin/test already exists as part of coreutils. Perhaps renaming to something more descriptive (and unique) would be better.

[Feature Request] Support client --authfile

Dose chisel client support --authfile ?
I would prefer chisel read configure file from disk. and do not want other user view the password .

The current -auth put username and password on command line argument. when using ps -aux | grep chisel , you will see the password.
It might be not safe

Default server local-host to localhost

ssh -L defaults to exposing the tunnel locally on localhost. If a chisel server is providing access to a port on its localhost, it seems like having the client keep its end of the tunnel on localhost is a safe default. As a user coming from ssh tunnelling, this not being the case was an unexpected difference.

[RFC] Add conn pool for client

To gain better connect performance, can we add conn pool for client?

The current client, will dial remote when need.
It's ok, but not very fast.
If there be conn pool. it will gain better performance.

dpkg: error processing archive chisel_1.1.3_amd64.deb (--install)

vultr ~ # wget https://github.com/jpillora/chisel/releases/download/1.1.3/chisel_1.1.3_amd64.deb
vultr ~ # sudo dpkg -i chisel_1.1.3_amd64.deb
(Reading database ... 94889 files and directories currently installed.)
Preparing to unpack chisel_1.1.3_amd64.deb ...
Unpacking chisel (1.1.3) ...
dpkg: error processing archive chisel_1.1.3_amd64.deb (--install):
 trying to overwrite '/usr/bin/test', which is also in package coreutils 8.25-2ubuntu2
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 chisel_1.1.3_amd64.deb

[Feature request] Option to custom HTTP header in client

Hi.
Add please option custom HTTP header in client.These settings help many bypass the firewall.
User-Agent:CustomAgent
Host:CustomHost
X-Forwarded-Host:CustomHost

The current settings for bypassing the firewall are very bad -
User-Agent:Go-http-client/1.1

Please add this option.
I think to you many will say thank you.
And your program will be the best.

[Feature Request] TLS and Lets Encrypt Support

I want to support manual TLS with certs and automatic with Let's Encrypt (see acmewrapper. However, this would require a tls.json file (or a set of files) to store TLS state, and with Let's Encrypt you'd also need to specify a hostname and you'd be restricted to port 80/443. All of this adds complexity so, I ended up leaving TLS support out for now. Since the SSH protocol is already performing full authentication and encryption, I see TLS as an optional nice to have.

Encrypting the keys using the server key then storing them encrypted out in the open, in a public database somewhere might work... First I'd need to use a proper PBKDF for the server key.

Please mention any comments/ideas you have below

Unrecoverable ssl handshake error

During chisel's normal operation, I had this error:

ssh: handshake failed: websocket: close 1006 (abnormal closure): unexpected EOF

The client is on a bad network so that's probably what caused the error. The problem is that the tunnel went down for good and chisel didn't stop ether.

If this kind of fatal error occurs, can you either:

  • try / catch and retry to open the tunnel
  • exit the process with a non-null exit code so that it may be restarted

Can it be related to this code ?
https://github.com/jpillora/chisel/blob/master/client/client.go#L160

Specify hostname in client mode

I'm using nginx to proxy requests to chisel, there are several benefits if users can change the hostname of server address

  • proxy by any hostname you want, without register a domain or change DNS records. Useful when you have lots of chisel backends with one entry server.
  • no DNS query (which is clear text) was sent, man-in-the-middle could not get the hostname, it's more secure.

Probable usage:

$ chisel client --hostname mydomain.com https://1.2.3.4 3000

the --hostname parameter will override the default server hostname.

[Feature Request] Allow clients to be proxy endpoints

Issue #8 mentions problems with reaching clients behind HTTP-only NAT/firewalls. Allowing a client to be a proxy endpoint would provide access to the client via the chisel server. For example, client A connects to client B via server:

[client A] <-> [server] <-> [client B] <-> ...

Possible API:

chisel server <server options>
#client B
chisel client --proxy B <client options> <server address>
#client A
chisel client <client options> <server address> B@3000

Where B@3000 is in the format <proxy name>@<chisel remote>

[Feature request] Any interest in server supporting many-to-many connections for remote mgt of IOT devices or other use cases?

My use case is being able to SSH into 1000's of embedded devices that are behind a firewall. I've been looking at creating a supervisor app for your server that would listen on a std port for connection requests from devices, and then create new instances respectively. The supervisor app would also need to provide some sort of directory service to clients wishing to connect to devices.

[Feature Request] Add connection timeouts

After a while not using the chisel connections(30minutes).
The connections dead and seems not accessable.

2016/03/25 05:36:14 client: ghp:8123#1: conn#104: Close (sent 47380 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#507: Close (sent 0 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#512: Close (sent 0 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#517: Close (sent 233 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#514: Close (sent 0 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#509: Close (sent 0 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#510: Close (sent 0 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#515: Close (sent 215 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#516: Close (sent 223 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#504: Close (sent 207 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#505: Close (sent 233 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#518: Close (sent 207 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#513: Close (sent 0 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#519: Close (sent 207 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#506: Close (sent 0 received 0)
2016/03/25 05:36:40 client: ghp:8123#1: conn#511: Close (sent 0 received 0)

The connection was dead. and can not read any data.

I forced kill the progress. and run again . the connection working well.

so please add dead connection detect, when the connection is dead, can not read any data for a limit time(3-30s). please disconnect and reconnect it .

Thanks.

[Feature Request] Automatically reload auth file

This feature assumes connections will be broken if server is restarted.

This would come in handy for building the auth file programmatically from a separate data source to avoid.

There's three ways we could do it in increasing levels of complexity:

  1. Reload every x second regardless
  2. Catch SIGUSR1 to trigger a reload
  3. Use inotify to trigger a reload when the file changes

Not sure which will be best.

Chisel client behind a proxy

Hi,

I can't seem to find the option to specify an upstream proxy on the client side. The objective would be to support a chisel client that has to connect through an authenticated (NTLM) proxy in order to connect to the chisel server.

Any options ?
Thanks.
Arno

connect the client to multiple servers

Currently, with 1.2, multiple clients instances are needed to connect to multiple servers.
Although #9 would aid in this in the sense that instead of running multiple server you would run a router and multiple clients proxying endpoints so maybe multiple servers per client is not a necessary feature.

[Feature Request] Add support for an http proxy

Thanks for all your work !
I use Chisel Client in Windows 7. Internet connection of our company runs through a proxy.
Chisel Client does not seem to support a http proxy (I tried to set HTTP_PROXY in ENV).
Did I miss a point ? Do you see a possibility to get it working ?

[Support] Help with socks5 on Heroku

Hello.
I trying:

~/bin $ ./chisel_linux_amd64 server --port 9312 --socks5
2017/08/27 18:08:00 server: SOCKS5 Enabled
2017/08/27 18:08:00 server: Fingerprint 2b:01:b4:8b:26:a5:24:5a:e2:b8:02:fa:58:96:ee:35
2017/08/27 18:08:00 server: Listening on 9312

but got

./chisel_linux_amd64 client --fingerprint 2b:01:b4:8b:26:a5:24:5a:e2:b8:02:fa:58:96:ee:35  https://pacific-refuge-52999.herokuapp.com:9312 1080:socks
2017/08/27 21:10:49 client: Connecting to wss://pacific-refuge-52999.herokuapp.com:9312
2017/08/27 21:10:49 client: tunnel#1 127.0.0.1:1080=>socks: Listening
2017/08/27 21:10:50 client: Retrying in 100ms...
2017/08/27 21:10:52 client: Retrying in 200ms...
2017/08/27 21:10:53 client: Retrying in 400ms...
2017/08/27 21:10:55 client: Retrying in 800ms...
2017/08/27 21:10:57 client: Retrying in 1.6s...

What am I doing wrong?

telnet pacific-refuge-52999.herokuapp.com 9312
Trying 23.23.116.0...
Trying 23.21.155.56...
Trying 23.23.120.204...
Trying 23.23.117.76...
Trying 23.21.142.10...
Trying 23.21.45.51...
Trying 23.21.181.176...
Trying 23.23.126.158...
telnet: Unable to connect to remote host: Connection refused

[Feature request] Fallback to HTTP when web sockets aren't available

@jpillora I need to tunnel https/http over an http connection specifically to GAE. Using this project would be ideal, however GAE doesn't yet support web sockets. Is there a way to fall back to HTTP when web sockets aren't available?

I know this isn't nearly as natural, but at least in our firewall environment I can only hit an http endpoint without ws support.

Question

Hi, this is a really neat project you've hacked together. Just out of curiosity, if you're controlling clients and servers on both ends why don't you just tunnel tcp via a tls channel and be done with it? Why do you need HTTP in there at all?

Zero-downtime deployment of Chisel

First off, let me begin by saying that Chisel is a brilliant little project for accomplishing a lot of useful tasks. I personally use Chisel to tunnel SSH traffic to containers and VMs.

However, this got me thinking- how do you propose to achieve zero-downtime maintenance and deployment of the chisel server? If there are existing tunnels already created and active, would it be possible to switch the connections over to the new chisel server instance?

https/ws transport instead of http/ws/ssh?

is there a possibility to drop ssh an use plain web sockets over https? in other words, why is this using http, websocket and ssh instead of just https and websocket?

vpn over chisel

Is there an option to use the tun/tap devices with ssh to have a vpn implemented over chisel instead of doing port forwarding?

Add soms user scenario samples please

Hi, its hard to understand what chisel does and does not do.
Is it possible to add some user scenario examples on the readme please?

If I understand correctly you can use chisel to:

  • set up a proxy on the internet that allows you to connect to ports your firewall blocks
  • set up your own socks proxy on the internet somewhere so you can make connections to internet sites that you are not allowed to go to by a firewall

You cannot use chisel to:

  • remotely login into a desktop say on your work behind corporate firewall, like you can with logmein hamachi or other remote login services

panic: ssh: no key material for msgNewKeys

Client get crashed after running about 3 minutes while the download speed is about 25MB/s, I'm testing locally with wget.

System: ubuntu 16.04 64 bit (Linux desktop 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux)

Desktop lan ip is 192.168.9.162, port 80 is served by nginx for file download.

Server command: chisel server -v --port 3000 --proxy http://example.com

Client command: chisel client -v --keepalive=10s http://192.168.9.162:3000 8001:80

Download test command: wget http://192.168.9.162:8001/dl/00002.m2ts

chisel client crash log:

2017/02/03 20:50:39 client: Disconnected
2017/02/03 20:50:39 client: Fingerprint a4:59:fb:8a:fd:93:b5:0a:2e:08:9c:15:38:b3:1d:44
2017/02/03 20:50:39 client: Sending configurating
2017/02/03 20:50:39 client: Connected (Latency 333.839µs)
2017/02/03 20:50:42 client: 0.0.0.0:80#1: conn#4: Open
2017/02/03 20:51:24 client: Fingerprint a4:59:fb:8a:fd:93:b5:0a:2e:08:9c:15:38:b3:1d:44
2017/02/03 20:52:06 client: Fingerprint a4:59:fb:8a:fd:93:b5:0a:2e:08:9c:15:38:b3:1d:44
panic: ssh: no key material for msgNewKeys

goroutine 71 [running]:
panic(0x74ec60, 0xc820084bb0)
	/usr/lib/go-1.6/src/runtime/panic.go:481 +0x3e6
golang.org/x/crypto/ssh.(*connectionState).writePacket(0xc820128168, 0xc82011ad80, 0x7fc143dba330, 0xc8200126f0, 0xc8200e0440, 0x9, 0x9, 0x0, 0x0)
	/root/gocode/src/golang.org/x/crypto/ssh/transport.go:163 +0x2c5
golang.org/x/crypto/ssh.(*transport).writePacket(0xc820128100, 0xc8200e0440, 0x9, 0x9, 0x0, 0x0)
	/root/gocode/src/golang.org/x/crypto/ssh/transport.go:144 +0x81
golang.org/x/crypto/ssh.(*handshakeTransport).pushPacket(0xc820106140, 0xc8200e0440, 0x9, 0x9, 0x0, 0x0)
	/root/gocode/src/golang.org/x/crypto/ssh/handshake.go:206 +0x63
golang.org/x/crypto/ssh.(*handshakeTransport).kexLoop(0xc820106140)
	/root/gocode/src/golang.org/x/crypto/ssh/handshake.go:286 +0x40f
created by golang.org/x/crypto/ssh.newClientTransport
	/root/gocode/src/golang.org/x/crypto/ssh/handshake.go:113 +0x352

Client should exit/fail if it not able to bind to the local port

If one tries to run multiple chisel clients, possibly talking to different hosts, but mistakenly uses the same local port, the second invocation should fail and complain loudly.

./chisel client -v --keepalive 10s https://first-host 5022::2022 &
./chisel client -v --keepalive 10s https://second-host 5022::2022

The second invocation continues to run despite encountering the error (silent error!). This leads to false sense of success, and subsequent attempts to communicate to second-host via local port 5022 will actually forward traffic to first-host.

Below is slightly modified output from an actual run:

$ ./chisel client -v --keepalive 10s https://second-host 5022::2022
2017/04/13 12:38:32 client: Connecting to wss://second-host:443
2017/04/13 12:38:32 client: 0.0.0.0:202#1: listen tcp4 0.0.0.0:5022: bind: address already in use
2017/04/13 12:38:33 client: Fingerprint 6e:37:2b:d4:76:28:35:12:36:a3:ae:b1:59:10:77:3e
2017/04/13 12:38:33 client: Sending configurating
2017/04/13 12:38:33 client: Connected (Latency 30.839892ms)

Usage example

Hello, I am having a difficult time understanding how to use chisel for my use case.

I have a sever, running "chisel server --port 8080".

I have a client (client A) that is running a webserver on port 80.
I have another client behind a firewall (client B).
I would like client B to be able to view the website hosted on client A's machine.

What types of settings would I use in "chisel client" for each client to allow this to work?

Thank you!!

[Feature request] Option to Ignore TLS certificate verification

(Sorry for my poor English)
Chisel is an amazing tool! I want to use chisel behind Nginx.
Becasuse the firewall of my company only allow port 443 use HTTP CONNECT command.
I want to use port 443 for my home server for HTTPS website, and chisel too.
So I tried to config Nginx to redirect HTTPS request by different domain.

[Client Command]
chisel_windows_amd64.exe client --proxy http://company-proxy:port https://home-server:443 0.0.0.0:33389:192.168.1.102:3389

2017/05/26 11:34:54 client: Retrying in 100ms...

How to run OpenVPN through chisel?

I have OpenVPN server running on TCP/443. Is it possible to run it over chisel?

If yes, what commands should be issued on server and what on client?

Any help would be much appreciated.

remote server is behind NAT

i have a situation where i have some embedded devices out in the field and they are all in NAT environment. They can only call upstream on 80 and 443.

So i am hoping i could use this to connect to them via a public static in between server, using Chisel.

But i am not sure.. Can you let me know what you think..

Add docker support

We can put chisel into docker image.
Here is my docker image

https://github.com/netroby/alpine-chisel
https://hub.docker.com/r/netroby/alpine-chisel/

and these guide how to using docker image

Both server and client need docker installed.

Server side

There be a proxy server listen on 127.0.0.1:8123 on server. (squid or polipo)
create a file /etc/chisel.json, with content

{
    "USER:AVERYSTRONGPASSWORD": [
        ""
    ]
}

run command

docker run -d --restart=always --name chisel-server  -v /etc/chisel.json:/etc/chisel.json -p 0.0.0.0:8719:8719  netroby/alpine-chisel /bin/chisel server -v --port 8719 --authfile /etc/chisel.json

Client side

$SERVER_IP will be your chisel server ip address
run command

docker run -d --restart=always --name chisel  -p 0.0.0.0:8123:8123  netroby/alpine-chisel /bin/chisel client -v --keepalive 300s --auth USER:AVERYSTRONGPASSWORD $SERVER_IP:8719 8123

After it success connected to chisel server, the localhost:8123 will forward tcp connection to remote server proxy server port. you will be access to the free network

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.