Bug 869903
Summary: | RequiredAuthentications2 does not work in Match blocks as documented. | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Steven Haigh <netwiz> | ||||
Component: | openssh | Assignee: | Petr Lautrbach <plautrba> | ||||
Status: | CLOSED ERRATA | QA Contact: | Patrik Kis <pkis> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.3 | CC: | bkurt, jjaburek, netwiz, pasteur, pkis, pvrabec | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
URL: | https://bugzilla.mindrot.org/show_bug.cgi?id=983 | ||||||
Whiteboard: | |||||||
Fixed In Version: | openssh-5.3p1-83.el6 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 872608 (view as bug list) | Environment: | |||||
Last Closed: | 2013-02-21 10:32: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
Steven Haigh
2012-10-25 06:18:54 UTC
As a side note, I have also tried matching the single address and using "RequiredAuthentications2 publickey", however I still get a rejection stating further auth was required (password). Config also tested: RequiredAuthentications2 publickey,password Match Address 1.2.3.4/32 X11Forwarding no AllowTcpForwarding no RequiredAuthentications2 publickey Added to #872608 filed against Fedora: While I'm not 100% sure of the syntax here, I've also tried the following config: Match Address 203.56.246.89 X11Forwarding no AllowTcpForwarding no RequiredAuthentications2 publickey Match Address * X11Forwarding no AllowTcpForwarding no RequiredAuthentications2 publickey,password This has no effect any anyone can log in via public key only. Created attachment 643648 [details]
fixed required authentications patch
I've done a bit more testing and I can say that this doesn't *always* work. For example: Host: 10.1.1.1 has the following in sshd_config: RequiredAuthentications2 publickey,password Match Address 203.56.246.89/32 RequiredAuthentications2 publickey When I SSH in from 203.56.246.89, I get: # ssh 10.1.1.1 Authenticated with partial success. root.1.1's password: This shouldn't happen. # ifconfig | grep addr eth0 Link encap:Ethernet HWaddr 00:16:36:35:35:09 inet addr:203.56.246.89 Bcast:203.56.246.95 Mask:255.255.255.240 # ssh -v 10.1.1.1 .... debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: /root/.ssh/identity debug1: Server accepts key: pkalg ssh-rsa blen 1045 debug1: read PEM private key done: type RSA Authenticated with partial success. debug1: Authentications that can continue: password debug1: Next authentication method: password root.1.1's password: On 10.1.1.1: # rpm -qa | grep openssh openssh-server-5.3p1-81.el6_3.x86_64 openssh-clients-5.3p1-81.el6_3.x86_64 openssh-5.3p1-81.el6_3.x86_64 Output from the SSH server side (10.1.1.1) with DEBUG1 set: Nov 22 11:06:00 xenhost sshd[5256]: Connection from 203.56.246.89 port 58966 Nov 22 11:06:00 xenhost sshd[5256]: debug1: Client protocol version 2.0; client software version OpenSSH_5.3 Nov 22 11:06:00 xenhost sshd[5256]: debug1: match: OpenSSH_5.3 pat OpenSSH* Nov 22 11:06:00 xenhost sshd[5256]: debug1: Enabling compatibility mode for protocol 2.0 Nov 22 11:06:00 xenhost sshd[5256]: debug1: Local version string SSH-2.0-OpenSSH_5.3 Nov 22 11:06:00 xenhost sshd[5257]: debug1: permanently_set_uid: 74/74 Nov 22 11:06:00 xenhost sshd[5257]: debug1: list_hostkey_types: ssh-rsa,ssh-dss Nov 22 11:06:00 xenhost sshd[5257]: debug1: SSH2_MSG_KEXINIT sent Nov 22 11:06:00 xenhost sshd[5257]: debug1: SSH2_MSG_KEXINIT received Nov 22 11:06:00 xenhost sshd[5257]: debug1: kex: client->server aes128-ctr hmac-md5 none Nov 22 11:06:00 xenhost sshd[5257]: debug1: kex: server->client aes128-ctr hmac-md5 none Nov 22 11:06:00 xenhost sshd[5257]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received Nov 22 11:06:00 xenhost sshd[5257]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent Nov 22 11:06:00 xenhost sshd[5257]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT Nov 22 11:06:00 xenhost sshd[5257]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent Nov 22 11:06:00 xenhost sshd[5257]: debug1: SSH2_MSG_NEWKEYS sent Nov 22 11:06:00 xenhost sshd[5257]: debug1: expecting SSH2_MSG_NEWKEYS Nov 22 11:06:00 xenhost sshd[5257]: debug1: SSH2_MSG_NEWKEYS received Nov 22 11:06:00 xenhost sshd[5257]: debug1: KEX done Nov 22 11:06:00 xenhost sshd[5257]: debug1: userauth-request for user root service ssh-connection method none Nov 22 11:06:00 xenhost sshd[5257]: debug1: attempt 0 failures 0 Nov 22 11:06:00 xenhost sshd[5256]: debug1: connection from 203.56.246.89 matched 'Address 203.56.246.89/32' at line 142 Nov 22 11:06:00 xenhost sshd[5256]: debug1: PAM: initializing for "root" Nov 22 11:06:00 xenhost sshd[5257]: debug1: userauth-request for user root service ssh-connection method publickey Nov 22 11:06:00 xenhost sshd[5257]: debug1: attempt 1 failures 0 Nov 22 11:06:00 xenhost sshd[5257]: debug1: test whether pkalg/pkblob are acceptable Nov 22 11:06:00 xenhost sshd[5256]: debug1: PAM: setting PAM_RHOST to "tsm.vm.crc.id.au" Nov 22 11:06:00 xenhost sshd[5256]: debug1: PAM: setting PAM_TTY to "ssh" Nov 22 11:06:00 xenhost sshd[5256]: debug1: temporarily_use_uid: 0/0 (e=0/0) Nov 22 11:06:00 xenhost sshd[5256]: debug1: trying public key file /root/.ssh/authorized_keys Nov 22 11:06:00 xenhost sshd[5256]: debug1: fd 4 clearing O_NONBLOCK Nov 22 11:06:00 xenhost sshd[5256]: debug1: matching key found: file /root/.ssh/authorized_keys, line 2 Nov 22 11:06:00 xenhost sshd[5256]: Found matching RSA key: ef:82:51:b0:dd:0d:b7:3d:ca:b1:67:23:d0:06:7b:7a Nov 22 11:06:00 xenhost sshd[5256]: debug1: restore_uid: 0/0 Nov 22 11:06:00 xenhost sshd[5257]: Postponed publickey for root from 203.56.246.89 port 58966 ssh2 Nov 22 11:06:00 xenhost sshd[5257]: debug1: userauth-request for user root service ssh-connection method publickey Nov 22 11:06:00 xenhost sshd[5257]: debug1: attempt 2 failures 0 Nov 22 11:06:00 xenhost sshd[5256]: debug1: temporarily_use_uid: 0/0 (e=0/0) Nov 22 11:06:00 xenhost sshd[5256]: debug1: trying public key file /root/.ssh/authorized_keys Nov 22 11:06:00 xenhost sshd[5256]: debug1: fd 4 clearing O_NONBLOCK Nov 22 11:06:00 xenhost sshd[5256]: debug1: matching key found: file /root/.ssh/authorized_keys, line 2 Nov 22 11:06:00 xenhost sshd[5256]: Found matching RSA key: ef:82:51:b0:dd:0d:b7:3d:ca:b1:67:23:d0:06:7b:7a Nov 22 11:06:00 xenhost sshd[5256]: debug1: restore_uid: 0/0 Nov 22 11:06:00 xenhost sshd[5256]: debug1: ssh_rsa_verify: signature correct Nov 22 11:06:00 xenhost sshd[5256]: debug1: do_pam_account: called Nov 22 11:06:00 xenhost sshd[5256]: Accepted publickey for root from 203.56.246.89 port 58966 ssh2 Nov 22 11:06:05 xenhost sshd[5257]: Connection closed by 203.56.246.89 Nov 22 11:06:05 xenhost sshd[5257]: debug1: do_cleanup Nov 22 11:06:05 xenhost sshd[5256]: debug1: do_cleanup Nov 22 11:06:05 xenhost sshd[5256]: debug1: PAM: cleanup So. It does see that the address matches. It also sets the userauth-request to publickey. It then accepts the key, but still wants password auth. (In reply to comment #10) > # rpm -qa | grep openssh > openssh-server-5.3p1-81.el6_3.x86_64 > openssh-clients-5.3p1-81.el6_3.x86_64 > openssh-5.3p1-81.el6_3.x86_64 You need at least openssh-5.3p1-83.el6, see "Fixed in version" (which is not available yet), or build your own rpm with fixed required authentications patch from comment #c6. (In reply to comment #10) > I've done a bit more testing and I can say that this doesn't *always* work. > For example: > > Host: 10.1.1.1 has the following in sshd_config: > RequiredAuthentications2 publickey,password > Match Address 203.56.246.89/32 > RequiredAuthentications2 publickey > > When I SSH in from 203.56.246.89, I get: > # ssh 10.1.1.1 > Authenticated with partial success. > root.1.1's password: > > This shouldn't happen. > > # ifconfig | grep addr > eth0 Link encap:Ethernet HWaddr 00:16:36:35:35:09 > inet addr:203.56.246.89 Bcast:203.56.246.95 Mask:255.255.255.240 > > # ssh -v 10.1.1.1 > .... > debug1: Authentications that can continue: publickey,password > debug1: Next authentication method: publickey > debug1: Offering public key: /root/.ssh/identity > debug1: Server accepts key: pkalg ssh-rsa blen 1045 > debug1: read PEM private key done: type RSA > Authenticated with partial success. > debug1: Authentications that can continue: password > debug1: Next authentication method: password > root.1.1's password: > > On 10.1.1.1: > # rpm -qa | grep openssh > openssh-server-5.3p1-81.el6_3.x86_64 > openssh-clients-5.3p1-81.el6_3.x86_64 > openssh-5.3p1-81.el6_3.x86_64 This case is also working on the new openssh version that will be released in RHEL-6.4. # rpm -qa | grep openssh openssh-server-5.3p1-84.el6.x86_64 openssh-5.3p1-84.el6.x86_64 openssh-clients-5.3p1-84.el6.x86_64 SERVER SIDE: # tail /etc/ssh/sshd_config # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # ForceCommand cvs server RequiredAuthentications2 publickey,password Match Address 127.0.0.1 RequiredAuthentications2 publickey Match Address 192.168.100.1/32 RequiredAuthentications2 publickey # CLIENT SIDE: $ ifconfig eth0 |grep addr eth0 Link encap:Ethernet HWaddr F0:DE:F1:95:82:E8 inet addr:10.34.25.37 Bcast:10.34.25.255 Mask:255.255.254.0 $ ssh root.100.63 Last login: Mon Nov 26 14:40:07 2012 from 192.168.100.1 # I'm wondering if there is any way we can fast track this for existing 6.3 installs? We are running into this bug as well where our global configuration specifies publickey and password authentication, yet we'd like to have some internal hosts only need to use public key. It would seem that no matter what we put in the match block they are still being forced to do both. It would be great if this could be fast tracked as mentioned as this has been sitting way too long in my opinion. 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. http://rhn.redhat.com/errata/RHSA-2013-0519.html |