https://bugzilla.mindrot.org/show_bug.cgi?id=2663
Bug ID: 2663 Summary: [man] sshd_config(5) AuthenticationMethods segment clarification, proposal and questions Product: Portable OpenSSH Version: 7.2p2 Hardware: Other OS: Linux Status: NEW Keywords: low-hanging-fruit Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-b...@mindrot.org Reporter: bg...@gmx-topmail.de 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... -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs