OpenSSH 10.6p2 인증 우회 수정과 Alpine 서버 패치 확인

원격 서버의 인증 경로를 점검하고 보완하는 모습을 표현한 생성형 에디토리얼 이미지. 실제 제품 화면이나 공격 절차를 나타내지 않는다.

SSH에는 늘 키로 접속하니 비밀번호 인증 문제와 무관할까? 서버가 비밀번호 로그인도 허용하고 있다면 따로 확인해야 한다. 이번 OpenSSH 보안 수정에서 먼저 볼 것은 평소 접속 습관보다 서버의 실제 인증 설정과 실행 중인 프로세스다.

OpenSSH는 November 5, 2026 Portable OpenSSH 10.6p2를 발표했다. musl libc를 사용하고 PAM을 비활성화한 일부 Linux 환경에서 발생하는 비밀번호 인증 우회를 막는 수정이며, 프로젝트는 이를 critical로 설명한다. 모든 Linux나 모든 OpenSSH 설치가 같은 조건으로 영향받는다는 뜻은 아니다. OpenSSH 공식 릴리스

1. Alpine 이미지 이름만으로 영향 여부를 판단하지 않는다

Alpine 공식 공지는 sshd 실행, PAM 미사용, 비밀번호 인증 허용에 더해 특정 계정 비밀번호 필드 조합이 있어야 한다고 설명한다. 비밀번호 필드가 *인 계정과 $5$ 또는 $6$ 해시를 가진 다른 로컬 계정이 함께 있는 경우다. sshd를 실행하지 않는 컨테이너는 해당하지 않는다. 영향 조건과 예외

운영 목록은 이미지 태그만 모으기보다 다음처럼 나누는 편이 좋다.

SSH 서버를 직접 실행하는 VM과 관리용 호스트

컨테이너 안에서 sshd까지 실행하는 구성

SSH 클라이언트만 포함한 빌드 이미지

SSH 접속을 제공하지 않는 애플리케이션 컨테이너

뒤의 두 종류까지 같은 긴급도로 취급하면 실제 접속 가능한 서버의 조치가 늦어질 수 있다. 반대로 “우리는 키만 쓴다”는 답만으로 앞의 두 종류를 제외하지 않는다. 사용자가 키를 선택한 것과 서버가 비밀번호를 거부하는 것은 별개의 설정이다.

2. 설정 파일 검색보다 최종 적용값을 확인한다

sshd_config에는 Include와 Match 조건이 들어갈 수 있다. 또한 sshd의 시작 옵션이 설정 파일 값을 덮어쓸 수 있다. 한 줄을 검색해 no를 찾았다고 모든 접속에 적용됐다고 판단하지 않는다. sshd 설정 처리

아래는 관리 권한이 있는 대상 서버에서 실행할 읽기 전용 점검 예시다. deploy, 주소, 호스트 이름은 설명용 값이므로 실제 접속 조건으로 바꿔야 한다.

-T는 설정과 키를 검사하고 유효 설정을 출력한다. 실행 중인 데몬을 조회하는 것이 아니라 새 검사 프로세스가 현재 파일과 옵션을 읽은 결과다. -C는 해당 연결에 맞는 Match 조건을 적용한다. 서비스가 별도 -f 파일이나 -o 옵션으로 시작했다면 검사에도 같은 조건을 반영한다. 호스트 키를 읽을 수 없는 권한 오류가 나면 결과를 정상 설정으로 해석하지 않는다. 공식 옵션 설명

관련 사용자와 출발지 조건별로 검사를 반복한다. Match LocalAddress·LocalPort를 사용한다면 -C에 laddr·lport도 지정한다.

여기서 버전 문자열은 참고 자료다. PAM 지원 여부와 배포판 백포트까지 알려주는 취약점 판정기는 아니다. usepam 줄이 없다는 사실만으로 안전하다고 결론 내리지 않는다. 계정 조건을 조사할 때도 비밀번호 해시나 shadow 파일 전체를 티켓·채팅에 붙여 넣을 필요는 없다.

3. 안정 브랜치는 배포판 패치 버전으로 확인한다

Alpine은 같은 날 3.21.10, 3.22.8, 3.23.8, 3.24.4를 공개했다. 이 릴리스에는 openssh-server 인증 우회 수정이 포함된다. Alpine 릴리스 공지

주요 브랜치의 수정 패키지는 다음과 같다.

Alpine 3.24: 10.3_p1-r2

Alpine 3.23: 10.2_p1-r1

Alpine 3.22: 10.0_p1-r11

Alpine 3.21: 9.9_p2-r1

edge: 10.6_p2-r0

안정 브랜치에는 보안 수정이 백포트됐다. 따라서 10.6p2보다 숫자가 작다는 이유만으로 미수정이라고 판단하거나, 패치를 위해 저장소를 edge로 바꿀 필요는 없다. 이전 브랜치의 수정 버전과 지원 상태는 공식 공지에서 따로 확인한다. 브랜치별 수정 버전

실무에서는 “업데이트 완료” 한 칸보다 배포판 브랜치, 설치 패키지 전체 버전, 공급자 공지, 재시작 시각을 함께 남기는 편이 검증하기 쉽다. 자체 빌드라면 릴리스 이름 외에 적용한 수정 커밋과 빌드 산출물도 추적한다.

4. 업데이트 후 새 로그인까지 확인한다

Alpine은 패키지 갱신만으로 실행 중인 sshd가 바뀌지 않으므로 재시작이 필요하다고 명시한다. 즉시 업데이트하기 어렵다면 PasswordAuthentication no 적용을 임시 대응으로 안내한다. 공식 조치 안내

다음은 이를 운영 환경에 적용할 때 제안하는 순서다.

현재 SSH 세션을 유지하고 별도 콘솔 등 복구 경로를 확인한다.

변경 전 새 세션에서 정상적인 키 로그인이 되는지 확인한다.

현재 브랜치의 수정 패키지를 적용하거나, 승인된 절차로 비밀번호 인증을 차단한다.

sshd -t로 설정·키 검사를 통과한 뒤 환경의 서비스 관리 절차에 따라 재시작한다.

새 세션으로 다시 접속하고, 앞의 sshd -T -C 검사와 설치 패키지 버전을 기록한다.

일반적인 Alpine OpenRC 환경의 재시작 명령은 rc-service sshd restart다. 컨테이너나 다른 프로세스 관리 환경에는 그 명령을 그대로 적용하지 않는다. 키 로그인을 먼저 확인하고 기존 세션을 유지하라는 주의사항도 Alpine 공지에 포함돼 있다. 재시작 및 접속 주의사항

sshd -t 성공은 설정 검사를 통과했다는 의미다. 새 바이너리가 실제 서비스 중인지, 정상 사용자가 접속할 수 있는지까지 증명하지 않는다. 이 두 가지를 각각 확인해야 변경 작업을 닫을 수 있다.

5. 패치 적용과 과거 침해 확인을 분리한다

패치는 앞으로의 노출을 줄이는 조치다. 과거에 비정상 접속이 없었다는 증거가 되지는 않는다. Alpine은 비밀번호가 없는 계정에 대한 Accepted password for 기록과 권한 상승·새 계정·authorized keys 변경을 검토하라고 안내한다. 로그 점검 안내

팀의 완료 기준을 정한다면 다음 네 항목을 권한다.