Source builds share system libcrypto with Python's ssl; libssh2 leaves OpenSSL errors on the queue after pubkey auth #246

The manylinux wheels bundle a private libcrypto (ssh2_python.libs/), so they are isolated from the interpreter. A source build (e.g. on Python 3.15, where no wheel exists yet) links the system libcrypto, the same library Python's ssl module loads. Both then use one per-thread OpenSSL error queue.

During userauth_publickey_fromfile, libssh2 first tries OpenSSL's PEM decoder on an OpenSSH-format key. That fails with error:1E08010C:DECODER routines::unsupported; libssh2 then falls back to its own parser but never clears the error queue.

The next TLS read in the same thread (e.g. a pooled requests HTTPS connection) returns "want read", SSL_get_error() sees the stale error and reports SSL_ERROR_SSL, so ssl raises:

SSLError(1, '[OSSL_DECODER] unsupported (_ssl.c:3042)')

Seen with Python 3.15.2 / OpenSSL 3.5.7 on Debian trixie; with the cp314 wheel the queue is empty after auth.

Suggested fixes:

• call ERR_clear_error() after libssh2 calls that can touch OpenSSL (at least the auth paths), so stale errors don't leak to other users of the library; and/or
• document that source builds share libcrypto with the interpreter and recommend auditwheel repair.

Our workaround is auditwheel repair on the source build, which bundles a private libcrypto like the PyPI wheels: scylladb/scylla-cluster-tests#16742