Bug 2287 - AuthorizedKeysCommandUser should have it's default documented
Summary: AuthorizedKeysCommandUser should have it's default documented
Status: CLOSED WORKSFORME
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Documentation (show other bugs)
Version: 6.7p1
Hardware: All All
: P5 trivial
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_6_9
  Show dependency tree / graph
 
Reported: 2014-10-10 12:12 AEDT by Christoph Anton Mitterer
Modified: 2015-08-11 23:04 AEST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2014-10-10 12:12:03 AEDT 
Hi.

In sshd_config(5) AuthorizedKeysCommandUser is documented as follows:

>AuthorizedKeysCommandUser
> Specifies the user under whose account the AuthorizedKeysCommand
> is run.  It is recommended to use a dedicated user that has no
> other role on the host than running authorized keys commands.

It should have the default of this directive documented, i.e. whether it needs to be manually set when AuthorizedKeysCommand is used, or whether it's simply always the user under which sshd runs.


Cheers,
Chris.
Comment 1 Damien Miller 2014-12-11 16:25:26 AEDT 
fixed:

+If no user is specified then
+.Cm AuthorizedKeysCommand
+is ignored.
Comment 2 Christoph Anton Mitterer 2014-12-12 13:48:31 AEDT 
Hi.

I've just tried that, and it seems it's not ignored, but sshd fails to start, when AuthorizedKeysCommandUser is unset, while AuthorizedKeysCommand is set.
Comment 3 Damien Miller 2014-12-22 19:52:21 AEDT 
tweaked:

revision 1.186
date: 2014/12/22 08:04:23;  author: djm;  state: Exp;  lines: +8 -4;  commitid: GUvlwbDWDq69eUhh;
correct description of what will happen when a AuthorizedKeysCommand is
specified but AuthorizedKeysCommandUser is not (sshd will refuse to start)
Comment 4 Christoph Anton Mitterer 2014-12-23 14:39:30 AEDT 
Thanks :-)
Comment 5 Christoph Anton Mitterer 2015-02-22 05:40:18 AEDT 
Hey Damien.

Let me just reopen this once more as I've discovered by chance another unexpected behaviour by this (which might be a bug)... just have a look and decide... and feel free to close it again.

As we found out above, having:
"AuthorizedKeysCommandUser" unset while having "AuthorizedKeysCommand" set to anything but "none" and the daemon will not start.

Interestingly, having AuthorizedKeysCommandUser set to the empty value, e.g.
AuthorizedKeysCommand /bin/test
AuthorizedKeysCommandUser   

and the daemon *will* actually start, but it seems that /bin/test is nevertheless never executed.

So this is no security issue, but I guess for consistency it shouldn't start either when AuthorizedKeysCommandUser is explicitly set to the empty value.


Thanks,
Chris.
Comment 6 Damien Miller 2015-03-03 07:59:06 AEDT 
OpenSSH 6.8 is approaching release and closed for major work. Retarget these bugs for the next release.
Comment 7 Damien Miller 2015-03-03 08:01:29 AEDT 
Retarget to 6.9
Comment 8 Damien Miller 2015-05-01 13:55:26 AEST 
I don't see how sshd can start with an empty AuthorizedKeysCommandUser:

/etc/ssh/sshd_config line 60: missing AuthorizedKeysCommandUser argument.
Comment 9 Christoph Anton Mitterer 2015-06-02 08:43:06 AEST 
Which version did you use for testing?
I've just tried again with 6.7p1 and at least that behaves as I described before, i.e. it starts up with empty Username.
Comment 10 Damien Miller 2015-08-11 23:04:56 AEST 
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1