similar to: Auth via Multiple Publickeys, Using Multiple Sources, One Key per Source

Peter, On 2020-06-03 12:14, Peter Stuge wrote: > mailto428496 wrote: >> We would like to associate two different types of public keys >> with each user's account.? One would be a "client machine" public key >> (of which there could be several, if the user is allowed to login from >> multiple systems) and the other would be a public key from a user token,

On Tue, 2020-07-21 at 14:47 +1000, Damien Miller wrote: > On Mon, 20 Jul 2020, Jordan J wrote: [...] > > Firstly, would the following or some combination thereof be > > possible or is there an obvious impediment. Secondly, if it proved > > possible are the maintainers open to a patch providing it? > > > > 1. Update the SSH ecdsa-sk public key type to contain the

Alon, On 12/18/2018 06:52 PM, Alon Bar-Lev wrote: > OK... So you have an issue... > > First, you need to delegate your smartcard to remote machine, probably > using unix socket redirection managed by openssh. This can be done in > many levels... > 1. Delegate USB device, this will enable only exclusive usage of the > smartcard by remote machine. > 2. Delegate PC/SC, this

Alon, I should have provided more background. You are assuming that I could perform the PKINIT prior to connecting to the SSH server. In this case (and others) there is an interest in not exposing the kerberos servers to the world and thus someone connecting remotely would not be able to obtain a TGT or do a PKINIT. The goal would be for SSH to handle all the auth and only after connecting to

I know OpenSSH currently supports PKCS11 devices (such as smartcards) for publickey authentication, but I would love to see PKCS11 extended further. It is currently possible to perform PKCS11 certificate authentication, via pam_krb5.so (on Linux at least and likely something similar on other *NIX) which allows smartcard auth to a Kerberos (including AD) server, where a TGT can also be granted.

Hey everyone, Basically, I'm trying to figure out if I can configure sshd to require that the user has a key that has been signed by a trusted user CA *and* is listed separately as an authorised key (or the user has a signed key and a different authorised key)? The closest I've come is having an `authorized_keys` file have two entries consisting of the CA key and a normal key with

I'm writing a PAM module to do authentication through Signal (as in Open Whisper Systems) [1]. I would like to be able to offer (Public key AND Signal) or (Password AND Signal) for authentication. This suggests setting AuthenticationMethods to publickey,keyboard-interactive:pam password,keyboard-interactive:pam However, when PAM is enabled "password" means "show password

On Thu, Dec 18, 2014 at 2:01 AM, Damien Miller <...> wrote: > On Wed, 17 Dec 2014, Dmt Ops wrote: > >> vi /etc/ssh/sshd_config >> ... >> - ChallengeResponseAuthentication no >> + ChallengeResponseAuthentication yes >> + KbdInteractiveAuthentication yes >>

Hi folks, Since Docker can bind-mount every .ssh directory I am looking for some way to forbid unprotected private keys. AFAICS it is currently not possible on the sshd to verify that the peer's private key was protected by a passphrase. Can you confirm? Regards Harri

> I?ve spent some time (together with Christian and Thomas) hacking on > U2F support in OpenSSH, and I?m happy to provide a first patch ? it?s > not complete, but it should be good enough to get the discussion going > :). Please see the two attached files for the patch. This is great - I'm looking forward to it! :) I've implemented U2F into another (C-based) application these

Hi all, Thanks for all your hard work! I was particularly excited to see FIDO/U2F support in the latest release. I'd like to make the following bug report in ssh-agent's PKCS#11 support: Steps to reproduce: 1. Configure a smart card (e.g. Yubikey in PIV mode) as an SSH key. 2. Add that key to ssh-agent. 3. Remove that key from ssh-agent. 4. Add that key to ssh-agent. Expected results:

Hey, Recently, the FIDO alliance announced U2F [1], and Google announced that it supports U2F tokens (?security keys?) for Google accounts [2]. As the spec is not a very short read, I gave a presentation last week about U2F which may be a good quick introduction to the details [3]. For the rest of this mail, I?ll assume that you read either my presentation or the spec, but feel free to post any

Hello list! Recently, there was a request to implement CTAP 2.1 resident credential management to Trezor, a hardware wallet which already supports FIDO2 authentication (full CTAP 2.0). My colleague Andrew[1] raised some points on GitHub and I'd like to check with you what are we missing or whether Andrew is right. Thank you for your help and understanding! Quoting from [1]: It really

Changes since OpenSSH 6.1 ========================= This release introduces a number of new features: Features: * ssh(1)/sshd(8): Added support for AES-GCM authenticated encryption in SSH protocol 2. The new cipher is available as aes128-gcm at openssh.com and aes256-gcm at openssh.com. It uses an identical packet format to the AES-GCM mode specified in RFC 5647, but uses simpler and

Hello All, The attached patch allows openssh to specify which pam service name to authenticate users against by specifying the PAMServiceName attribute in the sshd_config file. Because the parameter can be included in the Match directive sections, it allows different authentication based on the Match directive. In our case, we use it to allow different levels of authentication based on the

On Mon, 6 Jan 2025, Pavol Rusnak via openssh-unix-dev wrote: > Hello list! > > Recently, there was a request to implement CTAP 2.1 resident credential > management to Trezor, a hardware wallet which already supports FIDO2 > authentication (full CTAP 2.0). > > My colleague Andrew[1] raised some points on GitHub and I'd like to check > with you what are we missing or

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

Hi all. OpenSSH 10.0p1 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This is primarily a bugfix release, although one notable change is the introduction of the sshd-auth binary (see below). Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD:

Are there any plans on the table to add native support for two-factor authentication, such as password *and* public key? Visa PCI standards require two-factor authentication for remote access and if password+key was available in openssh it would be much easier to maintain and support than a full-blown vpn with all the cross-platform compatibility issues that come with one. Thanks! Jacob

I have sshd server sshd -V ... OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014 ... running on linux/64 with cat sshd_config ... PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no