Bug 1219820
Summary: | Lack of clarity of Match block processing and RequiredAuthentications2 limitation | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Ted Rule <ejtr> | ||||
Component: | openssh | Assignee: | Jakub Jelen <jjelen> | ||||
Status: | CLOSED ERRATA | QA Contact: | Stanislav Zidek <szidek> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.5 | CC: | ejtr, jjelen, plautrba, szidek | ||||
Target Milestone: | rc | Keywords: | Documentation | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | openssh-5.3p1-113.el6 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2016-05-10 19:28:38 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Ted Rule
2015-05-08 11:01:55 UTC
Created attachment 1024634 [details] proposed patch for addrmatch The parsing of configuration files is quite complicated thing in openssh. First of all it is required to know, that > "For each parameter, the first obtained value will be used." which is in ssh_config(5), but unfortunately not in sshd_config(5) manual page. This can be fixed as a thing (1). Upstream also mentions this in later versions directly in sshd_config(5) next to Match keyword: > If a keyword appears in multiple Match blocks that are satisfied, only the first instance of the keyword is applied. This is also quite important to know so this can be also backported into rhel-6 as a fix (2). Another important thing is that config files are parsed in more runs. * First when you start sshd daemon it has to read many important configuration options, _without_ any knowledge about remote client. In this run it doesn't even fall into "Match *" block. * Another round is made when you have some information about remote client. In your example it is parsed correctly, but as pointed out in the beginning, only the first option value is used. Your use-case with Banner works for me as explained in testing mode and in real tests: [root@r6 ~]# tail /etc/ssh/sshd_config -n 5 banner /etc/ssh/default_banner Match Address 127.0.0.1 Banner /etc/ssh/hello-localhost.txt Match Address * Banner /etc/ssh/hello-unknown-party.txt [root@r6 ~]# sshd -T | grep banner banner /etc/ssh/default_banner [root@r6 ~]# sshd -TC user=none,host=myhost,addr=1.2.3.4 | grep banner banner /etc/ssh/hello-unknown-party.txt [root@r6 ~]# sshd -TC user=none,host=myhost,addr=127.0.0.1 | grep banner banner /etc/ssh/hello-localhost.txt [root@r6 ~]# ssh localhost Hello Localhost [jjelen@jjelen ~]$ ssh rhel6 Hello Unknown Party About the second issue with RequiredAuthentications2 I would recommend such a solution, but as I tried it doesn't work for me: [root@r6 ~]# tail -n 3 /etc/ssh/sshd_config requiredauthentications2 password Match Address !1.2.3.4 RequiredAuthentications2 publickey,password The match for ip address is made somehow ... strange ... that the negative match doesn't work at all (it is never matched) with ip addresses. This should be fixed by this code snippet (attachment) - I will propose it upstream as a fix (3). With this fix I am able to achieve with above mentioned config such a result: [root@r6 build]# ./sshd -TC user=none,host=myhost,addr=1.2.3.4 | grep required requiredauthentications2 password [root@r6 build]# ./sshd -TC user=none,host=myhost,addr=1.2.3.5 | grep required requiredauthentications2 publickey,password We had some problem with this option recently, and in such cases it can be problem that we don't have a default value because it is one of the last inconsistent values. Proposing value "any" as default sounds like a good idea. Change proposal (4). >There appears to be an undocumented feature of RequiredAuthentications2 which can be set to "none", which seemingly causes Authentication to ALWAYS fail. Yes, you are right. This would be good to have in manual pages. As I see, it is not even documented in upstream AuthenticationMethods. Proposing this as a fix (5) from this bugzilla. Thanks for reporting, stay tuned about changes and feel free to comment on my findings. Seems like I forgot to report the upstream bugs back here: 3) https://bugzilla.mindrot.org/show_bug.cgi?id=2397 4) https://bugzilla.mindrot.org/show_bug.cgi?id=2398 5) https://bugzilla.mindrot.org/show_bug.cgi?id=2453 To other mentioned things and about backporting, please discuss your issue with your regular red hat support. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-0741.html |