search for: c_login

...chipcard reader."); + pin = NULL; + } else { + snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ", + si->token.label); + pin = read_passphrase(prompt, RP_ALLOW_EOF); + if (pin == NULL) + return (-1); /* bail out */ + }; + rv = f->C_Login(si->session, CKU_USER, (u_char *)pin, pin ? strlen(pin) : 0); if (rv != CKR_OK && rv != CKR_USER_ALREADY_LOGGED_IN) { - free(pin); + if (pin) free(pin); error("C_Login failed: %lu", rv); return (-1); } - free(pin); + if (pin) free(pin); si->logg...

Right now, if I typo my PIN for a PKCS#11 token, I get the inscrutable message: $ ssh -I /path/to/module user at example.com Enter PIN for 'SSH key': C_Login failed: 160 I'd prefer to receive a more useful message: Login to PKCS#11 token failed: Incorrect PIN I've attached a patch that adds specific handling for three common error cases: Incorrect PIN, PIN too long or too short, and PIN locked. I've also tweaked the fallback error case to...

...TH) ? " on reader keypad" : ""); return (-1); } - snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ", - si->token.label); - pin = read_passphrase(prompt, RP_ALLOW_EOF); - if (pin == NULL) - return (-1); /* bail out */ - if ((rv = f->C_Login(si->session, CKU_USER, pin, strlen(pin))) + if (si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) { + verbose("Deferring PIN entry to keypad of chipcard reader."); + pin = NULL; + } else { + snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ", +...

...entry to keypad of chipcard reader."); + pin = NULL; + } else { snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ", si->token.label); pin = read_passphrase(prompt, RP_ALLOW_EOF); if (pin == NULL) return (-1); /* bail out */ - if ((rv = f->C_Login(si->session, CKU_USER, - (u_char *)pin, strlen(pin))) != CKR_OK) { - free(pin); + }; + if ((rv = f->C_Login(si->session, CKU_USER, pin, pin ? strlen(pin): 0)) + != CKR_OK) { + if (pin) + xfree(pin); error("C_Login failed: %lu", rv); return (-1);...

Hello everyone, as you could have noticed over the years, there are several bugs for PKCS#11 improvement and integration which are slipping under the radar for several releases, but the most painful ones are constantly updated by community to build, work and make our lives better. I wrote some of the patches, provided feedback to others, or offered other help here on mailing list, but did not

Hi Alon, I confirmed with pkcs11-tool (from OpenSC) and I can confirm that pressing return when asked for the pin causes the login to stop (and not to try a empty pin). Can you confirm if a empty pin is actually a valid pin, and if not, can the patch be accepted? Once again, the problem is that from a user experience, *some/most* users would expect they can skip pkcs11 token authentication just

On 11/16/16, 8:55 AM, "openssh-unix-dev on behalf of Juha-Matti Tapio" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of jmtapio at ssh.com> wrote: On Wed, Nov 16, 2016 at 12:54:44PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > I find this approach very bad in general. > > PKCS#11 standard says that *private* keys should not be

On Sat, 2019-04-06 at 03:20 +1100, Damien Miller wrote: > On Fri, 5 Apr 2019, Jakub Jelen wrote: > > > There is also changed semantics of the ssh-keygen when listing keys > > from PKCS#11 modules. In the past, it was not needed to enter a PIN > > for > > this, but now. > > > > At least, it is not consistent with a comment in the function > >

https://bugzilla.mindrot.org/show_bug.cgi?id=2652 Bug ID: 2652 Summary: PKCS11 login skipped if login required and no pin set Product: Portable OpenSSH Version: 7.4p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: Smartcard Assignee:

https://bugzilla.mindrot.org/show_bug.cgi?id=2638 Bug ID: 2638 Summary: Honor PKCS#11 CKA_ALWAYS_AUTHENTICATE attribute of the private objects Product: Portable OpenSSH Version: 7.3p1 Hardware: Other OS: Linux Status: NEW Keywords: patch Severity: enhancement

...3148 * ssh(1), ssh-keygen(1): fix NULL dereference in private certificate key parsing (oss-fuzz #20074). * ssh(1), sshd(8): more consistency between sets of %TOKENS are accepted in various configuration options. * ssh(1), ssh-keygen(1): improve error messages for some common PKCS#11 C_Login failure cases; bz#3130 * ssh(1), sshd(8): make error messages for problems during SSH banner exchange consistent with other SSH transport-layer error messages and ensure they include the relevant IP addresses bz#3129 * various: fix a number of spelling errors in comments and debug/error...

Hi, OpenSSH 6.7 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This is a big release containing a number of features, a lot of internal refactoring and some potentially-incompatible changes. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD:

Hello All, As I promised, I've completed and initial patch for openssh PKCS#11 support. The same framework is used also by openvpn. I want to help everyone who assisted during development. This patch is based on the X.509 patch from http://roumenpetrov.info/openssh/ written by Rumen Petrov, supporting PKCS#11 without X.509 looks like a bad idea. *So the first question is: What is the

...3148 * ssh(1), ssh-keygen(1): fix NULL dereference in private certificate key parsing (oss-fuzz #20074). * ssh(1), sshd(8): more consistency between sets of %TOKENS are accepted in various configuration options. * ssh(1), ssh-keygen(1): improve error messages for some common PKCS#11 C_Login failure cases; bz#3130 * ssh(1), sshd(8): make error messages for problems during SSH banner exchange consistent with other SSH transport-layer error messages and ensure they include the relevant IP addresses bz#3129 * various: fix a number of spelling errors in comments and debug/error...