search for: process_remove_smartcard_key

...sr/lib64/pkcs11/opensc-pkcs11.so Enter passphrase for PKCS#11: Card added: /usr/lib64/pkcs11/opensc-pkcs11.so $ ssh-add -e /usr/lib64/opensc-pkcs11.so Could not remove card "/usr/lib64/opensc-pkcs11.so": agent refused operation >From the ssh-agent log we can see: process_remove_smartcard_key: pkcs11_del_provider failed the problem is the call to the realpath(3), which resolves the symlinks and passes to the pkcs11-code already target of that symlink. I understand that it is needed for the whitelist to be effective, but it is getting confusing that one input is sanitized, the second n...

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

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

...uf_put_u32(e->output, 1) != 0 || + sshbuf_put_u8(e->output, r) != 0) + fatal("%s: buffer error", __func__); +} +#endif /* USE_OPENSSL_ENGINE */ + #ifdef ENABLE_PKCS11 static void process_add_smartcard_key(SocketEntry *e) @@ -860,6 +937,12 @@ process_message(u_int socknum) process_remove_smartcard_key(e); break; #endif /* ENABLE_PKCS11 */ +#ifdef USE_OPENSSL_ENGINE + case SSH_AGENTC_ADD_ENGINE_KEY: + case SSH_AGENTC_ADD_ENGINE_KEY_CONSTRAINED: + process_add_engine_key(e); + break; +#endif /* USE_OPENSSL_ENGINE */ default: /* Unknown message. Respond with failure. */ error("Un...