Displaying 5 results from an estimated 5 matches for "ssh_request_repli".
Did you mean:
ssh_request_reply
2003 Sep 24
1
[Bug 711] 3.7.1p2 does not compile on redhat 5.1
http://bugzilla.mindrot.org/show_bug.cgi?id=711
Summary: 3.7.1p2 does not compile on redhat 5.1
Product: Portable OpenSSH
Version: -current
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Build system
AssignedTo: openssh-bugs at mindrot.org
ReportedBy:
2000 Sep 18
1
ssh-agent and ssh2 servers...
I'm not on the mailing list, so I'd appreciate it if you could cc: me,
though I will keep an eye on the archives.
I am running openssh 2.2.0p1 on Debian GNU/Linux. I was pleased to
see that 2.2.0p1 had support for DSA keys in the agent, and I have
successfully used the v2 protocol to another openssh server with the
agent providing authentication.
I am also able to successfully connect
2020 Jun 09
3
[PATCH v2 0/2] Add openssl engine keys with provider upgrade path
I've architected this in a way that looks future proof at least to the
openssl provider transition. What will happen in openssl 3.0.0 is
that providers become active and will accept keys via URI. The
current file mechanisms will still be available but internally it will
become a file URI. To support the provider interface, openssl will
have to accept keys by URI instead of file and may
2017 Oct 26
3
[RFC 0/2] add engine based keys
Engine keys are private key files which are only understood by openssl
external engines. ?The problem is they can't be loaded with the usual
openssl methods, they have to be loaded via ENGINE_load_private_key().
?Because they're files, they fit well into openssh pub/private file
structure, so they're not very appropriately handled by the pkcs11
interface because it assumes the private
2020 Jan 30
6
[PATCH 1/2] Add support for openssl engine based keys
Engine keys are keys whose file format is understood by a specific
engine rather than by openssl itself. Since these keys are file
based, the pkcs11 interface isn't appropriate for them because they
don't actually represent tokens. The current most useful engine for
openssh keys are the TPM engines, which allow all private keys to be
stored in a form only the TPM hardware can decode,