OpenSSH 10.6p2, musl 환경의 비밀번호 인증 우회를 차단한다

공개 설명에서 *sshole로 불리는 이번 문제를 “리눅스 SSH 전체가 위험하다”로 묶으면 대응 대상을 잘못 고르게 된다.[5][7] Ubuntu 호스트가 영향 밖이어도 그 안에서 실행하는 Alpine 기반 워크로드는 별개다. 반대로 Alpine 이미지라는 이유만으로 모두 취약한 것도 아니다. 실행 중인 sshd와 인증 구성을 함께 확인해야 한다.

어떤 구성이 모두 겹쳐야 영향을 받나?

musl 기반 Linux에서 sshd를 실행하고, PAM을 사용하지 않으며, 비밀번호 인증과 특정 계정 구성이 함께 존재해야 한다. Alpine 공식 공지가 제시한 조건은 모두 충족되어야 한다. 공지가 확인한 영향 범위는 Alpine 3.16~3.24와 edge다.[1]

구체적으로 Alpine의 PAM 없는 openssh-server를 사용하거나, openssh-server-pam에서 UsePAM no로 실행하는 환경이 대상이다. 여기에 PasswordAuthentication yes, 비밀번호 필드가 정확히 *인 계정, 같은 머신에 $5$ 또는 $6$ 비밀번호 해시를 가진 계정이 하나 이상 있어야 한다. SSH 포트에 접근할 수 있다는 전제도 필요하다.[1]

여기서 *는 빈 문자열 비밀번호와 다르다. 정상적인 비밀번호 해시가 아닌 표식으로, 키 전용 계정 등에서 쓰인다. !와도 구별해야 한다. Alpine 공지는 !인 잠금 계정은 비밀번호와 키 모두로 로그인할 수 없다고 설명한다. *를 보고 같은 방식의 잠금이라고 판단하면 이번 취약점의 핵심을 놓친다.[1]

어느 계정에도 $ 형식의 비밀번호 해시가 없는 시스템은 영향 밖이다. cloud-init이 PasswordAuthentication no를 기록한 클라우드 이미지도 해당하지 않는다. 따라서 이미지 이름만 수집하지 말고 실제 실행 구성까지 확인해야 한다.[1]

왜 키 전용 계정의 인증이 통과하나?

musl의 crypt()가 반환하는 오류 문자열 *와 계정에 저장된 *가 같아지는 것이 원인이다. PAM을 사용하지 않는 sshd는 입력값을 crypt()로 처리한 결과와 저장된 비밀번호 필드를 비교한다. 저장 필드가 너무 짧아 salt를 얻을 수 없으면 다른 계정의 salt를 가져와 계산한다.[1]

이 경로에서 musl의 crypt()는 입력 키가 256바이트를 넘으면 오류 표시로 *를 반환한다. 그런데 비교 대상 계정의 저장 필드도 *라면 오류 결과가 인증 성공으로 이어진다. 정상적인 비밀번호 해시를 알아내거나 해독하는 문제가 아니라, 실패를 나타내는 값과 계정 표식이 충돌하는 문제다.[1]

길이 기준은 문자 수가 아니라 바이트 수다. 오류가 실제 인증 성공으로 이어지려면 앞서 설명한 계정·해시·설정 조건이 모두 맞아야 한다.[1]

OpenSSH는 근본 원인이 sshd 외부에 있다고 설명하면서도 sshd에서 우회를 막는 수정본을 배포했다. 공식 수정 커밋에서는 저장된 비밀번호 필드의 길이가 최소 기준인 4 이상인지 검사한 뒤 비교하도록 바뀐 것을 확인할 수 있다. 따라서 * 같은 짧은 필드가 오류 결과와 같다는 이유만으로 인증되는 경로를 차단한다.[3][4][6]

root:*가 보이면 곧바로 root 접속이 가능한가?

아니다. 기본 PermitRootLogin prohibit-password는 root의 직접 비밀번호 접속을 막는다. Alpine 기본 이미지의 root:*만 보고 원격 root 접속이 가능하다고 단정하면 안 된다. 공지는 root 직접 접속에는 PermitRootLogin yes 설정이 필요하다고 구분한다.[1]

다만 로그인 가능한 다른 계정에 권한 상승 수단이 있으면 root 권한까지 얻을 수 있다. 공식 tiny-cloud의 qcow2·VHD·AMI 이미지 중 3.18.11부터 3.24.3까지는 * 필드의 alpine 사용자와 비밀번호 없는 doas를 함께 제공한다. 이 경우 조건이 맞아 alpine 계정으로 접속하면 doas를 통해 root가 될 수 있다.[1]

해당 tiny-cloud 이미지는 최초 부팅 상태에서는 안전하다. 관리자가 콘솔 비밀번호를 설정하거나 user-data의 hashed_passwd로 사용자를 추가해 머신에 $6$ 해시가 생기면 위험 조건이 성립한다. 초기 이미지 상태가 안전했다는 사실만으로 이후 운영 상태까지 안전하다고 판단해서는 안 된다.[1]

3.21.10·3.22.8·3.23.8·3.24.4 및 이후의 해당 이미지는 수정 패키지를 포함한다. 이전 이미지에서 이미 실행 중인 인스턴스는 새 이미지가 나왔다는 이유로 해결되지 않는다. 그 인스턴스의 OpenSSH를 업데이트하거나 비밀번호 인증을 꺼야 한다.[1]

어느 버전으로 올리고 무엇을 재시작해야 하나?

Alpine은 소속 브랜치의 수정 패키지로 업데이트한 뒤 실행 중인 sshd를 재시작하라고 안내한다. 업스트림 수정 릴리스는 2026년 11월 5일 공개된 Portable OpenSSH 10.6p2지만, Alpine 안정 브랜치에는 같은 문제의 수정이 백포트됐다. “10.6p2 미만이면 모두 취약하다”는 판정은 틀리다.[1][3]

표는 Alpine 공식 공지의 수정 버전이다. 3.16까지 수정 패키지가 제공됐다는 사실과 정규 지원 여부는 별개다. 오래된 브랜치를 계속 운영해도 된다는 의미로 받아들이지 말아야 한다.[1]

Alpine 공식 업데이트와 OpenRC 재시작 명령은 다음 두 줄이다. 패키지를 올려도 실행 중인 데몬은 교체되지 않으므로 두 번째 줄까지 실행해야 한다.[1]

apk upgrade -U -a
rc-service sshd restart

OpenRC가 아닌 환경은 그 환경의 프로세스 관리 방식에 맞게 sshd를 재시작해야 한다. 아래 버전 조회는 공식 공지의 조치 명령과 구분한 보조 확인용이다. 설치 패키지를 해당 브랜치의 표와 비교하되, 버전 문자열을 확인한 것만으로 실행 중인 데몬 교체까지 입증됐다고 보지는 말자.

apk info -v openssh
sshd -V

당장 패치할 수 없다면 어떻게 막나?

비밀번호 인증을 끄고 sshd를 재시작하면 된다. 단, 먼저 SSH 키로 새 로그인이 되는지 확인하고 현재 세션은 유지하라. 아래 명령은 root로 실행한다. 설정을 바꾼 뒤 검사와 재시작, 새 접속 확인까지 끝나기 전에 기존 연결을 닫지 않는 것이 중요하다.[1]

다음은 Alpine 원문의 drop-in과 sed를 함께 사용하는 완화 명령이다. Alpine 기본 설정은 3.19부터 drop-in 디렉터리를 읽는다. 이전판은 이를 무시하므로 drop-in 파일만 만들어서는 안 되며, 본 설정을 바꾸는 sed 단계가 필수다.[1]

아래는 Alpine 공식 명령의 긴 경로와 설정 이름을 셸 변수로 나눈 표기다. 설정 변경 내용과 정규식은 원문과 같다. 한 셸에서 블록 전체를 순서대로 실행한다.[1]

d=/etc/ssh/sshd_config.d
c=/etc/ssh/sshd_config
p=PasswordAuthentication
mkdir -p "$d"
printf '%s no\n' "$p" > \
  "$d/00-no-passwords.conf"
r='s/^\(\s*'
r="${r}${p}[^y#]*\)yes/\1no/i"
sed -i.bak -e "1i $p no" \
  -e "$r" "$c"
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

sed는 본 설정 파일 맨 위에 PasswordAuthentication no를 넣고, Match 블록 안을 포함한 해당 설정의 yes를 no로 바꾼다. 원본은 /etc/ssh/sshd_config.bak으로 보관한다. 설정 검사에 성공해야 재시작하며 마지막 출력은 다음과 같아야 한다.[1]

passwordauthentication no

운영 권고로는 여기에 실제 접속 사용자·주소 등 Match 조건별 유효 설정 확인을 추가한다. 기본 출력 하나만 보고 모든 접속 조건에 같은 설정이 적용됐다고 넘기지 말자는 취지다. 새 키 접속까지 확인한 뒤 기존 세션을 정리하자.

침해 여부와 다른 배포판의 영향은 확인됐나?

이번에 확인한 공식 공지와 메일에서는 실제 악용 사례나 진행 중인 공격 캠페인을 확인하지 못했다. 이는 “악용이 없다”는 뜻이 아니다. Alpine은 /var/log/messages에서 비밀번호 로그인이 허용되지 않아야 할 alpine·root·키 전용 계정의 Accepted password for 기록을 확인하고, doas 사용과 최근 생성된 사용자·파일·authorized_keys도 검토하라고 안내한다. 의심되는 로그인을 배제할 수 없다면 침해된 것으로 취급하라는 지침이다. 기록이 없다는 사실만으로 침해가 없었다고 단정하지 말자.[1]

발견자는 Wakefield의 Özgün Kültekin이다. Miller는 AI 에이전트가 보안 문제를 수 시간 만에 독립적으로 재발견하는 사례 때문에 긴 엠바고를 위험하게 본다고 설명했다. 이것은 빠른 공개의 이유이지 이번 취약점이 이미 악용됐다는 증거는 아니다.[2][3]

OpenWrt·Buildroot·Yocto는 2차 참고 설명과 보도에 등장한다. 각 배포판의 공식 공지는 확인하지 못했으므로 Alpine의 수정 표를 그대로 적용하거나 배포판별 대응 완료를 단정하지 않는다. 해당 환경 역시 musl, sshd, PAM, 비밀번호 인증과 계정 조건을 따로 확인해야 한다.[7][8]

Ubuntu 호스트의 별도 패치 작업은 APT CVE-2026-109518, Ubuntu 22.04·24.04 수정 버전과 Ubuntu CVE-2026-98432, LTS 수정 커널 아직 정식 배포 전에서 다뤘다. 이번 OpenSSH 인증 우회와는 별개 사안이다. 커널 글은 당시 배포 상태를 설명하므로 실제 설치 전 현재 공지를 다시 확인하자.

출처