Rundeck非root用户执行任务报错：PAM: Authentication failed求助

Let’s walk through the most likely issues and fixes step by step—since your public key auth works on other servers, the problem is almost certainly a configuration quirk on the target node or a permission mismatch.

1. Fix Strict SSH Directory/File Permissions #

SSH and PAM enforce strict permissions to prevent security vulnerabilities. Even a minor permission misconfiguration can block public key authentication:

• Set your non-root user’s home directory to 700 (only the owner has access):

  chmod 700 /home/non-rootuser
  

• Set the .ssh directory to 700:

  chmod 700 /home/non-rootuser/.ssh
  

• Set the authorized_keys file to 600:

  chmod 600 /home/non-rootuser/.ssh/authorized_keys
  

• Ensure all files/directories are owned by non-rootuser (not root or another user):

  chown -R non-rootuser:non-rootuser /home/non-rootuser/.ssh
  

2. Validate SSHD and PAM Configurations on the Target Node #

SSHD Settings #

Open /etc/ssh/sshd_config and confirm these critical lines are set correctly (uncomment if they’re commented out):

PubkeyAuthentication yes
# These can stay enabled but shouldn’t interfere if keys are valid
PasswordAuthentication yes
ChallengeResponseAuthentication yes

Restart SSHD after making changes:

systemctl restart sshd

PAM Configuration #

Check /etc/pam.d/sshd for rules that might block authentication:

• Look for pam_access.so references—this module restricts access by source IP. Verify /etc/security/access.conf allows your Rundeck host to connect as non-rootuser:
  Add this line if missing:

  +:non-rootuser:rundeck_host
  

• Ensure no PAM modules are forcing password checks even for public key auth (e.g., pam_unix.so with required flags that demand a valid password).

3. Check SELinux/AppArmor Contexts (If Enabled) #

If your target node uses SELinux, incorrect file contexts can prevent SSH from reading authorized_keys:

• Temporarily disable SELinux to test:

  setenforce 0
  

• If authentication works after this, restore the correct SELinux context permanently:

  restorecon -Rv /home/non-rootuser/.ssh
  

• For AppArmor, verify the SSH profile isn’t restricting access to the .ssh directory and adjust it if needed.

4. Verify the Non-Root User Account Status #

PAM will reject authentication if the user account is locked or has an expired password:

• Check the user’s status:

  passwd -S non-rootuser
  

• If the output shows L (locked), unlock the account:

  passwd -u non-rootuser
  

• If the password is expired, disable expiration or set a new password:

  chage -E -1 non-rootuser  # Disable password expiration
  # OR
  passwd non-rootuser
  

5. Isolate Rundeck vs. Target Node Issues with a Manual SSH Test #

From your Rundeck host, run a manual SSH command to confirm the key pair works outside of Rundeck:

ssh -i /path/to/rundeck/private/key non-rootuser@targetnode

• If this fails, the issue is with the target node or key setup (not Rundeck).
• If this works, double-check your Rundeck node configuration:
  • Ensure the username matches non-rootuser exactly
  • Confirm the private key path in Rundeck is correct and accessible by the Rundeck service user
  • Verify no extra SSH options in Rundeck are forcing password auth

6. Dig Into Detailed Logs for Exact PAM Failure Cause #

Check the target node’s auth logs to see which PAM module is failing:

• On most systems, logs are in /var/log/secure or /var/log/auth.log:

  grep -i "pam" /var/log/secure | grep non-rootuser
  

This will show you the specific module (e.g., pam_unix.so, pam_access.so) causing the error, making it easier to fix.

内容的提问来源于stack exchange，提问作者Charlie