Bug #499

changes to user authorized_keys files not immediately incorporated

Added by jrollins about 5 years ago. Updated over 3 years ago.

Status:NewStart date:01/30/2009
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:monkeysphere
Target version:1.0

Description

In the current default configuration, the user-controlled authorized_keys file is appended to the end of the monkeysphere-controlled authorized_keys file. However, this is only done when an administrator run the update-users command. This means that users can add keys to authorized_keys file, but then still not be able to log in with that key until the admin does an update.

We could by default schedule updates, but that still means there would potentially still be an unknown delay for the user.

How do we get around this? incron is a possibility, but it would requires another unusual dependency.


Related issues

Related to Monkeysphere - Bug #500: cron.hourly script needed New 01/30/2009

History

#1 Updated by jrollins about 5 years ago

I found an old ssh bug about supporting multiple AuthorizedKeysFile options, with patch, in the ssh bugzilla. I added a comment to it, with the hopes of reviving it. The more I think about it, the more I think that having sshd support multiple AuthorizedKeysFile options is the Right way to fix this issue. Would folks be interested in trying to work on a newer patch to ssh?

#2 Updated by dkg about 5 years ago

I like jamie's proposal about the change to openssh. Reading the arguments in that bug, and thinking about how i'd like monkeysphere to be configurable, i'm convinced that that's the right way to resolve all of this in the long run.

So i think that updating the openssh patch to work with recent versions (5.1p1 at least) would be a good project. But even if it were adopted in a new version of OpenSSH, we'd need to support the other alternatives for a little while before the new OpenSSH is widely distributed.

#3 Updated by dkg about 5 years ago

btw, i don't think that incron would need to be a dependency; we could support a cronjob (for everyone), and Suggest or Recommend incron, providing useful incron instructions for those administrators who choose to install it.

Conflict between the two schemes could be avoided by having the cronjob test for the availability of incron, and simply disable itself in that case.

#4 Updated by jrollins about 5 years ago

  • Priority changed from Normal to Elevated

#5 Updated by jamie about 5 years ago

Hi all,

I haven't made any progress on incron since our last hack day, but wanted to let you know where I'm at (in case anyone else is itching to get this working).

I'm still testing - but am stuck with simply getting incron to work as I expect it to. At the moment I can get it to take an action the first time a file that it's watching has been modified, but not subsequent times. I suspect I'm doing something wrong, but haven't yet continued my investigations.

jamie

#6 Updated by dkg about 5 years ago

  • Target version set to 1.0

#7 Updated by jrollins over 4 years ago

So we just found out that there is an undocumented feature in sshd that supports an AuthorizedKeysFile2 option that can be used to specify a second authorized_keys file. This is of course a solution for this bug (see comment #1). For some reason the documentation about this bug was removed upstream]. If we could get this documentation put back and a guarantee that it will be supported, then that would be a great help. We should push on that.

#8 Updated by jrollins over 4 years ago

jrollins wrote:

I found an old ssh bug about supporting multiple AuthorizedKeysFile options, with patch, in the ssh bugzilla. I added a comment to it, with the hopes of reviving it. The more I think about it, the more I think that having sshd support multiple AuthorizedKeysFile options is the Right way to fix this issue. Would folks be interested in trying to work on a newer patch to ssh?

There's also a brand new Debian bug dealing with this , which includes a patch. Hopefully this will get pushed through upstream.

#9 Updated by jrollins about 4 years ago

  • Category set to monkeysphere
  • Priority changed from Elevated to Normal

#10 Updated by jamie over 3 years ago

I've just taken a first stab and closing this ticket.

It's a file called monkeysphere-monitor-keys in the examples directory.

My new repository can be reached via: :jamie/monkeysphere.git

I started with incron, however abandoned that approach because it required too many separate pieces (one piece to generate the incrontab file with all the directories to watch, one piece to re-generate the list every time a new user is added, one piece as a wrapper to monkeysphere-authentication u that figures out which user to update based on the changed file).

Next, on dkg's suggestion, I started working with the perl inotify2 module. However, mlc pointed out that inotify is linux specific. I finally settled on File::ChangeNotify, which is a cross-platform module. If Linux::Inotify2 is installed, it will be used, otherwise, a cross platform default module is used.

You can optionally pass the path to a file that, if changed, indicates that the user list should be reloaded. /etc/passwd was intended as the file to be passed, but for some reason, when using inotify, user additions to this file are ignored (the default module works though).

Once Debian bug 36019 is fixed it might be trivial to edit a file in /var/lib/monkeysphere/ every time a new user is added and have this script monitor that file.

The script doesn't handle signals and there's no direction for how to launch it (no init script or runit files, etc.). It probably has other flaws both minor and structural (I'm not very proficient in perl).

Suggestions welcome.

jamie

#11 Updated by jamie over 3 years ago

More changes based on dkg's suggestions have been pushed to git://git.mayfirst.org/jamie/monkeysphere:

  • Comments at top now contains more concrete explanation of how the script works.
  • Location of key files to monitor is more configurable by the sys admin.
  • All changed files treated the same for simplicity.
  • Added debug mode.

To do:

  • Respond to sighup signal by re-loading user list
  • add runit style directory to ease deployment as a always running service

Questions:

I hard coded '/var/lib/monkeysphere/user-update/lastchange as the file to monitor for new users being added to the system (any change in that file causes a reload of the user list).

Would it be appropriate to add a new variable to /etc/monkeysphere/monkeysphere-authentication to allow that directory to be changed?

And - suggestions for a variable name and a better default name/path?

jamie

#12 Updated by jamie over 3 years ago

Thanks for the additional feedback dkg - just pushed more changes that cover most of your FIXMEs.

At the top of the file you write:

# FIXME: does this handle revocations and re-keying?  if a sysadmin
# switches over to this arrangement, how will the system check for
# revocations?  Scheduling a simple gpg --refresh should handle
# revocations.  I'm not sure how to best handle re-keyings.

I think you are getting at the idea that this script would completely replace the cron job that normally calls m-a u for all users.

I don't think it will ever replace that for the reasons you are indicating. I think it will have to exist along with that cron job. We could try to get this script to do regular m-a u against all users, but it seems like it would be more complicated than just leaving the cron job in place.

Let me know if I'm mis-understanding where your comment was coming from...

jamie

#13 Updated by dkg over 3 years ago

jamie wrote:

I don't think it will ever replace that for the reasons you are indicating. I think it will have to exist along with that cron job.

ah, ok. this makes sense to me now. i was hoping that we'd get an added bonus of being able to cut down on the overhead of the cronjob, but i guess that won't be possible.

We could try to get this script to do regular m-a u against all users, but it seems like it would be more complicated than just leaving the cron job in place.

I could go either way on this. One advantage of doing it in this daemon is that it's a way to potentially consolidate all the configuration for this kind of update. For instance, the administrator might decide that they want revocation updates hourly, but can afford to wait 24 hours for a re-keying to take effect. In that case, a simple gpg --refresh on the m-a sphere keyring would happen hourly, but the more expensive system-wide monkeysphere-authentication update-users could be relegated to a nightly run.

Of course, this could be done with cronjobs too.

#14 Updated by jamie over 3 years ago

I just created #2699 to have monkeysphere-monitor-keys replace the m-a u cron job so that it doesn't hold back this more limited feature.

#15 Updated by dkg over 3 years ago

jamie wrote:

I hard coded '/var/lib/monkeysphere/user-update/lastchange as the file to monitor for new users being added to the system (any change in that file causes a reload of the user list).

Would it be appropriate to add a new variable to /etc/monkeysphere/monkeysphere-authentication to allow that directory to be changed?

And - suggestions for a variable name and a better default name/path?

i don't think a new variable is necessary; i'd choose the monitoring file based on the same logic monkeysphere uses to find $SYSDATADIR.

Also available in: Atom PDF