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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
