RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 869903 - RequiredAuthentications2 does not work in Match blocks as documented.
Summary: RequiredAuthentications2 does not work in Match blocks as documented.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh
Version: 6.3
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Petr Lautrbach
QA Contact: Patrik Kis
URL: https://bugzilla.mindrot.org/show_bug...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-25 06:18 UTC by Steven Haigh
Modified: 2013-02-21 10:32 UTC (History)
6 users (show)

Fixed In Version: openssh-5.3p1-83.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 872608 (view as bug list)
Environment:
Last Closed: 2013-02-21 10:32:38 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
fixed required authentications patch (28.14 KB, patch)
2012-11-12 17:49 UTC, Petr Lautrbach 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0519 0 normal SHIPPED_LIVE Moderate: openssh security, bug fix and enhancement update 2013-02-20 21:28:57 UTC

Description Steven Haigh 2012-10-25 06:18:54 UTC 
Description of problem:
I have set up some critical machines to use publickey + password authentication. I have done this by adding the following to /etc/ssh/sshd_config:
        RequiredAuthentications2 publickey,password

I have certain hosts that run automated tasks that require JUST publickey auth. As such, these scripts are currently broken.

I have set up a Match block as follows:
Match Address !1.2.3.4/32,*
        X11Forwarding no
        AllowTcpForwarding no
        RequiredAuthentications2 publickey,password

This should allow publickey auth (as the default) to the specific hosts excluded, and require publickey + password for all other hosts.

When trying to run a script that uses a public key, I get the following returned:
Authenticated with partial success.
Permission denied (password).

The documentation in 'man sshd_config' shows:
             Only a subset of keywords may be used on the lines following a Match keyword.  Available keywords
             are AllowAgentForwarding, AllowTcpForwarding, Banner, ChrootDirectory, ForceCommand, GatewayPorts,
             GSSAPIAuthentication, HostbasedAuthentication, KbdInteractiveAuthentication,
             KerberosAuthentication, KerberosUseKuserok, MaxAuthTries, MaxSessions, PubkeyAuthentication,
             AuthorizedKeysCommand, AuthorizedKeysCommandRunAs, PasswordAuthentication, PermitEmptyPasswords,
             PermitOpen, PermitRootLogin, RequiredAuthentications1, RequiredAuthentications2,
             RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset, X11Forwarding and X11UseLocalHost.

This configuration should therefore work.

Version-Release number of selected component (if applicable):
# rpm -qa | grep openssh
openssh-5.3p1-81.el6.x86_64
openssh-clients-5.3p1-81.el6.x86_64
openssh-server-5.3p1-81.el6.x86_64
Comment 1 Steven Haigh 2012-10-25 06:21:05 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
Comment 3 Steven Haigh 2012-11-05 04:52:47 UTC 
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.
Comment 6 Petr Lautrbach 2012-11-12 17:49:28 UTC 
Created attachment 643648 [details]
fixed required authentications patch
Comment 10 Steven Haigh 2012-11-21 13:53:44 UTC 
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
Comment 11 Steven Haigh 2012-11-22 00:08:44 UTC 
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.
Comment 12 Petr Lautrbach 2012-11-26 13:38:02 UTC 
(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.
Comment 13 Patrik Kis 2012-11-26 13:48:31 UTC 
(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
#
Comment 14 Steven Haigh 2012-12-07 03:51:45 UTC 
I'm wondering if there is any way we can fast track this for existing 6.3 installs?
Comment 15 Kurt Bechstein 2013-02-16 04:33:27 UTC 
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.
Comment 16 errata-xmlrpc 2013-02-21 10:32:38 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.