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 990539 - iLO2: Unable to login when password contains "
Summary: iLO2: Unable to login when password contains "
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: fence-agents
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Marek Grac
QA Contact: Cluster QE
URL:
Whiteboard:
: 875055 1067855 1068940 (view as bug list)
Depends On: 990537
Blocks: 782468 1067873
TreeView+ depends on / blocked
 
Reported: 2013-07-31 12:18 UTC by Marek Grac
Modified: 2015-03-26 03:25 UTC (History)
12 users (show)

Fixed In Version: fence-agents-4.0.2-16.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 990537
Environment:
Last Closed: 2014-06-13 09:38:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Marek Grac 2013-07-31 12:18:57 UTC
+++ This bug was initially created as a clone of Bug #990537 +++

It is not possible to login to HP iLO2 when password contains characters that need to be escaped when used in XML attribute.

Unit test:
(before)

fence_ilo -o reboot -a test-ilo -z -l marx -p 'marx"marx'
Unable to connect/login to fencing device

(after)
fence_ilo -o reboot -a test-ilo -z -l marx -p 'marx"marx'

--- Additional comment from Marek Grac on 2013-07-31 08:17:36 EDT ---

Fixed in upstream:

https://git.fedorahosted.org/cgit/fence-agents.git/commit/?id=3a185569e825ee8e948a6cbef8bf847f6a7632dc

Comment 12 Marek Grac 2014-01-22 09:45:16 UTC
*) Non-encryption is not a solution because there is (or was) telnet based interface for ilo2 but it did not work correctly. If I remeber it, problem was that we had to issue power off but ilo always sent it as attempt to graceful shutdown.

@John Harrigan:

*) There is no problem with ilo3/ilo4/... because they support IPMI and that is the only supported way from us.

Comment 14 Marek Grac 2014-02-13 17:05:18 UTC
We can switch to gnutls-cli and remove nss_wrapper completely. With current version, there is no problem with communication with iLO2 (tested with RIBCL 1.22);

The required patch just change the executable and we will lose support for ilo2 & force ipv6 - what is not a problem as hw does not support it anyway.




diff --git a/fence/agents/lib/fencing.py.py b/fence/agents/lib/fencing.py.py
index fd21c69..d87618c 100644
--- a/fence/agents/lib/fencing.py.py
+++ b/fence/agents/lib/fencing.py.py
@@ -28,7 +28,7 @@ EC_INVALID_PRIVILEGES = 11
 
 TELNET_PATH = "/usr/bin/telnet"
 SSH_PATH    = "/usr/bin/ssh"
-SSL_PATH    = "@LIBEXECDIR@/fence_nss_wrapper"
+SSL_PATH    = "/usr/bin/gnutls-cli"
 SUDO_PATH   = "/usr/bin/sudo"
 
 all_opt = {
@@ -960,7 +960,7 @@ def fence_login(options, re_login_string = "(login\s*: )|(Login Name:  )|(userna
                re_pass  = re.compile("(password)|(pass phrase)", re.IGNORECASE)
 
                if options.has_key("--ssl"):
-                       command = '%s %s %s %s' % (SSL_PATH, force_ipvx, options["--ip"], options["--ipport"])
+                       command = '%s --insecure --crlf -p %s %s' % (SSL_PATH, options["--ipport"], options["--ip"])
                        try:
                                conn = fspawn(options, command)
                        except pexpect.ExceptionPexpect, ex:

Comment 15 Fabio Massimo Di Nitto 2014-02-13 18:18:11 UTC
(In reply to Marek Grac from comment #14)
> We can switch to gnutls-cli and remove nss_wrapper completely. With current
> version, there is no problem with communication with iLO2 (tested with RIBCL
> 1.22);
> 
> The required patch just change the executable and we will lose support for
> ilo2 & force ipv6 - what is not a problem as hw does not support it anyway.
> 
> 
> 
> 
> diff --git a/fence/agents/lib/fencing.py.py b/fence/agents/lib/fencing.py.py
> index fd21c69..d87618c 100644
> --- a/fence/agents/lib/fencing.py.py
> +++ b/fence/agents/lib/fencing.py.py
> @@ -28,7 +28,7 @@ EC_INVALID_PRIVILEGES = 11
>  
>  TELNET_PATH = "/usr/bin/telnet"
>  SSH_PATH    = "/usr/bin/ssh"
> -SSL_PATH    = "@LIBEXECDIR@/fence_nss_wrapper"
> +SSL_PATH    = "/usr/bin/gnutls-cli"


Makes sense to me. Can we consider dropping fence_nss_wrapper completely in favour of gnutls-cli?

Comment 16 Marek Grac 2014-02-14 12:26:55 UTC
@Fabio:

yes, we can completely drop fence_nss_wrapper then

btw: of course in final version the path won't be hard-coded :)

Comment 17 Marek Grac 2014-02-17 13:29:39 UTC
Problem is fixed in upstream:

https://git.fedorahosted.org/cgit/fence-agents.git/commit/?id=52ed50a1bd4b4bfe632bd560de27195fcea65802

nss-wrapper was completely removed in favor of gnutls-cli

Unit test:

fence_ilo -o status ...
fence_ilo -o reboot ...

Comment 23 Fabio Massimo Di Nitto 2014-02-19 18:36:14 UTC
*** Bug 875055 has been marked as a duplicate of this bug. ***

Comment 24 Fabio Massimo Di Nitto 2014-02-20 11:58:14 UTC
Unit test result related to incorrect build:

[root@rhel7-node1 ~]# grep SSL_PATH /usr/share/fence/fencing.py |head -n1
SSL_PATH    = "/usr/bin/gnutls-cli"

Unit test result related to the broken Requires:

[root@rhel7-node1 download]# rpm -U fence-agents-all-4.0.2-16.el7.x86_64.rpm fence-agents-ilo2-4.0.2-16.el7.x86_64.rpm
error: Failed dependencies:
        gnutls-utils is needed by fence-agents-ilo2-4.0.2-16.el7.x86_64
[root@rhel7-node1 download]# yum install gnutls-utils
[root@rhel7-node1 download]# rpm -U fence-agents-all-4.0.2-16.el7.x86_64.rpm fence-agents-ilo2-4.0.2-16.el7.x86_64.rpm
[root@rhel7-node1 download]#

Unit test results related to the gnutls connection to the device. Please note that a new option is required.

The problem:
gnutls > 3.x sets default negotiation protocol to TLS1.x
the device used for testing, while it claims TLS support, only works with SSL3.0

This can be verified either using RHEL6 gnutls-2.x or downgrading RHEL7 gnutls to 2.12.21-2.el7.x86_64.rpm (it will require some mocking around for libtasm.1.so.3 missing)

Default connection using gnutls-2.x on RHEL7:

[root@rhel7-node1 ~]# gnutls-cli --insecure hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com
Resolving 'hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com'...
Connecting to '10.16.64.205:443'...
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1024 bits
 - Secret key: 1022 bits
 - Peer's public key: 1023 bits
- Certificate type: X.509
 - Got a certificate list of 1 certificates.
 - Certificate[0] info:
  - subject `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', issuer `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `2002-12-05 20:25:26 UTC', expires `2022-12-05 20:25:26 UTC', SHA-1 fingerprint `73bb4663808c363c08ea088a9e04845b40655d6d'
- The hostname in the certificate does NOT match 'hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com'
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: SSL3.0
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

Default connection using gnutls-3.x on RHEL7:

[root@rhel7-node1 ~]# gnutls-cli --insecure hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com
Processed 149 CA certificate(s).
Resolving 'hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com'...
Connecting to '10.16.64.205:443'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', issuer `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `2002-12-05 20:25:26 UTC', expires `2022-12-05 20:25:26 UTC', SHA-1 fingerprint `73bb4663808c363c08ea088a9e04845b40655d6d'
        Public Key Id:
                7ee167b84da6cf478dc2a2860a83bc647652bdd5
        Public key's random art:
                +--[ RSA 1024]----+
                |                 |
                |                 |
                |                 |
                |    .   .        |
                |   . . .SE..   o |
                |...   o. ..oo o .|
                |.*o. . ...+.=o   |
                |+ +o  . o. X  .  |
                | .  .. .  o.+.   |
                +-----------------+

- Status: The certificate is NOT trusted. The certificate issuer is unknown. The name in the certificate does not match the expected.
*** Verifying server certificate failed...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [20]: Bad record MAC
*** Handshake has failed
GnuTLS error: A TLS fatal alert has been received.

Forcing SSL3.0 connection on gnutls-3.x on RHEL7:

[root@rhel7-node1 ~]# gnutls-cli --priority "NORMAL:-VERS-TLS1.2:-VERS-TLS1.1:-VERS-TLS1.0:+VERS-SSL3.0" --insecure hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com

Processed 149 CA certificate(s).
Resolving 'hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com'...
Connecting to '10.16.64.205:443'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', issuer `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `2002-12-05 20:25:26 UTC', expires `2022-12-05 20:25:26 UTC', SHA-1 fingerprint `73bb4663808c363c08ea088a9e04845b40655d6d'
        Public Key Id:
                7ee167b84da6cf478dc2a2860a83bc647652bdd5
        Public key's random art:
                +--[ RSA 1024]----+
                |                 |
                |                 |
                |                 |
                |    .   .        |
                |   . . .SE..   o |
                |...   o. ..oo o .|
                |.*o. . ...+.=o   |
                |+ +o  . o. X  .  |
                | .  .. .  o.+.   |
                +-----------------+

- Status: The certificate is NOT trusted. The certificate issuer is unknown. The name in the certificate does not match the expected.
*** Verifying server certificate failed...
- Description: (SSL3.0-PKIX)-(RSA)-(AES-128-CBC)-(SHA1)
- Session ID: D1:23:75:82:B0:93:E4:5B:A5:18:8E:90:CA:4E:D3:1A:34:69:5A:17:97:8C:72:E6:8A:86:0C:BB:8B:E1:E4:13
- Version: SSL3.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

======================

Since TLS should always be preferred by default, we add a new config option
specific to those agents that support --ssl (cisco_ucs, ilo, ilo2, rhevm, vmware_soap) "--notls" or "-t".

Pre-patch:
[root@rhel7-node1 ~]# fence_ilo -a hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com -l tester -p testtest -o status
Unable to connect/login to fencing device

Post patch:
[root@rhel7-node1 ~]# fence_ilo -a hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com -l tester -p testtest -o status -t
Status: ON

Since the device does not belong to us, I am currently unable to verify actions other than status or if the original problem with password containing " will work.

Comment 27 Martin Banas 2014-02-21 08:37:21 UTC
*** Bug 1067855 has been marked as a duplicate of this bug. ***

Comment 28 Fabio Massimo Di Nitto 2014-02-24 09:00:56 UTC
*** Bug 1068940 has been marked as a duplicate of this bug. ***

Comment 31 Ludek Smid 2014-06-13 09:38:47 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


Note You need to log in before you can comment on or make changes to this bug.