How can I expose Geth's RPC server to external connections?

  • 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?

    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: https://github.com/Kunstmaan/docker-ethereum

    Yes, `rpccorsdomain ` is what you want, consider answering your own question.

    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.

  • Micha Roon

    Micha Roon Correct answer

    5 years ago

    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 [email protected]
    

    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.

    Hello sir, about solution, Would this solution only works for the users who knows the password for the [email protected]? (as I understand from my external node I have to run the ssh command and should know the password for the "[email protected]" ). 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"?

    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.

    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.

    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?

    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

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM