SLES PAM 로그인 실패 원인을 계정 잠금 없이 진단하세요

"PAM 인증 실패" 메시지는 만능 해결책이 아닙니다. 먼저 오류가 발생하는 서비스와 사용자를 확인한 다음, 해당 시점의 로그를 확인하십시오. SUSE Linux Enterprise Server(SLES)에서는 확인된 전역 PAM 문제를 를 통해 복구하고 pam-config, 개별 서비스 파일은 해당 서비스의 스택에 문제가 있는 경우에만 수정하십시오. 테스트하는 동안 루트 또는 관리자 세션을 열어 두십시오. PAM 스택이 손상된 경우 새로운 SSH 및 콘솔 로그인이 차단될 수 있습니다.

현재 SLES 15 SP7 보안 및 강화 가이드에서는 PAM을 인증, 계정, 암호 및 세션 모듈의 스택으로 설명합니다. 이러한 구분은 중요합니다. 올바른 암호를 사용하더라도 초기 auth단계를 통과하면 계정 정책이나 서비스별 규칙에 의해 나중에 거부될 수 있기 때문입니다. 일반적인 오류 메시지만으로는 어떤 단계에서 오류가 발생했는지 정확히 파악할 수 없습니다.

이 오류는 무엇을 증명하고, 무엇을 증명하지 못하는가?

sshdPAM은 콘솔 로그인과 같은 애플리케이션과 구성된 인증 방법 간의 연결을 중재합니다 . 각 PAM 지원 서비스는 `/service.php` 경로에 파일을 가지고 있습니다. 서비스 파일에는 `/service.php` 및 `/service.php` 와 /etc/pam.d/같은 SLES 공통 파일이 포함될 수 있으므로 SSH에만 국한된 오류는 모든 로그인 방법에서 발생하는 오류와는 다른 원인일 수 있습니다.common-authcommon-account

확인됨: SUSE의 문서화된 SSH 스택에는 pam_nologin.so일반적인 PAM 파일이 포함되어 있습니다. /etc/nologin해당 모듈이 존재하는 경우, 루트 이외의 사용자에 대한 로그인을 거부합니다. 상황에 따라 달라질 수 있습니다. 로컬에서 편집된 규칙, 디렉터리 서비스 및 타사 MFA 모듈에서 추가 검사를 수행할 수 있습니다. 메시지만으로는 암호 오류, PAM 파일 손상 또는 계정 잠김 여부를 확인할 수 없습니다. 스택 전체를 교체하기 전에 영향을 받는 서비스와 해당 로그를 확인하는 것부터 시작하십시오.

어떤 로그인 경로에서 오류가 발생하고 있습니까?

오류가 발생하는 시점, 사용자 이름, 접속 방식(SSH, 로컬 텍스트 콘솔, 그래픽 로그인 sudo등) 을 한 번 재현하고 기록해 두세요 su. 관리자 계정으로 로그인할 수 있다면 최근 시스템 메시지를 확인해 보세요.

sudo journalctl -e

SUSE의 SLES 문제 해결 가이드에서는 로그인 및 PAM 오류에 대한 로그 확인을 권장합니다. 오류 발생 시점 주변의 모듈 이름이나 이유(예: 계정 거부, 디렉터리 서비스 사용 불가, 모듈 누락 또는 파일/권한 오류)를 찾아보세요. 사용자 이름, 호스트 이름, 주소 및 기타 민감한 정보를 삭제하지 않고 로그를 공개적으로 공유하지 마십시오.

SSH 연결만 실패하는 경우 SSH 데몬의 로그를 확인하십시오.

sudo journalctl -u sshd

다음으로 접근 경로를 비교해 보세요. 사용자가 로컬 콘솔에서는 인증이 되지만 SSH를 통해서는 인증이 되지 않는다면, /etc/pam.d/sshdSSH 접근 정책이나 SSH 관련 모듈에 문제가 있는지 확인하세요. 여러 서비스에서 동일한 로컬 사용자의 인증을 거부하는 경우, 해당 사용자의 공유 common-*파일을 검사해 보세요. 한 사용자만 인증에 실패하는 경우, 시스템 전체 인증 방식을 변경하기 전에 계정 상태와 암호를 확인하세요.

이 계정은 로컬 계정입니까, 아니면 네트워크 ID입니까?

로컬 사용자의 경우, 먼저 사용자 이름, 키보드 레이아웃 및 Caps Lock 키를 확인하십시오. 자격 증명 재설정이 필요한 경우, /etc/shadow수동으로 편집하는 대신 YaST 사용자 및 그룹 관리와 같은 관리자 승인 암호 도구를 사용하십시오. 루트가 아닌 모든 사용자가 SSH를 통해 접속이 거부되는 경우, /etc/nologinPAM 파일을 변경하기 전에 계획된 유지 관리 파일이 있는지 확인하십시오. 유지 관리 차단이 만료되었고 권한이 있는 경우에만 해당 파일을 삭제하십시오.

LDAP, Active Directory 또는 기타 디렉터리 기반 사용자의 경우, 다른 서버에서 암호가 정상적으로 작동한다고 해서 이 SLES 호스트가 ID 공급자에 연결할 수 있다는 것을 보장할 수는 없습니다. SUSE는 네트워크 및 DNS 문제, Kerberos 시간 편차, 잘못 구성된 PAM 규칙, 호스트 액세스 정책, 사용 불가능한 홈 디렉터리 등을 가능한 원인으로 제시합니다. 다른 도메인 사용자가 로그인할 수 있는지, 그리고 해당 사용자가 다른 호스트에 로그인할 수 있는지 확인하십시오. 그런 다음 구성된 ID 서비스와 서버 연결 상태를 확인하십시오.

호스트가 SSSD를 사용하는 경우 해당 서비스와 PAM이 SSSD를 사용하도록 구성되어 있는지 확인하십시오.

systemctl status sssd
sudo pam-config --query --sss

SSSD는 사용자 정보를 캐시할 수 있으며 디렉터리에 일시적으로 연결할 수 없는 경우에도 인증을 허용할 수 있지만, 이러한 동작은 구성 및 캐시된 자격 증명에 따라 달라집니다. 따라서 캐시가 오래되었거나 누락된 것은 하나의 가능성일 뿐, 결론은 아닙니다. 캐시를 지우거나 모듈을 변경하기 전에 DNS, Kerberos 시간 동기화, 디렉터리 연결 가능성 및 SSSD 로그를 확인하십시오. ID 공급자가 "계정이 잠겼습니다" 또는 "계정이 비활성화되었습니다"라고 보고하는 경우 디렉터리 관리자에게 해당 계정의 정책을 확인하도록 요청하십시오. PAM은 결정을 보고하는 것이지, 반드시 결정을 내리는 것은 아닙니다.

PAM 구성 문제가 확인된 경우 어떻게 해결해야 합니까?

서비스별 파일과 해당 파일에 포함된 공유 규칙을 검사하십시오.

sudo grep -nE '^(auth|account|password|session)' /etc/pam.d/sshd
sudo pam-config --query --sss

SLES에서는 pam-config전역 파일이 / etc /etc/pam.d/common-*/unit/ services /etc/pam.d/sshd...pam-configsudo pam-config --add --sss

흔히 발생하는 위험한 오해 중 하나는 해당 pam-config --create명령이 무해한 복구 명령이라는 것입니다. SUSE에 따르면 이 명령은 기본적인 Unix 인증 구성을 생성하고 관리하지 않는 기존 파일을 덮어쓰며 백업 복사본은 유지합니다. 이로 인해 사용자 지정 MFA 또는 디렉터리 인증 동작이 제거될 수 있습니다. 따라서 일반적인 복구 단계로 이 명령을 실행하지 마십시오. 서비스 파일에 오타가 있는 경우, 신뢰할 수 있는 백업에서 해당 서비스의 정상 작동하고 버전에 맞는 구성을 복원하거나 조직의 변경 프로세스에 따라 오류가 있는 특정 줄을 수정하십시오.

수리가 완료되었는지 어떻게 확인할 수 있나요?

기존 루트 또는 관리자 세션을 열어 둔 상태로 유지합니다. 동일한 서비스(예: 새 SSH 연결)를 통해 두 번째 세션을 시작하고 해당 계정을 테스트합니다. 로그에 동일한 PAM 거부 오류가 더 이상 기록되지 않고 다른 구성된 인증 방법이 여전히 작동하는지 확인합니다. 오류가 계속 발생하는 경우 정확한 타임스탬프, 서비스, PAM 모듈 이름 및 관련 로그 라인을 익명 처리하여 캡처합니다. 이러한 세부 정보는 일반적인 "인증 실패" 메시지보다 더 유용합니다.

공식 참조

• SUSE SLES 15 SP7 관리 가이드: 일반적인 문제 및 해결 방법 — 로컬 및 네트워크 로그인 문제 해결.
• SUSE SLES 15 SP7 보안 및 강화 가이드: PAM을 사용한 인증 — PAM 단계, SSH 스택 등 pam-config.
• SUSE SLES 15 SP7: YaST를 사용한 인증 클라이언트 설정 — SSSD 상태 및 캐시 동작.
• SUSE SLES 15 SP7: OpenSSH를 사용한 네트워크 운영 보안 — sshd 저널 메시지 보기.