OpenSSH sshole(CVE-2026-123158) 취재 노트: 비밀번호 없는 계정에 긴 비밀번호로 로그인이 뚫린다

2026년 11월 5일 OpenSSH 10.6p2가 나왔습니다. 리눅스에서 비밀번호가 없는 계정에 아주 긴 비밀번호를 보내면 로그인이 통과되는 인증 우회 취약점(별칭 sshole, CVE-2026-123158)을 고친 보안 릴리스입니다. 서버 접속 수단인 SSH의 문제라 이름만 보면 모든 서버가 위험해 보이지만, 실제로 영향을 받는 환경은 한정적입니다. 이 글에서는 어떤 환경이 위험한지, 어떤 환경은 괜찮은지, 지금 무엇을 확인해야 하는지를 공개된 자료로 정리합니다. 자료는 11월 8일까지의 것입니다.

한눈에 보기

취약점: CVE-2026-123158 (sshole), CVSS 3.1 기준 8.1(높음)
내용: 비밀번호가 설정되지 않은 계정에 긴 비밀번호를 보내면 인증을 통과하는 인증 우회
수정: OpenSSH 10.6p2 (2026년 11월 5일) 및 배포판의 패치 패키지
영향: musl C 라이브러리를 쓰고 PAM이 꺼진 리눅스(대표적으로 Alpine Linux의 기본 sshd 패키지)
영향 없음: Debian, Ubuntu, Fedora 같은 glibc 계열, PAM으로 비밀번호를 검증하는 환경, 비밀번호 로그인을 끈 서버
실제 공격: 공개 후 9시간이 지나기 전에 첫 공격 시도가 관측되었고, 보안업체 허니팟에서 root 획득이 확인됨

어떻게 뚫리나

보안 연구자가 밝힌 원인은 세 가지 설계가 겹친 것입니다.

musl의 비밀번호 처리: musl의 비밀번호 해시 함수(crypt)는 256바이트를 넘는 비밀번호를 거부하고 실패 값으로 “*”를 돌려줍니다.
2016년의 사용자 이름 추측 방지: 존재하지 않거나 사용할 수 없는 계정도 로그인 시간이 똑같도록, OpenSSH는 해시가 없는 계정에는 다른 계정의 설정으로 해시 계산을 한 번 해 봅니다.
비밀번호 없는 계정의 표기: /etc/shadow에서 비밀번호가 없는 계정(키 로그인 전용 계정, LDAP 계정, 클라우드 기본 계정, Alpine 3.16 이후의 root)은 “*”로 표시됩니다.

공격자가 이런 계정에 긴 비밀번호를 보내면 musl의 해시 함수가 “*”를 돌려주고, sshd는 이것을 저장된 값 “*”와 비교해 같다고 판단해 로그인을 허용합니다. 연구자는 이것을 암호학적 약점이나 메모리 손상 취약점이 아니라 논리 결함이라고 설명했고, 글리비씨와 musl, PAM 유무의 모든 조합으로 sshd를 빌드해 약 17,600번의 비정상 로그인을 시도했습니다. 잘못 허용한 것은 PAM 없는 musl 빌드뿐이었습니다. OpenSSH 측은 릴리스 노트에서 “근본 원인은 sshd 밖에 있지만 sshd를 통해 악용될 수 있고 sshd에서 막을 수 있다”고 밝혔습니다.

영향받는 조건 (모두 해당할 때)

OpenSSH가 10.6p2 이전이다.
musl libc 기반이다(Alpine, 그 밖에 OpenWrt, Buildroot, Yocto 같은 임베디드 계열도 musl을 쓸 수 있음).
PAM을 쓰지 않는다(Alpine의 기본 openssh-server 패키지, 또는 UsePAM no).
비밀번호 로그인이 켜져 있다(기본값).
비밀번호 필드가 “*”인 계정이 있다(키 전용 계정, root 등).
그 밖에 진짜 비밀번호가 있는 로컬 계정이 하나 이상 있다.

글자 수 기준은 자료마다 조금 다릅니다. 발견 보고는 257~1,024바이트로, 보도는 256자를 넘는 비밀번호로 설명합니다.

영향이 없는 환경

Debian, Ubuntu, Fedora 같은 glibc 계열 리눅스
PAM으로 비밀번호를 검증하는 환경
PasswordAuthentication을 no로 둔 서버
비밀번호 필드가 “!”인 계정
OpenSSH 서버가 없는 컨테이너, Dropbear, OpenBSD의 sshd

RHEL 계열은 읽은 자료 어디에도 이름이 나오지 않았습니다. glibc와 PAM을 쓰는 일반 구성이면 같은 이유로 영향이 없을 가능성이 높지만, 공급업체 공지로 확인하는 것이 안전합니다.

실제 공격은 있었나

보안업체 프레비디언(Previdian)이 취약점 공개 후 9시간도 지나지 않아 첫 시도를 관측했다고 밝혔습니다. 같은 주소에서 8번의 시도가 있었고, 공격자는 긴 비밀번호로 접속해 id, uname, hostname 같은 명령을 실행했습니다.
진짜 Alpine과 OpenSSH로 만든 허니팟에서 root 획득이 확인되었습니다.
국내 보도는 실제 기업 침해나 악성코드 설치는 확인되지 않았고, 성공은 보안업체 허니팟에 한정된다고 전했습니다.
GitHub에 개념증명(PoC) 코드가 올라와 있지만, 검증되지 않았고 악성코드가 섞여 있을 수 있으니 직접 실행하지 않는 것이 좋습니다.
인터넷 노출 장비의 악용 사례를 모은 미국 CISA 목록(KEV)에는 11월 6일 보도 시점에 아직 오르지 않았습니다.
한국인터넷진흥원(KISA)이 11월 7일 보안 업데이트 권고를 냈다고 보도되었습니다. 원문 공지는 이 글을 쓰는 시점에 직접 확인하지 못했습니다.

OpenSSH 개발자 데이미언 밀러(Damien Miller)는 “읽기를 멈추고 PasswordAuthentication=no로 설정하거나, 해당 시스템의 SSH를 즉시 끄라”고 밝혔습니다.

지금 해야 할 일

1. 내가 영향권인지 확인

서버에서 아래 명령으로 비밀번호 로그인과 PAM 사용 여부를 봅니다(관리자 권한).

sshd -T | grep -i -E 'passwordauthentication|usepam'

비밀번호 로그인이 켜져 있고(PasswordAuthentication yes) PAM이 꺼져 있으면(UsePAM no) 위험한 구성입니다. 비밀번호 로그인이 꺼져 있거나 PAM이 켜져 있으면 노출되지 않습니다. 운영체제도 확인하세요. Alpine이나 OpenWrt 같은 musl 기반이 아니면 이번 취약점의 영향권이 아닙니다.

2. 패치

Alpine: 패키지를 업데이트한 뒤 sshd를 반드시 재시작합니다. 설치만으로는 실행 중인 sshd가 바뀌지 않습니다. 패치된 패키지는 Alpine 3.16부터 edge까지 모두 11월 5일에 나왔고, edge는 10.6_p2이고 나머지 브랜치는 기존 버전에 수정을 얹은 백포트 버전입니다.
3.16 이전의 Alpine에는 수정 패키지가 없습니다. 이 경우 비밀번호 로그인을 끄는 것이 유일한 방법입니다.
클라우드 이미지와 컨테이너는 수정된 베이스 이미지로 다시 빌드해야 합니다. Alpine 클라우드 이미지(tiny-cloud 3.18.11~3.24.3)가 영향받는 것으로 보도되었습니다.

3. 패치가 어려우면 임시 조치

비밀번호 로그인을 끕니다(PasswordAuthentication no). 끄기 전에 키로 접속되는지 반드시 먼저 확인하세요. 안 그러면 서버에서 쫓겨납니다.
SSH 포트를 공개하지 않고 VPN이나 허용된 주소에서만 접속하게 합니다.

4. 이미 뚫렸는지 확인

로그(예: /var/log/messages)에서 비밀번호가 없는 계정(root, alpine, 키 전용 계정)이 “Accepted password”로 로그인한 기록이 있는지 봅니다.
새로 생긴 계정, authorized_keys 변경, doas 사용 기록을 점검합니다.
접속 흔적을 배제할 수 없으면 서버가 침해된 것으로 보고 대응해야 합니다.

올해 나온 다른 OpenSSH 보안 수정

2026년 OpenSSH는 보안 수정이 잦았습니다. 릴리스 노트에서 확인한 내용 중 눈에 띄는 것만 간추립니다(대부분 릴리스 노트에는 CVE 번호가 없습니다).

10.3 (4월 2일): 인증서 사용자(principal) 이름에 쉼표가 있을 때 권한이 잘못 판정되던 문제(CVE-2026-35414, 별칭 SplitSSHell, CVSS 8.1)가 수정되었습니다. 신뢰하는 인증 기관이 발급한 유효한 인증서를 가진 사용자가 root를 얻을 수 있는 문제로 보도되었습니다.
10.4 (7월 6일): sftp와 scp의 경로 검증, GSSAPI 인증 전 서비스 거부, 최소 인증 지연 미적용 등이 수정되었습니다.
10.5 (8월 11일): ssh-agent 잠금 우회와 클라이언트의 메모리 해제 후 사용 문제가 수정되었습니다.
10.6 (10월 6일): sftp 서버 경로 검증, 압축으로 인한 부채널 우려(LZ77 비활성화), 명령줄 사용자 이름 검증 등이 수정되었습니다.

일상적으로 SSH를 쓰는 서버라면 배포판이 제공하는 OpenSSH 업데이트를 정기적으로 받아야 합니다. 우분투와 데비안은 버전 번호를 올리지 않고 수정만 가져오는(백포트) 방식이라, ssh -V의 숫자만 보고 오래된 버전이라고 단정할 수 없습니다. 패키지 변경 기록에서 보안 수정 반영 여부를 확인하세요.

정리

이번 취약점은 SSH 전체가 아니라 musl 기반이고 PAM을 쓰지 않는 구성에 한정됩니다. 흔한 우분투, 데비안 서버는 해당하지 않습니다.
하지만 Alpine 기반 컨테이너, 임베디드 장비, 클라우드 이미지처럼 눈에 잘 띄지 않는 곳에 영향권 서버가 숨어 있을 수 있습니다.
확인 방법은 간단합니다. 비밀번호 로그인을 끄고 키로만 접속하게 하면 이 취약점뿐 아니라 무차별 대입 공격도 크게 줄어듭니다.
패치와 재시작, 그리고 침해 여부 점검까지 해야 끝입니다.

픽셀디자인 picell design은 워드프레스 서버의 SSH 접속 설정 점검, 키 기반 접속 전환, 보안 업데이트 운영을 대행하고 있습니다. 서버 점검이 필요하시면 문의해 주세요.

참고 자료

OpenSSH 릴리스 노트: https://www.openssh.org/releasenotes.html
Help Net Security, 공개 후 몇 시간 만에 악용: https://www.helpnetsecurity.com/2026/11/06/openssh-sshole-cve-2026-123158-exploitation/
OX Security 분석: https://www.ox.security/blog/openssh-authentication-bypass-cve-2026-123158/
Cycode 분석: https://cycode.com/blog/sshole-cve-2026-123158-openssh-alpine-linux-vulnerability/
데일리시큐 보도: https://www.dailysecu.com/news/articleView.html?idxno=209336 , https://www.dailysecu.com/news/articleView.html?idxno=209393
SecurityWeek, CVE-2026-35414: https://www.securityweek.com/openssh-flaw-allowing-full-root-shell-access-lurked-for-15-years/