search for: yubicos

Hey all, I'm trying to install the fedora-packager group so that I can build Fedora source packages into RPMs that I can install. I'm getting this error: Error: Package: fedora-packager-0.6.0.1-1.el6.noarch (epel) Requires: python-yubico <SNIP> [root at peach ~]# yum install python-yubico <SNIP> No package python-yubico available. Do you suppose that maybe this

On 01/10/17 13:12, Tony Schreiner wrote: > On Tue, Jan 10, 2017 at 11:12 AM, Mark LaPierre <marklapier at gmail.com> > wrote: > >> Hey all, I'm trying to install the fedora-packager group so that I can >> build Fedora source packages into RPMs that I can install. I'm getting >> this error: >> >> Error: Package:

On Tue, Jan 10, 2017 at 11:12 AM, Mark LaPierre <marklapier at gmail.com> wrote: > Hey all, I'm trying to install the fedora-packager group so that I can > build Fedora source packages into RPMs that I can install. I'm getting > this error: > > Error: Package: fedora-packager-0.6.0.1-1.el6.noarch (epel) > Requires: python-yubico > <SNIP> >

On Tue, 2017-01-10 at 11:12 -0500, Mark LaPierre wrote: > Hey all, I'm trying to install the fedora-packager group so that I can > build Fedora source packages into RPMs that I can install. I'm > getting > this error: > > Error: Package: fedora-packager-0.6.0.1-1.el6.noarch (epel) > Requires: python-yubico It's a known bug:

On Mon, 13 Aug 2018, Blumenthal, Uri - 0553 - MITLL wrote: > Lack of time on the Open Source projects is understandable, and not uncommon. > > However, PKCS11 has been in the codebase practically forever - the ECC > patches that I saw did not alter the API or such. It is especially > non-invasive when digital signature is concerned. > > Considering how long those patches have

Hi, So I finally have time to test the u2f support but so far I haven't been very successful, Specifically, current HEAD has SSH_SK_VERSION_MAJOR 0x00040000 and I can't seem to find a matching libfido2 version, current HEAD of Yubico/libfido2 is 0x00020000 Is there a more up to date libfido2 or a particular commit of openssh-portable I should be using? thanks Sean

On Feb 17, 2020, at 9:45 PM, Damien Miller <djm at mindrot.org> wrote: > On Mon, 17 Feb 2020, Ron Frederick wrote: >> I?m trying out the ?resident key? functionality in OpenSSH 8.2, and >> I?m having trouble getting it to find keys that I?ve created. >> >> I?m trying to create a new resident key using: >> >> ssh-keygen -O resident -t ed25519-sk -f

You might want to look at these : Windows: https://www.technorms.com/46293/enable-microsoft-two-step-authentication-in-windows-10 https://www.yubico.com/passwordless/ Or Phone: https://www.yubico.com/products/yubikey-for-mobile/ Setup: https://support.yubico.com/support/solutions/articles/15000006456-yubikey-smart-card-deployment-guide Ssh:

Dear all, I did try to google search the archives [1] but cannot find any information on this. Would it be possible to somehow implement a passwordless (or as a 2FA) to login to a remote samba (linux server)? Any suggestions greatly appreciated, Greg 1. https://lists.samba.org/archive/samba/

Hi, I'm interested in extending OpenSSH's PKCS#11 code to support ECDSA keys, but have so far been unable to find anyone who can sell me a smartcard that supports it. They certainly exist - AFAIK it's required by the US PIV standard, but obtaining cards that support it in single digit quantities seems all but impossible. Can anybody on this list help? I'd want 2-6 cards/tokens

I set up the YubiKey with OpenSSH 8.2 (Ubuntu client and server) and it works. However, it does not do PIN enforcement at SSH login. It only requests the PIN during the set-up process (when the key is being generated). Is that the way it's supposed to work? Frank

Hi, As of this morning, OpenSSH now has experimental U2F/FIDO support, with U2F being added as a new key type "sk-ecdsa-sha2-nistp256 at openssh.com" or "ecdsa-sk" for short (the "sk" stands for "security key"). If you're not familiar with U2F, this is an open standard for making inexpensive hardware security tokens. These are easily the cheapest way

https://bugzilla.mindrot.org/show_bug.cgi?id=2635 Bug ID: 2635 Summary: Unable to use SSH Agent and user level PKCS11Provider configuration directive Product: Portable OpenSSH Version: 7.3p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5

On 2019-11-14, Damien Miller <djm at mindrot.org> wrote: > Please give this a try - security key support is a substantial change and > it really needs testing ahead of the next release. Hi Damien, Thanks for working on security key support, this is a really nice feature to have in openssh. My non-FIDO2 security key (YubiKey NEO) doesn't work with the latest changes to openssh

Hello, I?m trying out the ?resident key? functionality in OpenSSH 8.2, and I?m having trouble getting it to find keys that I?ve created. I?m trying to create a new resident key using: ssh-keygen -O resident -t ed25519-sk -f <filename> This creates a key, but I?m not actually sure it is creating a ?resident? key, as when I try to dump out the resident keys with either ?ssh-keygen -K?

https://bugzilla.mindrot.org/show_bug.cgi?id=3613 Bug ID: 3613 Summary: Unable to sign using certificates and PKCS#11 Product: Portable OpenSSH Version: 8.9p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh-keygen Assignee:

https://bugzilla.mindrot.org/show_bug.cgi?id=2432 Bug ID: 2432 Summary: ssh-keygen and tools should be able to get public part directly from private key (portability) Product: Portable OpenSSH Version: 6.9p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement

On Mon, Sep 07, 2020 at 09:14:03PM +0200, Karol Herbst wrote: > > - changes in the nouveau driver. Mika told me the PCIe regression > > "pcieport 0000:00:01.0: PME: Spurious native interrupt!" is supposed > > to be fixed in 5.8, but I still get a 4mn hang or so during boot and > > with 5.8, removing the USB key, didn't help make the boot faster >

Hey, Judging from the (private) responses I?ve got, there is quite a bit of interest in the U2F feature I proposed a while ago. Therefore, I?ve taken some time to resolve the remaining issues, and I think the resulting patch (attached to this email) is in quite a good state now. I also posted the new version of the patch to https://bugzilla.mindrot.org/show_bug.cgi?id=2319 (which I?ve opened

I was recently looking at verifying the attestation data (ssh-sk-attest-v00) for a SK key, but I believe the data saved in this structure is insufficient for completing verification of the attestation. While the structure has enough information for U2F devices, FIDO2 devices sign their attestation over a richer "authData" blob [1] (concatenated with the challenge hash). The authData blob