We'd like to run sshd with a configuration morally equivilent to: # stuff ... AuthorizedKeysFile /var/db/keys-distributed-by-security-team/%u AuthorizedKeysFile %h/.ssh/authorized_keys # be backwards compatable for a bit longer yet AuthorizedKeysFile %h/.ssh/authorized_keys2 # more stuff ... The following patch (against the cvs source) turns the authorizedkeysfile statement in sshd.conf into one which populates a list of such files. I've also turned "authorizedkeysfile2" into an alias for "authorizedkeysfile" (but perhaps it out to be deprecated instead).
Created attachment 48 [details] Multiple AuthorizedKeyFile patch
I would perfer not myself. The reason why we went down to ONE authorization file was to simplify management. Allowing multiple key locations is asking for trouble. How do you handle the case where you have two alike authorization entries with conflicting key options (command=,environment=,etc)? Which one takes priority? First come first serve? No, you should have one spot only.
> ------- Additional Comments From mouring@eviladmin.org 2002-04-06 08:08 > ------- > I would perfer not myself. The reason why we went down to ONE authorization > > file was to simplify management. Allowing multiple key locations is > asking for trouble. If this were the default behaviour, I'd agree. It's not. It can be turned on only by deliberate administrator action. We automatically distribute the /var/db/keys-distributed-by-security-team/%u section (and have other evil hacks that allow keys in this location to be owned by a special user - those hacks aren't in the patch). This preserves the principal of least astonishment by seperating out the keys that the security team modify (and potentially clobber) from the keys that the users expect to have control over. > How do you handle the case where you have two alike authorization entries > with > conflicting key options (command=,environment=,etc)? Which one takes > priority? First come first serve? There's already that possibility today - you can have multiple keys which can match in a single file, the first match is the one that gets used. > No, you should have one spot only. Agreed you should have only one by default, but I don't think the flexibility loses you anything.
If someone comes up with a patch, then we can discuss that.
The patch we have is: http://bugzilla.mindrot.org/showattachment.cgi?attach_id=48 but thats against 3.1p1, I'll update it to against current CVS later today (and fix the man page which I forgot last time around).
Created attachment 88 [details] Implement multiple authorized keys against CVS copy from openssh@anoncvs.be.openbsd.org:/cvs as of 2002/4/23
I realize this issue is quite old, but I would really like to see this option available as well. I think there are a couple of very good reason to add this feature. It is possible to configure systems to handle AuthorizedKeys files in multiple ways. Things can be configured such that the file is maintained by the user (when using the typical %h/.ssh/authorized_keys setting), or so that it is maintained by an administrator (eg. /etc/ssh/authorized_keys/%u). If multiple AuthorizedKeysFile options were allowed, sshd could easily support both user <i>and</i> administrator controlled files. I can see this being useful in many situations, but it would particularly be useful for the <a href="http://web.monkeysphere.info">monkeysphere</a>, where we would like to be able to support both monkeysphere-maintained and user maintained authorized_keys files. I also think the issue about multiple matching keys is not a worry. As Alex Kiernan points out, it is possible to have multiple matching keys in a single file, and the way around it is to accept the options from the first encountered key.
Another (more recent) patch for this feature is available at http://bugs.debian.org/560148, along with some caveats about how a feature like this might interact with any future inclusion of AuthorizedKeysFile with the Match directive.
bug 1684 was just filed, which looks like it might be a duplicate of this one.
If this is implemented, it would be nice if wildcards were be possible as well, such as AuthorizedKeysFile %h/.ssh/authorized_keys.d/* That would save me from having cat ~/.ssh/authorized_keys.d/* > ~/.ssh/authorized_keys in my login scripts. Greetings Marc
I too would like to see this implemented sometime this millennium. What's the hold up? R.
This was implemented a few releases ago, in openssh-5.9. AuthorizedKeysFile may have multiple arguments now.
*** Bug 1684 has been marked as a duplicate of this bug. ***
Close all resolved bugs after 7.3p1 release