search for: webauthn

https://bugzilla.mindrot.org/show_bug.cgi?id=3748 Bug ID: 3748 Summary: "webauthn-sk-ecdsa-sha2-nistp256 at openssh.com" signature type not supported from ssh agent Product: Portable OpenSSH Version: 9.7p1 Hardware: 68k OS: Mac OS X Status: NEW Severity: enhancement Priority:...

Announcement: ------------- The 2-factor authentication was extended with Webauthn/FIDO2. You can manage AD LDS users and groups (LAM Pro). This is a test release. Please report any issues till 2020-03-06. Full changelog: https://www.ldap-account-manager.org/lamcms/changelog Download: https://www.ldap-account-manager.org/lamcms/releases Features: --------- * management of...

Announcement: ------------- The 2-factor authentication was extended with Webauthn/FIDO2. You can manage AD LDS users and groups (LAM Pro). Full changelog: https://www.ldap-account-manager.org/lamcms/changelog Download: https://www.ldap-account-manager.org/lamcms/releases Features: --------- * management of various account types * Unix * Samba 4/Active Directory * Aster...

...ibuting in git-for-windows repository to help expand the OpenSSH support for fido2 devices on Windows. Currently we are using your internal implementation(sk-usbhic.c) however since Windows 10 version 1903 this requires administrator privileges. I'm trying to create a module for OpenSSH to use webauthn.dll instead of direct calling to libfido2 to eliminate the need for administrator privileges I noticed that in ssh-sk.c in function sshsk_sign you hash the input data before passing it to external module sk_sign function. The problem is, Windows API automatically hash the input before sending it to...

At present whenever non-resident keys are used the key_handle required to use the token must be given by selecting the ssh 'private key' file generated by ssh-keygen during negotiation. In the more common webauthn context this key_handle would be stored on the server and then transmitted to the client during authentication. The client then checks connected tokens for one that reports it understands that key_handle and can sign on its behalf. Compared to SSH this approach means there are no external files req...

...to the client > > I'm not keen on making the public keys contain the key handle. IMO > being able to offer some protection of the key handle on disk by > setting a password on the key is valuable and we'd lose that if > everything were public by default. Your worry is that webauthn isn't true two factor because it's only based on a thing you possess rather than both a thing you know and a thing you possess? I agree, I've always thought the ability to steal someone's token was a big flaw in the scheme. However, it is trivially fixable: if you encrypt the fido...

...ot terribly inclined to go there myself.) Is there something I'm missing that would enable verification of the attestation signature for FIDO2 devices, or is this a correct assessment that the ssh-sk-attest-v00 file saved from ssh-keygen would not be enough? [1] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn-attestation

...n: 8.4p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh-keygen Assignee: unassigned-bugs at mindrot.org Reporter: pflug at pse-consulting.de I'm using a Trustkey G310. On Webauthn enabled sites (e.g. Bitwarden), the key requires a valid fingerprint to authenticate, effectively making the key two factors at once. While -O verify-required does validate against the key's PIN, it doesn't request fingerprint verification. I'd like to see the fingerprint user validat...

Announcement: ------------- This release enhances 2-factor authentication with Okta support and naming of WebAuthn devices. LAM Pro user self registration process can include an admin approval. This is a test release. Please report any issues till 2020-11-03. Full changelog: https://www.ldap-account-manager.org/lamcms/changelog Download: https://www.ldap-account-manager.org/lamcms/releases Features: ---...

...cceptedKeyTypes=rsa-sha2-512 ec2-user@<...IP...> Debug output: debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519 at openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256 at openssh.com,webauthn-sk-ecdsa-sha2-nistp256 at openssh.com> Additional notes: Note that Putty is unable to connect with the default connection options if server is configured like this, because it will always attempt to use rsa-sha2-512, I'm guessing due to it being sent in server-sig-algs list. -- You are re...

...require FIDO signatures assert that the token verified that the user was present before making the signature. The FIDO protocol supports multiple methods for user-verification, but currently OpenSSH only supports PIN verification. * sshd(8), ssh-keygen(1): add support for verifying FIDO webauthn signatures. Webauthn is a standard for using FIDO keys in web browsers. These signatures are a slightly different format to plain FIDO signatures and thus require explicit support. * ssh(1): allow some keywords to expand shell-style ${ENV} environment variables. The supported keywords...

...require FIDO signatures assert that the token verified that the user was present before making the signature. The FIDO protocol supports multiple methods for user-verification, but currently OpenSSH only supports PIN verification. * sshd(8), ssh-keygen(1): add support for verifying FIDO webauthn signatures. Webauthn is a standard for using FIDO keys in web browsers. These signatures are a slightly different format to plain FIDO signatures and thus require explicit support. * ssh(1): allow some keywords to expand shell-style ${ENV} environment variables. The supported keywords...

Stuart Henderson wrote: >> This is why I push for challenge/response tokens, not simply >> cert authentication, and really wish that FIDO (such as yubikey) >> was an option, but the discussions I've seen about suporting >> that have not been encouraging. > > hmm? That works pretty well in OpenSSH. hmm, what I'm finding doesn't seem to use the FIDO

I updated to the latest versions of libfido2 and openssh-portable tonight, with an intention to test out the security key functionality and look closely at the changes over the last couple of months to see if I need to change anything in my AsyncSSH implementation to stay in sync. However, it seems that libfido2 no longer provides the ?libsk-libfido2.so? library that it used to. That was something

...nd sshd supports the following algorithms: ssh-ed25519 ssh-ed25519-cert-v01 at openssh.com sk-ssh-ed25519 at openssh.com sk-ssh-ed25519-cert-v01 at openssh.com ssh-rsa rsa-sha2-256 rsa-sha2-512 ssh-dss ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 sk-ecdsa-sha2-nistp256 at openssh.com webauthn-sk-ecdsa-sha2-nistp256 at openssh.com ssh-rsa-cert-v01 at openssh.com rsa-sha2-256-cert-v01 at openssh.com rsa-sha2-512-cert-v01 at openssh.com ssh-dss-cert-v01 at openssh.com ecdsa-sha2-nistp256-cert-v01 at openssh.com ecdsa-sha2-nistp384-cert-v01 at openssh.com ecdsa-sha2-nistp521-cert-v01 at ope...