읽는 데 8분
SSHole 막으려고 비밀번호 로그인을 껐는데, 예외 계정은 아직 켜져 있었어요
PasswordAuthentication no를 넣고 설정을 확인하자 no가 나왔어요. 그런데 같은 파일을 특정 사용자 조건으로 다시 읽히니 yes였어요. OpenSSH 10.2p1에서 작은 설정 파일로 확인한 결과예요. 아래쪽의 Match User 예외가 비밀번호 로그인을 다시 허용하고 있었죠.
이 차이가 지금 Alpine 서버를 운영하는 사람에게 중요해요. 비밀번호를 몰라도 일부 계정에 들어갈 수 있는 SSHole(CVE-2026-123158)이 공개됐고, GreyNoise는 11월 7일부터 자신들의 관측용 시스템에서 실제 침입을 확인했어요. Alpine의 공식 대응은 업데이트 후 SSH 접속을 받는 서버 프로그램인 sshd를 재시작하는 거예요. 당장 업데이트하기 어렵다면 비밀번호 로그인을 꺼야 하는데, 접속할 계정에 실제로 적용되는 값을 확인해야 해요.
Alpine 이미지라고 전부 위험한 건 아니에요
문제는 musl이라는 C 표준 라이브러리와, PAM이라는 로그인 검증 모듈을 쓰지 않는 OpenSSH의 조합에 있어요. Alpine 기본 openssh-server가 이 조합이에요. 같은 Alpine이라도 PAM 패키지에 UsePAM yes를 쓰면 이번 경로에 해당하지 않아요.
공식 권고가 제시하는 조건은 여기에 더해져요. 비밀번호 로그인이 허용되고, 저장된 비밀번호 칸이 *인 계정과 해시가 $5$ 또는 $6$로 시작하는 다른 로컬 계정이 함께 있어야 해요. *는 비밀번호를 설정하지 않은 키 전용 계정 등에서 쓰는 값이에요.
해시는 비밀번호를 검증하려고 변환해 저장한 값이고, $5$와 $6$는 그 해시 방식을 나타내는 접두사예요. crypt(5) 매뉴얼에 따르면 각각 SHA-2 기반의 sha256crypt와 sha512crypt를 뜻해요.
Alpine 기반 앱 컨테이너라도 안에서 sshd를 실행하지 않으면 이번 취약점의 대상이 아니에요.
Tiny-cloud 이미지에는 특히 주의할 부분이 있어요. Alpine은 3.18.11부터 3.24.3까지의 공식 이미지가 첫 부팅 때는 안전하지만, 관리자가 콘솔 비밀번호를 설정하는 등 $6$ 해시가 생기면 기본 alpine 계정이 공격 가능해질 수 있다고 설명해요. 이 계정은 비밀번호 없이 doas로 관리자 권한을 얻을 수 있어요. root의 직접 로그인만 막았다고 끝나지 않는 이유예요.
고친 패키지와 실행 중인 프로그램을 따로 봐요
OpenSSH는 11월 5일 10.6p2를 공개했어요. Alpine은 기존 버전에도 수정 사항을 옮겨 넣었기 때문에, 버전 앞자리만 보고 10.6보다 작으니 미수정이라고 판단하면 안 돼요.
| Alpine 브랜치 | 공식 권고의 수정 openssh 패키지 |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
더 오래된 브랜치의 수정 버전도 공식 권고에 있어요. 다만 Alpine 3.21은 11월 1일 정기 지원이 끝났으니, 이번 패치가 나왔다는 것과 앞으로 지원받는다는 것은 별개예요.
Alpine은 관리자 권한으로 apk upgrade -U -a를 실행한 뒤 rc-service sshd restart로 재시작하도록 안내해요. 패키지만 바꿔도 이미 실행 중인 데몬은 교체되지 않거든요. 이 업데이트 명령은 설치된 패키지 전반을 업그레이드하므로 운영 중인 다른 서비스의 변경도 함께 살펴야 해요.
no가 나왔는데도 yes였던 작은 설정
패치를 바로 적용할 수 없다면 Match 예외까지 살펴 PasswordAuthentication no로 바꾸고, 설정 검사 후 sshd를 재시작해야 해요. Alpine 권고의 적용 명령은 sshd -t && rc-service sshd restart예요. sshd -T는 파일의 유효 값을 보여 줄 뿐 실행 중인 서버를 바꾸지는 않아요. 여기서 전역 설정만 확인하는 것과 실제 접속 조건까지 넣어 확인하는 것이 갈려요.
다음 파일을 sshd_config로 저장했어요. 운영 서버 설정을 고친 것이 아니라, 이 세 줄의 해석만 시험했어요.
PasswordAuthentication no
Match User nobody
PasswordAuthentication yes
그 파일을 지정해 sshd -T -f ./sshd_config로 읽으면 passwordauthentication no가 나와요. 여기에 -C user=nobody,addr=192.0.2.10,host=client.test를 더하자 yes로 바뀌었어요. 같은 조건에서 사용자만 root로 바꾸면 다시 no였고요. 192.0.2.10과 client.test는 설정 판정에 넣은 예시 값이며, 그 주소로 접속하지 않아요.
공식 매뉴얼에서 -T는 유효 설정을 출력하는 모드이고, -C는 사용자·접속 주소 같은 조건을 넣어 해당 Match 규칙을 적용하는 옵션이에요. 운영 서버에서는 실제로 허용하는 사용자와 접속 경로를 넣어 확인해야 해요. 한 사용자에서 no가 나왔다고 모든 계정의 예외가 사라진 것은 아니에요.
이 시험은 설정 해석을 확인한 것이고, 취약점 공격을 재현한 결과는 아니에요. Alpine에서는 설정 파일을 추가하는 방식에도 버전 차이가 있어요. 공식 권고에 따르면 기본 설정이 sshd_config.d를 읽는 것은 3.19부터라서, 오래된 버전에 파일만 추가하면 반영되지 않을 수 있어요.
패치와 침입 확인도 다른 일이에요
GreyNoise의 공개 관측에는 로그인 뒤 SSH 공개키 파일이나 시작 서비스를 바꾼 기록이 있어요. 패치는 취약한 진입 경로를 고치는 일이므로, 이미 바뀐 파일까지 되돌려 주지는 않아요.
Alpine은 /var/log/messages에서 비밀번호가 없어야 할 계정에 Accepted password for가 남았는지 확인하고, doas 사용과 새 계정·파일·공개키도 검토하라고 안내해요. 침입 가능성을 배제할 수 없으면 침해된 시스템으로 취급하라는 권고예요.
제 생각엔 이번 점검은 세 칸으로 나누면 덜 헷갈려요. 수정된 패키지인지, 실행 중인 sshd를 바꿨는지, 임시 대응이라면 계정별 유효 설정이 no인지. 그리고 인터넷에 노출돼 있었다면 침입 흔적 확인은 따로 남겨 두는 거예요.
확인한 범위
- 기준일: 2026-11-10
- 직접 한 것: Linux의 OpenSSH 10.2p1에서 전역 금지와 사용자별 허용이 함께 있는 설정을 만들어, 전역·nobody·root 조건의 유효 값을 비교했어요. Alpine 수정 패키지 표, OpenSSH 릴리스, 공식 매뉴얼과 GreyNoise 관측을 대조했어요.
- 읽은 것: Alpine 보안 권고, OpenSSH 10.6p2 릴리스와 sshd 매뉴얼, GreyNoise 사건 관측 페이지, Red Hat CVE 설명.
- 확인하지 못한 것: Alpine 취약 서버의 공격 재현이나 실제 서버의 침해 여부는 확인하지 않았어요. 시험은 설정 해석에 한정돼요.
출처
GreyNoise
