bcrypt TypeError "Unicode-objects must be encoded before hashing" #1039
Comments
|
Is your key file in the "new openssh format" (the "-o" option to ssh-keygen) by any chance? |
|
I do have an ed25519 key which is according to ssh-keygen(1) always in the new format. |
|
@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. |
|
Sorry I try to clearify. The enviromentThe 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 codeI 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 resultThe code produces the following output: |
|
That's interesting - it looks like it's using a key from the ssh agent, but then it tries to load a private key from a file ... |
|
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 |
|
IIRC 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. |
|
@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 |
|
I think that PR is the right way to fix this, left a note on there. Let's roll this into the PR. Thanks! |
|
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 |
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.
The text was updated successfully, but these errors were encountered: