-
Notifications
You must be signed in to change notification settings - Fork 20.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Could not decrypt key with given passphrase #19905
Comments
My hunch is that the first time you had an extra line break from |
The file created by echo, recreated from the command above and renamed: I would support a rule that a trim() operation be applied to all passwords, making leading and trailing whitespace characters no longer an impactful part of a password, at the next breaking-change release, if it isn't there already. |
So, here's the reason it fails (your three files, dumped out with hexdump):
All of the files actually include 2 invisible prefix bytes, which Windows (Notpad) probably prepends in there to act as a byte order mark. From Wikipedia:
Additionally, all the characters in your password files are actually represented by 2 bytes, whereas 1 is enough. E.g. here's the same password echoed out under Linux and hexdumped:
My hunch is that Geth simply loads the content of the file as a plain blob and expects it to work as is. We don't expect that some Windows program will inject extra characters that it interprets as metadata and not real data. CC @holiman ^ interesting issue on Windows |
The first one was created by echo (in Windows PowerShell), not Notepad. It appears Notepad then just ignores these. |
…convert it instead of unexpectedly failing to unlock
while in theory the contents could be converted, instead of going down the unicode rabbithole I'd instead suggest failing in MakePasswordList when a BOM is detected |
Windows powershell echo defaults to specific utf encodings depending on the platform. Echo can be modified as follows in powershell: |
We should add this issue to our FAQ |
This issue was added to the FAQ with a link to here, so I think we can safely close this issue |
You don't think it'd be better to actually handle the BOM? |
You're right, I was a bit to fast clicking the close button! |
We can't filter, but we could maybe try without the BOM if there is one and the first attempt fails.
|
To minimize any negative consequences to existing setups, I might suggest trying first with the status quo and have any new code to handle the BOM active only after the existing code has reached a failure state. |
I got the same error while running my faucet code |
I have the same isse : OS : Windows 11
Entered password: @N0d31!!.
=> Could not decrypt key with given password
=> Could not decrypt key with given password Finally I've changed the password (removing first "@" and last "." chars)
Entered password: N0d31!!
=> OK Hop it helps. |
This doesn't work. The
Could you show the binary content of |
This is what is needed to get it correct:
Note the |
When I try to repro this (on linux),
It would be interesting to see what happens with the input. You could print out the password used in the attempt like so: diff --git a/cmd/geth/accountcmd.go b/cmd/geth/accountcmd.go
index e33b9eb0fb..b990b64a60 100644
--- a/cmd/geth/accountcmd.go
+++ b/cmd/geth/accountcmd.go
@@ -212,6 +212,7 @@ func unlockAccount(ks *keystore.KeyStore, address string, i int, passwords []str
for trials := 0; trials < 3; trials++ {
prompt := fmt.Sprintf("Unlocking account %s | Attempt %d/%d", address, trials+1, 3)
password := utils.GetPassPhraseWithList(prompt, false, i, passwords)
+ log.Info("Attempting password", "pw", fmt.Sprintf("%s %x", password, password))
err = ks.Unlock(account, password)
if err == nil {
log.Info("Unlocked account", "address", account.Address.Hex()) Naturally, take care not to post any sensitive information here. |
This ticket is very old, afaict most of the questions were answered and the last question I posted (years ago) went unanswered. Closing |
It wasn't clear to whom your last question was addressed. |
I am getting a reliably reproducible error "Could not decrypt key with given passphrase" when attempting to use the
--password
command-line argument to unlock an account on a mining node. Omitting that command line flag, and on prompt interactively entering the same password that the file contains (below, that's "issuedemo1"), works as expected.Below is a shell session showing a close to minimal reproducible example, developed on Windows 10.
In a new shell window:
Back in the Bootnode window, additional output:
Omitting the quotes around the password filename produces the same results.
Opening node1/password.txt in Notepad, I can see it contains "issuedemo1" followed by a line break and then the end of the file. Removing that line break, saving, closing, and trying again produces the same results, though on a subsequent reopen of the file the closing line break is no longer there (matching expectations). Clearing the file out completely, as concerningly suggested by comments on this answer, saving, and retrying, also has the same effect, but that is as expected.
The expected behavior is that the account is unlocked instead of geth terminating with error
Fatal: Failed to unlock account
. Alternative expected behavior is a better error message indicating what went wrong and how I might fix it, as this might be a simple error.The text was updated successfully, but these errors were encountered: