search for: ssh_request_repli

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,