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

mailto428496 mailto628496 at
Thu Jun 4 05:34:53 AEST 2020


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.



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

More information about the openssh-unix-dev mailing list