search for: socketentri

Add support to load additional certificates for already loaded private keys. Useful if the private key is on a PKCS#11 hardware token. The private keys inside ssh-agent are now using a refcount to share the private parts between "Identities". The reason for this change was that the PKCS#11 code might have redirected ("wrap") the RSA functions to a hardware token. We don't

Hi all! I do not know openssh patch policy so I am just sending the patch to the mailing list. Sorry for inconvenience. Ssh-agent seems to be too slow if you need to access thousands of servers. This is a simple patch to enable threading in ssh2 authentication. Patch adds "-p numthreads" option and defaults to the number of processors. I've tested it as I could, but

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

Hello, I noticed a problem recently when running some test code against the OpenSSH 7.6p1 ssh-agent. These tests ran fine against OpenSSH 7.5p1 and earlier, but with OpenSSH 7.6p1, they were suddenly causing ssh-agent to exit. The request being made was a ?sign? request, and the point of the test was to have the sign operation fail. To trigger this, I was passing in an invalid key blob

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

key is freed outside of the if that checks if key is NULL therefore, NULL could be sent to the key_free function which will not handle it correctly. The fix is to move key_free to a place where you know key is not NULL. This patch moves the key_free call. This entire set of patches passed the regression tests on my system. Bug found by Coverity. Signed-off-by: Kylene Hall <kjhall at

Hi all Patch adds flag -C to ssh-agent which will force confirmation for any key added in agent (similar to ssh-add -c) Helps when forwarded agent authentication is used and each key should be confirmed before use catam --- ssh-agent.c 2006-08-28 14:02:12.000000000 +0300 +++ ssh-agent.c.orig 2006-08-28 13:36:05.000000000 +0300 @@ -111,9 +111,6 @@ /* Default lifetime (0 == forever) */

On Nov 14, 2017, at 4:11 PM, Damien Miller <djm at mindrot.org> wrote: > On Mon, 13 Nov 2017, Ron Frederick wrote: >> I noticed a problem recently when running some test code against >> the OpenSSH 7.6p1 ssh-agent. These tests ran fine against OpenSSH >> 7.5p1 and earlier, but with OpenSSH 7.6p1, they were suddenly causing >> ssh-agent to exit. > > Sorry,

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,

ssh-agent is a great tool that is often misconfigured with respect to agent forwarding. How many people running ssh-agent and doing a ssh -A have the very same public keys in ~/.ssh/authorized_keys of the machine they are coming from? ssh(1) is very clear in its warning about enabling agent forwarding. The simple act of prompting the user before using the key would enable them to determine

Hi everyone. I have a system where I'd like to give certain users time-limited access to the use of certain SSH private keys without actually exposing the keys. I have the idea of using ssh-agent to do this. The agent would run as a "keyholder" user, and group permissions on the UNIX-domain socket would allow read-write by both that account and the actual ssh user. Right now,

during my seminar of advanced exploitation techniques (SEAT, [1]) i developed some methods to crack into system via DMA (e.g. via firewire). as part of this i developed a program that steals loaded ssh private keys from ssh-agents. i was astonished to find that the keys are not immediately removed from the agent when a timeout occurs, but only the next time the agent is queried via its socket. i

Moin, attached is a patch, which adds a new configuration option "PreferAskpass" to the ssh config. ssh{,-add,-keygen,-agent} will use ssh-askpass to prompt for passwords, if this option is set to "yes", and if ssh-askpass is available. Default for "PreferAskpass" is "no". Pacth is against current CVS. Sebastian -- signature intentionally left blank.

This is the 1st revision of the Advisory. This document can be found at: http://www.openssh.com/txt/buffer.adv 1. Versions affected: All versions of OpenSSH's sshd prior to 3.7 contain a buffer management error. It is uncertain whether this error is potentially exploitable, however, we prefer to see bugs fixed proactively. 2. Solution: Upgrade to OpenSSH

https://bugzilla.mindrot.org/show_bug.cgi?id=1506 Summary: rationalize agent behavior on smartcard removal/reattachment Product: Portable OpenSSH Version: 5.1p1 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Smartcard AssignedTo: