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

[mailto428496]

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