Mailing List Archive

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

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

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

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

mailto428496 wrote:
> > 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.

Hostbased authentication can use per-user host keys.

Or maybe I don't understand your point?

Hostbased auth can consider both system-wide (on server) public host keys
(for client hosts) as well as per-user (on server) public host keys
(for client hosts).


In addition to hostbased, publickey authentication then requires the
user to also authenticate themselves to the server, as usual.


Now, I don't think there is a hook for host public keys like there is
for user public keys, but maybe you can use it anyway?


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Peter,

I see your point, but it is not ideal for systems that we don't
control.  The user would have to hunt down the hostkey for that host to
provide it to us, which might be in /etc/ssh or it might be elsewhere
and it may or may not be accessible to the user. Also, the system admins
could change the hostkeys which would then require the user to grab a
new hostkey.  Although potentially doable, it adds a lot of complication
to the process.  We would prefer to have the client pubkey tied to the
user's account rather than the client hostkey, and in many cases the
remote system may be comprised of many different hosts that all share
the same home directory - we would not want to have to deal with the
potential for lots of different hostkeys where a single user account is
used across a system enclave.  The hostbased auth would be a good
solution when the user connects from a system we manage, where we can
help them set it up and know when keys change, but much more problematic
for shared systems controlled by other organizations.

Thanks,


Jim


On 2020-06-03 14:07, Peter Stuge wrote:
> mailto428496 wrote:
>>> 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.
> Hostbased authentication can use per-user host keys.
>
> Or maybe I don't understand your point?
>
> Hostbased auth can consider both system-wide (on server) public host keys
> (for client hosts) as well as per-user (on server) public host keys
> (for client hosts).
>
>
> In addition to hostbased, publickey authentication then requires the
> user to also authenticate themselves to the server, as usual.
>
>
> Now, I don't think there is a hook for host public keys like there is
> for user public keys, but maybe you can use it anyway?
>
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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

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