Auth via Multiple Publickeys, Using Multiple Sources, One Key per Source

[Brian Candler]

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.