Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
bcrypt TypeError "Unicode-objects must be encoded before hashing" #1039
I am using Python 3.6.2 and paramiko 2.2.1. Since I am not using the ed25519 private key explicitly in my code I assume this is a paramiko bug.
@tvannahl - you said:
Can you clarify this? What are you explicitly using for auth in this situation, if anything? (I.e. what args are you giving to
I ask because this may be an issue with how Paramiko currently tries all key types in an arbitrary order for any given key file it's been asked to load. (Normally that doesn't explode in this particular way, but that's why I'm asking, to see if we can figure out exactly what key material is triggering it.)
EDIT: if you enable debug-level stdlib logging and supply that output, that will also help as it will give at least some info about which keys are being tried when.
referenced this issue
Sep 1, 2017
Sorry I try to clearify.
The client does have an rsa and ed25519 keypair and has the server registered within known_hosts. The client is only able to connect to the server using a password, so no keypair will work for authentication.
The minimal code
I have written the following minimal example where I have been able to replicate the problem:
#!/usr/bin/env python3 import paramiko import logging import sys logging.basicConfig(stream=sys.stdout, level=logging.DEBUG) server, user, pw = "server.example.org", "tvannahl", "mypassword" client = paramiko.client.SSHClient() client.load_system_host_keys() client.set_missing_host_key_policy(paramiko.client.AutoAddPolicy()) client.connect(hostname=server, username=user, password=pw)
The code produces the following output:
I was a little surprised that it said "userauth is OK", but then must have thrown an exception, for it to continue on to try the standard auth-key filenames.
I think that a temporary work-around for you is
It confuses people a lot (self included) so I'd like to change it sometime. Whether given log messages should be considered backwards compatible or not is something I'm torn on though, heh.
@tvannahl One of my questions is simply "which key are you intending to use for this server" :) It seems clear by now that this ed25519 key is triggering the bug, and is probably coming from your SSH agent (this can be disabled, by the way, with I think
back to @ploxiln - it seems like this could be the password or the salt, though I think you're probably right re: password type consistency.
added a commit
Sep 4, 2017
@bitprophet I am not intending to use any key on this server. I am intending to use password authentication because I do not have any of my public keys on that server.
It does not seem to be the agent interfering, I did try out
But after I did change the password encoding to a byte string, like @ploxiln suggested, the authentication did work. I must admit that I am a little bit puzzled by this because of the stacktrace in the former try:
We did figure out that it has nothing to do with the ssh agent - it is just because paramiko is trying to use the password to decrypt the ed25519 auth key, and instead of failing in the normal way it's getting an unexpected exception. Another work around which I think will work for you is using the
Oh and re: agent, I was never thinking the agent itself was teh issue, was just trying to separate "key exploding" from "why is key even being used, I don't want it". Given that this still pops up even w/ agent in play I'm assuming the key is in