무슨 일이 있었나요
Alpine Linux가 openssh-server의 비밀번호 인증 우회(password authentication bypass) 문제를 다룬 보안 공지를 올렸어요. 공지 주소에 찍힌 날짜는 2026년 11월 5일이에요. OpenSSH 쪽에서도 PAM 없이 돌아가는 Alpine 환경을 위한 긴급 우회 조치를 10.6p2 릴리스로 내놓았고요.
먼저 솔직하게 말씀드릴게요. 이 글은 공지 제목과 릴리스 항목을 기준으로 배경을 풀어 쓴 글이에요. 정확한 영향 버전과 근본 원인은 여기서 단정하지 않을 테니, 실제 조치 전에 Alpine 공지와 OpenSSH 릴리스 노트를 꼭 직접 확인해 주세요.
왜 서둘러야 하냐면요, SSH는 서버의 현관문이거든요. 인증 우회라는 말은 그 문의 잠금장치가 제 역할을 못 할 수 있다는 뜻이에요. 어떤 조건에서 뚫리는지는 공지를 봐야 알 수 있지만, 인터넷에 sshd를 열어둔 Alpine 서버가 있다면 일단 점검부터 하는 게 맞아요.
왜 하필 "PAM 없는 Alpine"일까요
이 사건을 이해하려면 PAM부터 알아야 해요. PAM(Pluggable Authentication Modules)이 뭐냐면, 리눅스에서 로그인 검사를 대신 맡아주는 공용 창구예요. 건물 로비의 출입 관리 데스크를 떠올리면 쉬워요. 각 사무실이 방문객을 직접 확인하는 대신 데스크에 맡기는 거죠. Ubuntu나 RHEL 계열의 sshd는 보통 이 창구를 통해 인증을 처리해요.
그런데 Alpine은 조금 달라요. 작고 단순한 걸 지향하는 배포판이라 glibc 대신 musl을, GNU 도구 대신 BusyBox를 쓰거든요. 기본 openssh-server도 PAM 없이 빌드돼 있고, PAM이 필요하면 openssh-server-pam 패키지를 따로 설치해야 해요.
PAM이 없으면 sshd가 비밀번호를 직접 확인해요. /etc/shadow에서 해시값을 읽고, 입력받은 비밀번호를 crypt() 함수로 해시한 다음 둘을 비교하는 식이에요. 대부분의 주요 배포판에서는 잘 지나가지 않는 코드 경로를 Alpine은 기본으로 쓰고 있는 셈이죠. 릴리스 항목에 "without PAM"이 들어간 걸 보면 이 근처가 관련됐을 가능성이 높아 보여요. 다만 이건 제목에서 유추한 것이지, 확인된 원인은 아니에요.
버전 번호도 힌트를 줘요. OpenSSH는 원래 OpenBSD용으로 개발되고, 다른 운영체제로 옮긴 portable 버전에 p1 같은 꼬리표가 붙어요. p2는 보통 portable 쪽 문제를 고치려고 추가로 낸 릴리스예요.
지금 바로 확인할 것
먼저 내 서버에 OpenSSH 서버가 깔려 있는지부터 봐요. Alpine 베이스 이미지를 쓴다고 전부 해당되는 건 아니고, sshd를 실제로 설치해서 띄운 경우가 점검 대상이에요.
apk list --installed | grep openssh
설치돼 있다면 패키지를 올리고 sshd를 재시작해요. 패키지만 바꾸고 재시작을 안 하면 예전 프로세스가 계속 돌 수 있거든요. 올린 뒤에는 공지에 나온 수정 버전 이상인지 비교해 보세요.
apk update && apk upgrade
rc-service sshd restart
그다음 현재 적용된 설정을 확인해요. sshd -T는 설정 파일을 사람이 읽는 게 아니라 sshd가 실제로 해석한 최종 값을 보여줘서 편해요.
sshd -T | grep -iE 'passwordauthentication|kbdinteractiveauthentication|permitemptypasswords'
바로 패치하기 어렵다면, 키 인증만 쓰는 서버는 PasswordAuthentication no로 비밀번호 로그인을 꺼두고 22번 포트 접근을 방화벽이나 보안 그룹으로 좁히는 게 일반적인 방어예요. 공지에 별도 권고가 있다면 그쪽을 우선해 주세요.
컨테이너는 한 가지 더 조심해야 해요. 실행 중인 컨테이너는 알아서 패치되지 않아요. 이미지를 다시 빌드해서 재배포해야 하는데, Docker 빌드 캐시가 예전 apk add 레이어를 그대로 쓰면 소용이 없어요. docker build --no-cache로 새로 빌드하고, 이미지 안의 패키지 버전까지 확인하세요.
업계 맥락: 같은 OpenSSH도 빌드에 따라 달라요
SSH는 최근 몇 년간 크게 두 번 흔들렸어요. 2024년 3월의 xz 백도어(CVE-2024-3094)는 일부 배포판이 sshd에 libsystemd를 연결한 구조를 노렸고, 같은 해 7월의 regreSSHion(CVE-2024-6387)은 glibc 기반 리눅스의 sshd에서 시그널 처리 경쟁 상태를 파고든 취약점이었어요.
두 사건의 공통점이 있어요. 같은 OpenSSH라도 어떻게 빌드되고 어떤 라이브러리와 묶이느냐에 따라 위험이 달라졌다는 거예요. 이번 건도 제목만 보면 비슷한 교훈을 주는데요, 흔한 환경에서 안전하다고 해서 소수 환경의 코드 경로까지 안전한 건 아니에요.
한국 개발자에게 주는 시사점
Alpine은 컨테이너 베이스로 많이 쓰이니까, 이번 기회에 sshd가 들어간 이미지를 찾아보세요. SFTP 전용 컨테이너, 배스천 서버(내부망으로 들어가는 관문 서버), 오래된 CI 러너가 흔한 후보예요. 컨테이너 안의 sshd가 단순 디버깅용이라면 docker exec, kubectl exec, AWS SSM Session Manager 같은 대안으로 아예 없애는 편이 나아요. 없는 문은 뚫릴 일도 없으니까요.
Trivy나 Grype 같은 이미지 스캐너도 좋지만, 취약점 DB에 반영되기까지 시차가 있을 수 있어요. 그래서 스캔 결과만 기다리기보다 패키지 버전을 직접 확인하는 게 확실해요.
마무리
한 줄로 정리하면, Alpine에서 sshd를 쓴다면 공지를 확인하고 패치한 뒤 컨테이너까지 다시 빌드하세요. 여러분 팀은 이런 공지가 떴을 때 영향받는 서버와 이미지를 얼마나 빨리 찾아낼 수 있나요? 컨테이너 안의 sshd, 아직 쓰고 계신가요?
🔗 출처: Hacker News