ed25519 key auth fails with FileError
epuscasu opened this issue · 7 comments
Bug reports
Steps to reproduce:
- Example code that produces error.
import socket
from ssh2.session import Session
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("dest.server", 22))
session = Session()
session.handshake(sock)
pkey = r"path\to\id_ed25519"
session.userauth_publickey_fromfile("username", pkey, "")
channel = session.open_session()
channel.execute("echo test")
print(channel.read())
- Stack trace or error messages.
Traceback (most recent call last):
File "C:\Users\epuscasu\AppData\Local\Programs\Python\Python310\test_ssh.py", line 23, in <module> session.userauth_publickey_fromfile("username", pkey, "")
File "ssh2\session.pyx", line 222, in ssh2.session.Session.userauth_publickey_fromfile
File "ssh2\utils.pyx", line 162, in ssh2.utils.handle_error_codes ssh2.exceptions.FileError
Expected behaviour: Successful connection, (5, b'test\n')
output.
Actual behaviour: ssh2.exceptions.FileError
. Using a RSA key performs as expected.
Additional info: ssh2-python version 0.27.0
, Windows 10 x64, Python 3.10.
Possible cause - the OpenSSL version bundled with the PyPI packages might be outdated on some platforms. EdDSA support was included in 1.1.1 (https://www.openssl.org/blog/blog/2018/09/11/release111/)
Hi there,
Thanks for the interest and report.
This is a known issue with publickey_fromfile
and ED25519 keys on Windows only. I suspect Window's file locking behaviour is the root cause.
Use userauth_publickey_frommemory
instead to work around.
Use userauth_publickey_frommemory instead to work around.
Does not work, same behavior. Any other suggestions?
Yes, also tested.
I've not found a way to make ED25519
keys work on Windows clients. I'd suggest using ECDSA or any other type of key.
Can also use the high level client pssh.clients.ssh.SSHClient
- documentation here.
Reference ParallelSSH/parallel-ssh#285
ED25519
key files cannot be loaded by neither userauth_publickey_fromfile
nor userauth_publickey_frommemory
on Windows clients only.
Most probably a bug with upstream libssh2. Needs C test case and tracing output to investigate and raise with libssh2.
Hello @pkittenis!
Any updates on this issue?
Hello again, @pkittenis
It seems the issue was fixed in the latest version of libssh2. Is there a chance to update libssh2 on this repository as well?
Pending new release of libssh2 that contains the fix.
1.10.0 is so far the latest version and it does not contain the fix.