Bug 2288 - documentation of options defaulting to "none"
Summary: documentation of options defaulting to "none"
Status: CLOSED FIXED
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 treegraph
 
Reported: 2014-10-10 13:02 AEDT by Christoph Anton Mitterer
Modified: 2021-03-04 09:54 AEDT (History)
3 users (show)

See Also:


Attachments
make config parser more consistent (993 bytes, patch)
2015-03-07 02:14 AEDT, Jakub Jelen
dtucker: ok+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2014-10-10 13:02:54 AEDT
Hey.

I was just going through the documentation, and there are several options which are documented to default to "none", e.g. in sshd_config(5):

>AuthorizedPrincipalsFile
...
> The default is “none”, i.e. not to use a principals file – in
...

or

>Banner  The contents of the specified file are sent to the remote user
> before authentication is allowed.  If the argument is “none” then
> no banner is displayed.  This option is only available for proto‐
...

Now I looked through through the code, and it doesn't look as if "none" would really be handled special for these options, a test with "Banner none" confirmed this, if there is a file /none, it's contents are printed.


To the contrary, there are options in servconf.c for which "none" *is* apparently actually considered special, as e.g. AuthorizedKeysCommand.


I would guess that the same issues may happen again for other options for both, sshd and ssh.


1) So ideally someone should really go through all the options, and check whether the defaults still match.

2) The manpages should somehow better denote, what is actually value and what is just prose text, since “none” (as it also appears for “yes”) could mean both, the literal string "none", i.e.:
DirectiveName none
or that the directive's value is empty, i.e.:
DirectiveName ""

3) I personally tend to generally using the later or somehow better handling cases when a directive may take special enums and aribtrary strings like filenames.


Cheers,
Chris.
Comment 1 Damien Miller 2014-12-22 20:06:12 AEDT
fixed; will be in openssh-6.8

commit 8f6784f0cb56dc4fd00af3e81a10050a5785228d
Author: djm@openbsd.org <djm@openbsd.org>
Date:   Mon Dec 22 09:05:17 2014 +0000

    upstream commit
    
    mention ssh -Q feature to list supported { MAC, cipher,
     KEX, key } algorithms in more places and include the query string used to
     list the relevant information; bz#2288
Comment 2 Damien Miller 2014-12-22 21:38:17 AEDT
oops, wrong bug
Comment 3 Damien Miller 2015-03-03 07:59:25 AEDT
OpenSSH 6.8 is approaching release and closed for major work. Retarget these bugs for the next release.
Comment 4 Damien Miller 2015-03-03 08:01:03 AEDT
Retarget to 6.9
Comment 5 Jakub Jelen 2015-03-07 02:14:29 AEDT
Created attachment 2564 [details]
make config parser more consistent

Tested option Banner with current upstream and it works fine now. FYI: Fixed in
https://anongit.mindrot.org/openssh.git/commit/?id=161cf419f412446635013ac49e8c660cadc36080

AuthorizedPrincipalsFile option is fixed in different way in this commit (which is fur sure not so elegant as the previous one and it would be really nice to have it more consistent):
https://anongit.mindrot.org/openssh.git/commit/?id=9fed161e67b23977a1070419b356084295422f0c

If you want to have it in more elegant way, there is attached patch. Otherwise you can close this issue as resolved.
Comment 6 Damien Miller 2015-05-01 13:56:32 AEST
Comment on attachment 2564 [details]
make config parser more consistent

looks ok to me
Comment 7 Damien Miller 2015-05-01 14:18:03 AEST
patch applied, will be in openssh-6.9
Comment 8 Damien Miller 2015-08-11 23:05:21 AEST
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1
Comment 9 Christoph Anton Mitterer 2015-11-02 09:16:48 AEDT
Hey.

I just tried to verify this, and it seems there are still options left which can have a special value of "none" but for which this isn't documented (at least as of 6.9):
- HostKey
- HostCertificate
and as already mentioned before:
- AuthorizedKeysCommand

Since this is marked as fixed in 6.9, I'm reopening it.

Cheers,
Chris.
Comment 10 Christoph Anton Mitterer 2015-11-02 10:38:42 AEDT
And one more where there is "none" but nothing mentioned in the docs:
- AuthorizedPrincipalsCommand
Comment 11 Christoph Anton Mitterer 2015-11-04 05:59:03 AEDT
And another one, but this time in ssh_config:
- RevokedHostKeys
Comment 12 Damien Miller 2020-01-26 00:07:46 AEDT
I don't think we need to chase this further.
Comment 13 Christoph Anton Mitterer 2020-02-04 13:42:33 AEDT
Well, it's your project, so decide as it pleases you... :-)

But I still think its a bad idea to not document specially handled option values (i.e. "none") where otherwise a free form string could be used.

It may be unlikely but people could in principle use and AuthorizedKeysCommand called "none" which would, AFIAU, *not* be called unlike the documentation would suggest (by not mentioning "none" is special.
Same goes for the other commands I've found earlier (though I haven't checked the current code, whether this is still the case).

Cheers,
Chris.
Comment 14 Damien Miller 2021-03-04 09:54:43 AEDT
close bugs that were resolved in OpenSSH 8.5 release cycle