23

I want to set up a private network of applications which can connect to a single Geth node. What options do I have for exposing the RPC server?

I'm running this: geth --rpc --testnet (sometimes I use --dev)

How can I achieve the following:

  • Permit specific public/private keys to access the node
  • Permit anyone to access the node
  • Permit IP range to access the node

Possible solution?

Would this just require running a reverse proxy with a server like Nginx?

  • 4
    It looks like the geth option: --rpccorsdomain may be what I'm looking for. I think you can specify --rpccorsdomain "*" which will allow anyone to access the RPC server. I'm sure you can also use a reverse proxy to achieve this as well. I based my information off of this repo: github.com/Kunstmaan/docker-ethereum – Karl Floersch Apr 18 '16 at 21:04
  • 2
    Yes, rpccorsdomain is what you want, consider answering your own question. – niksmac Apr 19 '16 at 1:22
  • 4
    Please note, CORS is enforced by browsers. It's a security measure to prevent cross site scripting and DDOS attacks by essentially preventing the masses who use plain browsers to accidentally do something stupid. However an attacker may freely disregard any CORS requests the server sends back. It should not be used as a security precaution. – Péter Szilágyi Apr 20 '16 at 8:14
21

You can easily and securely create an SSH tunnel to your ETH Node from the application server. This way, the ETH node is fooled into believing that the connection is from localhost and you can ensure that only the holder of a private key can access.

This is a link to instructions on how to setup certificate based authentication

It is important to setup certificate authentication because else you can not automate the process.

Once you have set that up you can create a tunnel by running a command like:

ssh -f -N -L 9545:localhost:8545 remoteUser@remotehost.remotedomain.tld

The port numbers are different in my example, in order for the reader to be able to tell them apart. There is absolutely no other reason to make them different.

Once this command has been issued all traffic to port 9545 on localhost will be forwarded to remotehost.remotedomain.tld:8545 which will consider it to have originated from localhost and be targeted at localhost:8545

This way, you can keep your ETH node behind a firewall and not open it up to the world but still centralize the functionality.

In order to use this in production, you will have to solve the issue of disconnecting SSH sessions.

  • 1
    Hello sir, about solution, Would this solution only works for the users who knows the password for the remoteUser@remotehost.remotedomain.tld? (as I understand from my external node I have to run the ssh command and should know the password for the "remoteUser@remotehost.remotedomain.tld" ). Does it require for any user should have access to the server(remotehost.remotedomain.tld) under a username. or should I publicly announce a password for the "remoteUser"? – alper Nov 16 '16 at 19:05
  • 2
    publishing a password is a bad idea! But more to the point, you should really use certificate based authentication in order to NOT having to enter the password. Furthermore, this method is not meant to give end users access to the node but to give application servers access to the node. – Micha Roon Nov 17 '16 at 6:01
  • 1
    Would it be good idea to use Docker as an application server inside my ETH node? So Docker as the application server may create a tunnel. @Dr Gorb. – alper Feb 14 '17 at 17:48
  • 1
    What if it's on same machine? Meaning: GETH is running on same machine as app (block explorer). I do not want to make RPC port available to 0.0.0.0 (but I want the enduser/browser to be able to query it for the block explorer) is there a way around this? Proxy? --- Seems all the explorers I see need the RPC allowed for 0.0.0.0. This seems like a dumb design. Why not have app itself query localhost/save RPC info into array/etc, then deliver info to browser? Anyway, is there a workaround? – bshea Mar 19 '18 at 15:18
  • 1
    you can determine which RPC functions are available to clients with the RPC flag. And you can be more restrictive than 0.0.0.0 and allow it only for 127.0.0.1 – Micha Roon Mar 20 '18 at 20:14
19

warning: I do not recommend this

By default the node will only accept connections from localhost. You can change this to accept connections from anyone with: --rpcaddr "0.0.0.0".

Please note that anytime a private key is unlocked, anyone on the Internet can use this key by querying your rpc server and send transactions.

  • 1
    Yes, that is the obvious answer. But not the one anyone should use unless there is a 0 balance. I have a wallet that's unlocked from time to time. Not to mention opening any RPC to the world is just a bad idea, regardless.. – bshea Mar 19 '18 at 15:21
3
--rpc --rpcport "8545" --rpcaddr "127.0.0.1" --rpccorsdomain "*"

--rpccorsdomain "*" allows anyone to connect to the node on given --rpcport

  • 4
    Welcome to StackExchange! Can you explain what is happening here and what different items mean? Is there any potential dangers in allowing all ( * )? – tayvano Apr 19 '16 at 18:42
  • 1
    Why did this get so many down votes ? Why is this not a good solution, can someone explain plz – Rémi Aug 1 '17 at 17:25
  • 2
    --rpccorsdomain value Comma separated list of domains from which to accept cross origin requests (browser enforced) - Browser enforced means that if a user makes a request without a browser, geth will server the request ignoring the domain. ` – Pedro Lobito Oct 8 '17 at 0:07
  • 1
    "Why did this get so many down votes?" Because it's incomplete/wrong. CORS is only part of it. How would you (external connections) connect if its running on 127.0.0.1, only? – bshea Mar 19 '18 at 15:04
  • 2
    --rpccorsdomain "*" allows anyone to connect to your geth node via rpc. In production/public use --rpccorsdomain "remoteUser@remotehost.remotedomain.tld" to bind connection specifically to your remote user. In practice geth should be listening to local connections only. – 0mkar Mar 19 '18 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.