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

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux