Auth via Multiple Publickeys, Using Multiple Sources, One Key per Source
mailto428496
mailto628496 at cox.net
Thu Jun 4 05:34:53 AEST 2020
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 at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
More information about the openssh-unix-dev
mailing list