40

personal.unlockAccount(eth.accounts[0],"")

Error: account unlock with HTTP access is forbidden

I run Geth in a Docker container and use

docker exec -it bootstrap geth --datadir=~/.ethereum/devchain attach

to exec the Geth console.

Wayne
  • 401
  • 1
  • 4
  • 3

4 Answers4

43

Yes, this error is about some geth update. See more about it in this merged go-ethereum pull request.

Overall, to bypass this protection, If you want to enable unlocking accounts with unsecure http (security risk), you can use "--allow-insecure-unlock" option when starting geth local server like;

geth --ropsten --syncmode "fast" ***--allow-insecure-unlock*** --cache 1024 --rpc --rpcapi eth,net,web3,personal
myuce
  • 103
  • 3
artyppl
  • 539
  • 3
  • 4
  • 1
    Sorry, I am still confused where to append 'allow-insecure-unlock'? – Wayne Apr 09 '19 at 16:54
  • 1
    In your case something like: docker exec -it bootstrap geth --datadir=~/.ethereum/devchain --allow-insecure-unlock attach – artyppl Apr 10 '19 at 09:20
  • 2
    It still shows the Error: account unlock with HTTP access is forbidden, why? – Wayne Apr 10 '19 at 15:10
  • 9
    try to add "--allow-insecure-unlock" option when you start/run the eth-node. – artyppl Apr 11 '19 at 09:12
  • 1
    added it as the last parameter in commandline and it worked :) – krupesh Anadkat Aug 19 '20 at 05:08
  • 1
    IMO it is not advisable to suggest preferences of insecure methods since all of these hacks mean that you are not knowing what you are doing and that the door is wide open for secondary attack vectors. And that only because nobody told you how to do it right. Like we get into crypto and people tell you to run your node in an insecure way. Like what. Anybody knowing how to run geth securely while unlocking an account please respond here. I am now trying to figure this out myself as well. – xh3b4sd Jun 03 '21 at 11:40
8

It looks like you have geth open with --rpc, enabling HTTP access. If you unlock the account, anybody who can access that node by HTTP can do anything they like with that account, such as moving all funds to a different address that only they have a key to, or otherwise mess with whatever you're trying to accomplish. There are bots scanning for these sorts of vulnerabilities all over and you might suffer from the security hole even if not specifically targeted. (Example report here).

The best solution is probably not to allow insecure unlocking of accounts, though the dangers are considerably less if a strong firewall prevents external HTTP access on the relevant ports. A better solution would be to think more carefully about why you think you need the account unlocked, and if there are ways to accomplish those goals other than unlocking and leaving the account wide open. Alternatively, you could do the unlock on another node on the same blockchain network which does not enable RPC/HTTP access.

WBT
  • 565
  • 1
  • 5
  • 16
2

I found a same issue when I tried to deploy a contract on a private chain with remix-ide using we3 provider. It seems that a node with RPC/HTTP access and an unlocked account is needed. Otherwise, An error occurred saying "Not possible to connect to the Web3 provider. Make sure the provider is running and a connection is open (via IPC or RPC)".

In this case, I first had geth open with --unlock, and then enabled RPC with admin.startRPC() function in the console attached. It works!

HX Du
  • 61
  • 5
0

the latest quorum release inherits upstream behaviour whereby it disallows unlock via HTTP-RPC for security reasons. There is a command line flag --allow-insecure-unlock which can be passed when starting geth which will re-allow this.

This is described in the upstream geth command line options here: https://github.com/ethereum/go-ethereum/wiki/Command-Line-Options

(Note that geth doesn't actually support HTTPS, so that HTTPS_QUORUM_ENDPOINT must actually be using HTTP, or I'm guessing it uses HTTPS to connect to a reverse proxy which then attaches to geth over the HTTP-RPC port.)

Ayoung
  • 1
  • 1