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