openssh unix dev - Jun 2020 - Auth via Multiple Publickeys, Using Multiple Sources, One Key per Source

I don't see a way to do this currently (unless I am missing something) 
but I would like to be able to specify, that in order for a user to 
login, they need to use at least 1 public key from 2 separate key 
sources.? Specifically this would be when using "AuthenticationMethods 
publickey,publickey".? Right now requiring 2 public keys for 
authentication will allow 2 public keys from any authorized key source 
specified without distinction.? I would like a way to say, require 1 key 
from source A and 1 key from source B.

Like if there was a way to specify something like this for example:

AuthenticationMethods publickey[1],publickey[2]

AuthorizedKeysCommand[1] <source_a_command_script>

AuthorizedKeysCommand[2] <source_b_command_script>

and the same for AuthorizedKeysFile (for our needs multiple commands 
would be fine, but might as well support it for both)

Let me also give an example of why I am interested in this, for 
context.? 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, 
such as a smartcard (we don't want 2 "client machine" public keys
to be
able to be combined to bypass the user's token login).? A (poor) 
workaround is to use the same private key on all of the users machines 
but I would prefer not to do this, both in general for security reasons 
and also so that if a user's machine is lost, stolen or we just want to 
deauthorize it, the pubkey for that machine can be removed from the 
database.

Anyway, I don't see a way to do this currently so I thought I would 
throw it out there as a potential future enhancement.? Or please 
enlighten me if there is some magic way to do this that I am missing ;-)

Thanks,


Jim

On 03/06/2020 09:30, mailto428496 wrote:
>
> Let me also give an example of why I am interested in this, for 
> context.? 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, such as a smartcard (we don't want 2 "client machine"
public
> keys to be able to be combined to bypass the user's token login).? A 
> (poor) workaround is to use the same private key on all of the users 
> machines but I would prefer not to do this, both in general for 
> security reasons and also so that if a user's machine is lost, stolen 
> or we just want to deauthorize it, the pubkey for that machine can be 
> removed from the database. 
I can't answer your question directly, but I do run a somewhat 
comparable setup. In my case, the user token is a Yubikey running in its 
original OTP mode rather than as a smartcard, which lets me combine 
publickey with keyboard-interactive.

==> sshd_config <=
# Policy for authentication
AuthenticationMethods publickey,keyboard-interactive:pam

# From office and VPN addresses, 2FA not required
Match Address 192.168.0.0/16,10.0.0.0.8/,fd00::/8
AuthenticationMethods publickey

==> /etc/pam.d/ssh <=
#@include common-auth
auth sufficient pam_yubico.so id=XXXX key=XXXX debug 
authfile=/etc/yubikey_mapping mode=client

==> /etc/yubikey_mapping <=
brian:ccccccxxxxxx

Note that the server needs to be able to make outbound HTTPS calls to 
the Yubikey OTP validation API (at least, if you don't want to run your 
own key management infrastructure)

-=-=-=-

It seems the underlying use case here is you want to certify each client 
device individually, as well as the user holding the token.

I can suggest another way to achieve that: use a U2F (FIDO) security 
token with ecdsa-sk keys.

You generate a new ecdsa-sk pair on each device, but wrapped with the 
same FIDO token.? You put all of those public keys in your 
authorized_keys file.? In order to login, the user requires any one of 
the devices containing an authorized ecdsa-sk private key *and* its 
passphrase *and* the correct FIDO token to unlock it. If a device is 
stolen, you can disable just the ecsda-sk key for that device.? If the 
FIDO token is stolen, then all keys are useless and you'll need to rekey 
all devices with a new token.

This works well (and FIDO tokens are cheap), but requires openssh 8.2+ 
at both client and server side.

One other idea which is closer to your original intent: would it be 
possible to use the smartcard to decrypt the private key on each 
device?? In other words, you want an ssh-agent which doesn't use your 
smartcard to authenticate, but uses your smartcard to decrypt the stored 
private key which is then used to authenticate.? I don't know if such a 
thing exists.

Regards,

Brian.

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, 
> such as a smartcard (we don't want 2 "client machine" public
keys to be
> able to be combined to bypass the user's token login).
..
> some magic way to do this that I am missing ;-)
Couldn't you use hostbased authentication for client machines and
publickey for users?


//Peter

Brian,

On 2020-06-03 05:11, Brian Candler wrote:
> On 03/06/2020 09:30, mailto428496 wrote:
>>
>> Let me also give an example of why I am interested in this, for 
>> context.? 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, such as a smartcard (we don't want 2
"client
>> machine" public keys to be able to be combined to bypass the
user's
>> token login).? A (poor) workaround is to use the same private key on 
>> all of the users machines but I would prefer not to do this, both in 
>> general for security reasons and also so that if a user's machine
is
>> lost, stolen or we just want to deauthorize it, the pubkey for that 
>> machine can be removed from the database. 
>
> I can't answer your question directly, but I do run a somewhat 
> comparable setup. In my case, the user token is a Yubikey running in 
> its original OTP mode rather than as a smartcard, which lets me 
> combine publickey with keyboard-interactive.
>
> ==> sshd_config <=>
> # Policy for authentication
> AuthenticationMethods publickey,keyboard-interactive:pam
>
> # From office and VPN addresses, 2FA not required
> Match Address 192.168.0.0/16,10.0.0.0.8/,fd00::/8
> AuthenticationMethods publickey
>
> ==> /etc/pam.d/ssh <=>
> #@include common-auth
> auth sufficient pam_yubico.so id=XXXX key=XXXX debug 
> authfile=/etc/yubikey_mapping mode=client
>
> ==> /etc/yubikey_mapping <=>
> brian:ccccccxxxxxx
>
> Note that the server needs to be able to make outbound HTTPS calls to 
> the Yubikey OTP validation API (at least, if you don't want to run 
> your own key management infrastructure)

When combining publickey with keyboard-interactive:pam you can have an 
unlimited number of publickeys, and we actually have some situations 
where we are using that to combine the user client based pubkey with 
keyboard-interactive:pam for say SecurID login. In this case it works 
fine as pubkey is only used once so you can have an unlimited number of 
client pubkeys without the worry of them being combined to override 
additional authentication requirements.

>
> -=-=-=-
>
> It seems the underlying use case here is you want to certify each 
> client device individually, as well as the user holding the token.
>
> I can suggest another way to achieve that: use a U2F (FIDO) security 
> token with ecdsa-sk keys.
>
> You generate a new ecdsa-sk pair on each device, but wrapped with the 
> same FIDO token.? You put all of those public keys in your 
> authorized_keys file.? In order to login, the user requires any one of 
> the devices containing an authorized ecdsa-sk private key *and* its 
> passphrase *and* the correct FIDO token to unlock it. If a device is 
> stolen, you can disable just the ecsda-sk key for that device.? If the 
> FIDO token is stolen, then all keys are useless and you'll need to 
> rekey all devices with a new token.
>
> This works well (and FIDO tokens are cheap), but requires openssh 8.2+ 
> at both client and server side.
Unfortunately adding additional hard tokens like U2F is not currently an 
option in this case.

>
> One other idea which is closer to your original intent: would it be 
> possible to use the smartcard to decrypt the private key on each 
> device?? In other words, you want an ssh-agent which doesn't use your 
> smartcard to authenticate, but uses your smartcard to decrypt the 
> stored private key which is then used to authenticate.? I don't know 
> if such a thing exists.
I am not aware of a way to do that easily, especially using the standard 
SSH client tools.


Thanks,


Jim

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,
>> such as a smartcard (we don't want 2 "client machine"
public keys to be
>> able to be combined to bypass the user's token login).
> ..
>> some magic way to do this that I am missing ;-)
> Couldn't you use hostbased authentication for client machines and
> publickey for users?
That had occurred to me, but in our case users sometimes connect from 
shared systems that are outside of our direct control and we would like 
to control pubkey client access on a per user basis rather than per machine.

Thanks,


Jim

Do you know about certificates for openssh?

You create a ca for hostkeys and another for clientkeys.

Then you create a certificate for all of your hostkey-publickeys with
your host-ca.
Publish this certificates to all of your hosts and change the
configuration of sshd to use this certificates also.

Publish the public-key of your user-ca to all hosts.


Publish the pubkey for Host-ca to all your clients.

Then create certificates with user-ca for all of all users Pubkeys. Add
prinzipals (one or more) to this user-certs. Give it to the users.

Change ssh_config to accept only hosts with valid host-certs.

Create mapping-files. Each pam-user gets its own file, where the
principals are listed (one per line), which are allowed to login as this
user.

You dont need to accept a changed hostkey anymore. You can regulate with
principalfile, which user can login as which user. You can also use a
script instead of this files, so ldap or other mechanisms are possible
too via script.

Certs can have a serialnumber and a validydate.. You can revoke by
pubkey the whole user, or revoke by serialnumer.

This is a first entypoint:
https://chandanduttachowdhury.wordpress.com/2014/12/31/certificate-based-ssh-user-authentication/

Many howtos talk about pubkeys instead of certificates, when you search
on you searchengine. Be careful of your searches. Certificates are using
pubkeys, they are not pubkeys!!

Regards

Jakob

-- 
lore ipsum

On Wed, 3 Jun 2020, mailto428496 wrote:
> I don't see a way to do this currently (unless I am missing something) 
> but I would like to be able to specify, that in order for a user to 
> login, they need to use at least 1 public key from 2 separate key 
> sources.? Specifically this would be when using "AuthenticationMethods
> publickey,publickey".? Right now requiring 2 public keys for 
> authentication will allow 2 public keys from any authorized key source 
> specified without distinction.? I would like a way to say, require 1 key 
> from source A and 1 key from source B.
> 
> Like if there was a way to specify something like this for example:
> 
> AuthenticationMethods publickey[1],publickey[2]
> 
> AuthorizedKeysCommand[1] <source_a_command_script>
> 
> AuthorizedKeysCommand[2] <source_b_command_script>
> 
> and the same for AuthorizedKeysFile (for our needs multiple commands 
> would be fine, but might as well support it for both)
There's no way to do this at present. If we can figure out a good
syntax for expressing it, then we could add it (a few people have
asked for similar things before).

-d

Damien,

Thanks, it would be great if this functionality could be added!

I haven't thought about the syntax too much other than my quick proposal 
below.? But assuming the old syntax would be left as is and the new 
multiple source syntax would be optional?? Maybe 'publickey' could be an
alias for 'publickey[0]' for backward compatibility, and the same thing 
for the accompanying AuthorizedKeys* options that would be referenced?


Jim


On 2020-06-03 19:13, Damien Miller wrote:
> On Wed, 3 Jun 2020, mailto428496 wrote:
>
>> I don't see a way to do this currently (unless I am missing
something)
>> but I would like to be able to specify, that in order for a user to
>> login, they need to use at least 1 public key from 2 separate key
>> sources.? Specifically this would be when using
"AuthenticationMethods
>> publickey,publickey".? Right now requiring 2 public keys for
>> authentication will allow 2 public keys from any authorized key source
>> specified without distinction.? I would like a way to say, require 1
key
>> from source A and 1 key from source B.
>>
>> Like if there was a way to specify something like this for example:
>>
>> AuthenticationMethods publickey[1],publickey[2]
>>
>> AuthorizedKeysCommand[1] <source_a_command_script>
>>
>> AuthorizedKeysCommand[2] <source_b_command_script>
>>
>> and the same for AuthorizedKeysFile (for our needs multiple commands
>> would be fine, but might as well support it for both)
> There's no way to do this at present. If we can figure out a good
> syntax for expressing it, then we could add it (a few people have
> asked for similar things before).
>
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev