Bug 2663 - [man] sshd_config(5) AuthenticationMethods segment clarification, proposal and questions
Summary: [man] sshd_config(5) AuthenticationMethods segment clarification, proposal an...
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 7.2p2
Hardware: Other Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords: low-hanging-fruit
Depends on:
Blocks: V_7_8
  Show dependency treegraph
 
Reported: 2017-01-09 12:33 AEDT by Hans Meier
Modified: 2021-04-23 14:59 AEST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hans Meier 2017-01-09 12:33:31 AEDT
Segment's first paragraph reads:
AuthenticationMethods
    ... This option must be followed by one or more __comma-separated lists__ of authentication method names. ...

Suggested change
    ... This option must be followed by one or more lists of __comma-separated authentication method names__. ...

Rationale:
The current wording is misleading; not the lists are comma-separated, but their elements; any pair of neighbouring lists is space-separated.
----------

My approach was:
Taking the example of the second paragraph's first sentence (without considering the subsequent explanation)
    ... âpublickey,password publickey,keyboard-interactiveâ ...
the misleading statement about the list separator would have to yield three authentication paths, either with:
   "publickey" or "password and publickey" or  "keyboard-interactive"
Testing a configuration with just "password,publickey" in an actual sshd_config file made it apparent that a single list is at hand, as an authentication only occurs if the password input can be augmented with the retrieval of a keyfile (otherwise, the client reports "Authenticated with partial success.").
----------

And something else is at play:
    AuthenticationMethods password publickey
    AuthenticationMethods publickey password

Both fail to authenticate, if no publickey is present; apparently, the first (and only) items of the 2 lists are brought into a default order of "publickey password"; this cannot be inferred from invoking
    sshd -T -f /etc/ssh/sshd_config
which seems to suggest that the order remains as originally set in sshd_config.
Granted, single item lists do not warrant usage of "AuthenticationMethods". But this fails as well:
    AuthenticationMethods password publickey,password
(Again, a rather useless combination from a practical view)
The client specifically stating not to use public key auth remedies the issue:
    ssh user@host -o "PubkeyAuthentication no"
My suggestion for this would be to extend the manual section by a sentence that states the order of precedence of authentication methods within a given "stage".
----------

For me, with regard to the manual segment of AuthenticationMethods, a question remains with the term "stage" in paragraph 2, sentence 2:
    Only methods that are next in one or more lists are offered at each stage, ...
Is this supposed to say that, for example:
    AuthenticationMethods password,publickey  hostbased,keyboard-interactive
could result in a user being authenticated by "hostbased publickey"?

If so, then the last sentence of the section's paragraph 1:
    Successful authentication requires completion of every method in at least one of these lists.
would be incorrect in so far that - strictly speaking - none of the given lists was completed, but a new one was assembled.

Thanks for any clarifications -  and maybe, this helps some other folks when preparing and testing an sshd configuration.
----------

Beyond this topic, is there a reason why only the first occurrence of AuthenticationMethods is honored? As with HostKey, Port, ..., reocurring keywords' values could be appended...
Comment 1 Damien Miller 2018-07-20 15:01:20 AEST
I've committed the wording change you suggested - thanks!

> Beyond this topic, is there a reason why only the first occurrence of 
> AuthenticationMethods is honored? As with HostKey, Port, ..., reocurring 
> keywords' values could be appended...

Most configuration keywords are first-match-wins. The ones you mention there are the exception.
Comment 2 Damien Miller 2021-04-23 14:59:55 AEST
closing resolved bugs as of 8.6p1 release