SUSE Linux Enterprise Server에서 PAM 인증 실패를 해결하는 방법

"PAM 인증 실패" 메시지가 항상 암호가 틀렸다는 것을 의미하는 것은 아닙니다. SUSE Linux Enterprise Server(SLES)에서 플러그형 인증 모듈(PAM)은 신원 확인, 계정 접근, 암호 변경 및 세션 설정을 검사하는 스택을 구성합니다. 인증 실패는 오타, 비활성화된 계정, 손상된 PAM 포함 파일, 사용 불가능한 LDAP 또는 Active Directory 서비스, Kerberos 시간 또는 DNS 문제, 또는 인증 후 발생하는 데스크톱 세션 문제 등 다양한 원인으로 발생할 수 있습니다.

가장 안전한 해결 방법은 구성을 변경하기 전에 어떤 서비스와 어떤 PAM 단계에서 오류가 발생했는지 확인하는 것입니다. 이 가이드에서는 SUSE Linux Enterprise Server 15 SP7 설명서를 참조합니다. 다른 SLES 서비스 팩이나 특수 어플라이언스 이미지를 사용하는 경우, 명령을 적용하기 전에 해당 SUSE 설명서와 설치된 패키지 버전을 확인하십시오.

우선, 어떤 서비스에 문제가 있는 건지, 아니면 모든 로그인 과정에서 문제가 발생하는 건지 파악해야 합니다.

실패 발생 시 사용자, 정확한 시간, 호스트 및 진입점(SSH, 로컬 텍스트 콘솔, 그래픽 로그인 su또는 애플리케이션)을 기록하십시오. 가능하면 알려진 다른 계정으로 테스트하십시오. 콘솔 로그인은 성공하지만 SSH 로그인만 실패하는 경우 /etc/pam.d/sshdSSH 서비스에 집중하십시오. 로컬 사용자는 로그인되지만 디렉터리 사용자 로그인이 실패하는 경우 SSSD, LDAP, Active Directory, Kerberos, DNS 또는 호스트의 권한 부여 정책을 조사하십시오. 콘솔 로그인은 성공했지만 데스크톱에서 사용자 로그인이 거부되거나 로그인 화면으로 돌아가는 경우 암호 인증보다는 그래픽 세션이나 홈 디렉터리에 문제가 있을 수 있습니다.

문제 해결 중에는 기존 루트 셸을 열어 두십시오. 원격으로 연결된 경우 두 번째 SSH 세션을 열어 두고 PAM 파일을 수정하기 전에 콘솔 또는 복구 액세스 권한이 있는지 확인하십시오. 공유 PAM 파일의 구문 또는 제어 플래그 오류로 인해 여러 서비스의 새 로그인이 차단될 수 있습니다.

1. 실패 시도와 관련된 일지를 읽어보세요.

SUSE의 문제 해결 가이드에서는 로그인 프로세스 및 PAM에서 발생한 메시지를 확인하기 위해 시스템 저널을 검토할 것을 권장합니다. 관련 없는 메시지가 원인을 가리지 않도록 오류 발생 직후의 짧은 시간 동안의 메시지를 조회하십시오.

sudo journalctl -b --since "15 minutes ago"

SSH 관련 문제만 해결하려면 보기 범위를 SSH 데몬으로 좁히세요.

sudo journalctl -b -u sshd --since "15 minutes ago"

서비스 이름, PAM 서비스 이름, 모듈 이름, 그리고 메시지가 auth, account, password또는 를 참조하는지 여부를 확인하십시오 session. PAM auth스택은 자격 증명을 확인하고, account사용자가 해당 서비스에 액세스할 수 있는지 확인하고, session사용자 환경을 준비합니다. 암호 확인에 성공한 후 계정 거부가 발생하는 경우, 알 수 없는 사용자 또는 잘못된 암호와는 다른 문제일 가능성이 높습니다. 필요한 경우가 아니면 운영 시스템에서 자세한 디버깅을 활성화하지 마십시오. 진단 로그에는 계정 이름 및 기타 민감한 컨텍스트가 포함될 수 있습니다.

SUSE의 SLES 문제 해결 가이드 에서 로컬 및 네트워크 인증 워크플로를 참조하십시오.

2. SLES가 사용자를 찾을 수 있는지 확인합니다.

PAM을 변경하기 전에 시스템의 이름 서비스 스위치가 해당 계정을 확인할 수 있는지 확인하십시오.

getent passwd user_name
id user_name

해당 로그인으로 교체하십시오 user_name. 이러한 명령이 디렉터리 사용자에 대한 계정을 반환하지 않으면 PAM은 정상적으로 작동하지만 ID 조회가 실패하는 것일 수 있습니다. 구성된 ID 서비스가 실행 중인지, 호스트가 디렉터리에 연결할 수 있는지, 그리고 사용자가 이 호스트에 로그인할 수 있는 권한이 있는지 확인하십시오. SSSD 기반 설정의 경우 데몬 및 최근 로그를 검사하십시오.

sudo systemctl status sssd
sudo journalctl -b -u sssd --since "15 minutes ago"

SUSE 문서에 따르면 SSSD는 NSS 및 PAM 인터페이스를 모두 제공하며 ID 데이터를 캐시할 수 있습니다. 사용자가 간헐적인 오류를 보고하는 경우 로컬 시스템의 시간과 DNS 확인을 디렉터리 또는 Kerberos 환경과 비교하십시오. Kerberos는 정확한 시간 동기화에 의존하므로 네트워크 연결만으로는 인증이 성공한다는 것을 보장할 수 없습니다.

이름 충돌 여부도 확인하십시오. SUSE는 로컬과 네트워크 ID 소스에 모두 존재하는 사용자 이름이 네트워크 인증 문제의 원인이 될 수 있다고 명시하고 있습니다. PAM 규칙을 편집하기 전에 어떤 ID 소스가 해당 계정을 소유해야 하는지 확인하십시오.

3. PAM 서비스 파일과 공유 스택을 검사합니다.

SLES는 서비스별 PAM 파일을 에 보관합니다 /etc/pam.d. 와 같은 서비스 파일에는 일반적으로 , , , 와 /etc/pam.d/sshd같은 공유 파일이 포함됩니다 . 공유 파일의 잘못된 줄은 여러 서비스에 영향을 미칠 수 있으며, 특정 애플리케이션의 파일에 있는 잘못된 줄은 해당 애플리케이션에만 영향을 미칠 수 있습니다.common-authcommon-accountcommon-passwordcommon-session

편집하기 전에 관련 파일을 읽고 링크를 확인하세요.

sudo ls -l /etc/pam.d/common-*
sudo sed -n '1,160p' /etc/pam.d/sshd
sudo sed -n '1,160p' /etc/pam.d/common-auth
sudo sed -n '1,160p' /etc/pam.d/common-account

모듈 이름의 오타, 누락된 모듈 파일, 잘못된 옵션, 예상치 못한 순서, 최근 패키지 또는 인증 배포 중에 발생한 변경 사항 등을 확인하십시오. 제어 플래그는 중요합니다. required실패를 기록하지만 스택을 계속 진행하는 플래그, requisite즉시 중지하는 플래그, sufficient또는 이전 필수 모듈에서 실패가 발생하지 않은 경우 조기에 성공 반환을 허용하는 플래그가 있습니다. 모듈 및 제어 흐름을 이해하지 않고 다른 배포판이나 SLES 릴리스의 PAM 스택을 복사하지 마십시오.

변경하기 전에 심볼릭 링크를 유지하면서 현재 디렉터리의 루트 사용자만 사용할 수 있는 백업을 만드십시오.

backup_dir=/root/pam.d.backup.$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/pam.d "$backup_dir"

백업 파일이 있는지 확인하고 변경한 파일을 정확히 기록하십시오. 모든 사용자가 로그인할 수 없는 경우, 로그인 프롬프트에서 임의로 설정을 변경하지 말고 지원되는 SLES 복구 절차를 사용하여 정상 작동하는 구성에서 복원하십시오.

4. SLES에서 pam-config가 공유 파일을 관리하는지 확인하십시오.

SUSE는 pam-config전역 PAM 파일과 지원되는 애플리케이션 구성을 유지 관리할 수 있도록 지원합니다. 지원되는 메서드를 추가하거나 제거할 때 생성된 공유 스택을 수동으로 편집하는 것보다 일반적으로 더 안전합니다. 먼저 사용 가능한 모듈과 현재 SSSD 통합을 확인하십시오.

sudo pam-config --list-modules
sudo pam-config --query --sss

서버에서 SSSD를 의도적으로 사용하고 있는데 통합이 누락된 경우, SUSE 문서에 sudo pam-config --add --sss통합 추가 방법이 나와 있습니다. 이 작업은 디렉터리 인증 설계를 확인하고, 현재 스택을 검토하고, 백업을 유지하고, 복구 경로를 확보한 후에만 수행하십시오. 모든 "인증 실패" 문제에 대한 일반적인 해결책으로 이 방법을 사용하지 마십시오. 구성을 다시 확인하고 두 번째 세션에서 테스트하십시오.

특히 위험한 명령어는 `.`입니다 pam-config --create. SUSE에 따르면 이 명령어는 간단한 Unix 인증 구성을 생성하고 pam-config(`.`에서 관리하지 않는 .pam-config-backup) 기존 구성 파일을 덮어씁니다. 단, 백업 복사본은 접미사를 붙여 보관합니다. 이는 단일 로그인 실패에 대한 일상적인 복구 명령어가 아닙니다. 구성을 의도적으로 재구축하고 복구 계획을 세운 경우에만 사용하십시오.

조직에서 PAM 파일을 의도적으로 수동으로 관리하는 경우, 해당 방식을 일관되게 유지하십시오. SUSE는 수동 구성 시 pam-config해당 파일을 비활성화해야 한다고 명시하고 있습니다. 사용자 지정 스택은 필요한 세션 모듈을 유지해야 하며, pam_systemd.so적용 가능한 경우 선택적 세션 모듈로도 제공해야 합니다.

5. SSH, 디렉터리 및 데스크톱 문제를 분리합니다.

SSH에서만 계정이 거부되는 경우

/etc/pam.d/sshd정상적으로 작동하는 SLES 구성과 비교 하고 로그인 실패 시점의 SSH 데몬 저널을 검사하십시오. 해당 계정이 SSH 자체 설정 및 액세스 제어는 물론 PAM에서도 허용되어 있는지 확인하십시오. 오류를 없애기 위해 SSH 인증을 약화시키거나 계정 검사를 제거하지 마십시오.

디렉터리 사용자만 오류가 발생하는 경우

계정 조회를 확인하고 getent, SSSD 상태 및 로그를 점검하고, 디렉터리 연결 가능성, DNS, 시간 동기화, 호스트 등록 및 사용자 액세스 정책을 확인하십시오. 다른 디렉터리 사용자가 성공적으로 인증되면 해당 계정의 그룹, 셸, 홈 디렉터리 및 호스트별 액세스 규칙을 비교하십시오. SUSE 인증 클라이언트 가이드 에서 YaST로 관리되는 SSSD 및 상태 확인 방법에 대한 설명을 확인할 수 있습니다.

콘솔 로그인은 되지만 그래픽 세션 로그인이 실패하는 경우

그래픽 로그인 및 세션 로그, 홈 디렉터리 가용성, 소유권, 여유 디스크 공간, 암호화된 홈 디렉터리 잠금 해제 단계를 확인하십시오. 텍스트 콘솔 로그인 성공 여부는 암호 및 기본 인증 경로가 제대로 작동한다는 유용한 증거이며, 데스크톱 세션 또는 사용자 환경 문제로 관심을 돌릴 수 있게 해줍니다. 첫 단계로 사용자 파일을 삭제하는 것은 피하십시오. SUSE의 문제 해결 가이드에서는 데스크톱 구성 문제를 체계적으로 분리하는 것을 권장합니다.

6. 잠금 위험 없이 수리를 확인하십시오.

변경 후 복구 셸을 계속 사용할 수 있는 상태에서 새 테스트 세션을 엽니다. 영향을 받는 계정으로 해당 서비스를 테스트한 다음, 다른 계정과 로컬 관리자 계정으로 테스트합니다. 디렉터리 인증의 경우 계정 조회 및 서비스 상태, 그리고 성공적인 로그인을 확인합니다. 저널에서 새로운 PAM 오류가 있는지 다시 확인하고, pam-config --delete테스트가 완료되면 해당 옵션을 사용하여 임시 디버그 설정을 모두 제거합니다.

마지막으로, 결과가 실패 단계를 숨기는 것이 아니라 해결하는지 확인하십시오. 수정된 로그인은 의도한 사용자를 인증하고, 의도한 계정 정책을 적용하며, 정상적인 세션을 생성해야 합니다. 이러한 결과를 확인하고 최종 구성을 문서화할 때까지 백업을 보관하십시오.

언제 멈추고 복구 모드를 사용해야 할까요?

루트 액세스 권한을 잃었거나, 여러 서비스가 동시에 실패하거나, 공유 스택이 덮어쓰여졌거나, 어떤 구성 관리자가 파일의 소유권을 가지고 있는지 확인할 수 없는 경우 원격 변경을 중지하십시오. SLES 설명서에는 루트 액세스를 사용하여 구성을 복구하고 일반 로그인이 불가능할 때 복구 모드로 진입하는 방법이 설명되어 있습니다. 관리형 프로덕션 시스템의 경우 공유 인증 스택을 재구축하기 전에 ID 관리팀 또는 플랫폼팀과 협의하십시오.

정확한 PAM 파일 구조, 모듈 플래그, pam-config동작 및 복구 단계에 대해서는 버전별 SUSE SLES 15 SP7 PAM 가이드 및 SUSE 일반 문제 해결 가이드를 참조하십시오 . PAM 스택은 보안 정책이므로, 최소한의 정당한 변경만 하고 접근 권한과 제한 사항을 모두 확인하십시오.