The situation described presents multiple red flags in information security:

• Requesting plain-text passwords violates PCI DSS Requirement 8.4
• Historical password changes cannot be retrieved from standard Linux authentication systems
• SSH private keys should never be shared for auditing purposes

On Red Hat/CentOS systems with LDAP authentication, passwords are stored using one-way hashing algorithms. Here's what actually happens when a user changes their password:

# Example of password hash generation
$ openssl passwd -1 "example_password"
$1$9E4HpW3q$TrV5h/xvLvUZQ5zBQST5R.

Modern systems use even stronger algorithms like SHA-512:

# /etc/shadow entry example
user:$6$rounds=5000$saltvalue$hashedpassword:18283:0:99999:7:::

The Payment Card Industry Data Security Standard specifically prohibits the practices being requested:

• Requirement 2: Do not use vendor-supplied defaults for system passwords
• Requirement 8: Identify and authenticate access to system components
• Requirement 8.2: Use strong cryptography for all authentication credentials

Instead of the dangerous information requested, offer these technically valid alternatives:

# Get list of system users (without passwords)
$ getent passwd

# Show password aging information
$ chage -l username

# List SSH public keys
$ cat /etc/ssh/ssh_host_*.pub
$ cat ~/.ssh/authorized_keys

For tracking file transfers, you could implement proper logging going forward:

# Basic auditd rule for tracking file creations
-w /path/to/monitor -p wa -k file_uploads

# To check existing logs (limited to what's already configured)
$ ausearch -k file_uploads

When dealing with uninformed auditors, provide authoritative references:

• PCI DSS v3.2.1, Requirement 8.4
• NIST Special Publication 800-63B (Digital Identity Guidelines)
• Red Hat Security Hardening documentation

Document your system's security configuration properly:

# Show password hashing algorithm in use
$ authconfig --test | grep hashing

# Verify PAM configuration
$ cat /etc/pam.d/system-auth

# Check LDAP security settings
$ getent -s ldap passwd

As the original poster discovered, sometimes the best solution is to move to a compliant provider. Key steps:

1. Implement proper logging for future audits
2. Document all security controls in place
3. Engage PCI SSC when encountering non-compliant requests
4. Consider third-party compliance validation

Never comply with requests that violate security fundamentals. Instead:

1. Document the impossibility of the request
2. Provide alternative evidence of security controls
3. Escalate to compliance authorities when needed
4. Maintain your security integrity above all

---

Recently, I encountered a security auditor demanding:

• Plaintext passwords for all user accounts
• Six months of password change history in plaintext
• SSH private/public key pairs
• Real-time plaintext password email notifications

This violates multiple security principles:

# Example of proper password storage in /etc/shadow
username:$6$rounds=656000$saltvalue$hashedpassword:18283:0:99999:7:::

Modern systems never store passwords in recoverable formats. Here's why:

• PCI DSS Requirement 8.4 explicitly prohibits it
• GDPR/Data Protection Act violations
• Creates massive security liability

On Linux systems with LDAP authentication:

# To check password hashing method:
grep ^ENCRYPT_METHOD /etc/login.defs

# To verify LDAP config (RHEL/CentOS):
cat /etc/openldap/ldap.conf

Historical password changes are impossible to retrieve unless you've implemented custom logging (which would itself be a security risk).

While you can collect SSH keys, it's bad practice:

# Public keys are safe to share:
cat ~/.ssh/id_rsa.pub

# Private keys should NEVER be shared:
-----BEGIN OPENSSH PRIVATE KEY-----
(THIS SHOULD NEVER LEAVE YOUR SYSTEM)
-----END OPENSSH PRIVATE KEY-----

Key points to include in your response:

1. Cite PCI DSS 8.4 verbatim
2. Reference NIST SP 800-63B guidelines
3. Offer alternative evidence:
   - Password policy documents
   - SSH key fingerprints
   - File transfer logs (without content)

Document everything and escalate:

• CC legal/compliance teams
• Contact PCI Security Standards Council
• Begin migration plans (as we did to PayPal)

No legitimate security professional would demand these things. The auditor's claim that "PCI is software" reveals fundamental ignorance. Always prioritize actual security over checkbox compliance.