인밴드 신호 전달이 또 문제를 일으킴. /etc/passwd의 ‘비밀번호 없음’이나 crypt의 ‘비밀번호 해싱 오류’에 *를 특수값으로 쓰지 말았어야 함. 특히 문자열 처리에서 이런 오용이 더 많이 발견될 것 같음. null도 괜찮고, 예외나 그에 준하는 방식은 더 낫고, Result 같은 방식이 가장 나음.
musl 개발자들이 핵심 암호화 함수에 편의성을 이유로 여러 변경을 넣었다는 사실이 아쉬움. 적어도 이런 결함을 잡아낼 수준의 감사를 거치지는 않은 셈이라, 내 기준으로는 신뢰가 조금 떨어짐.
각각의 결정만 보면 나름 타당함. 수많은 프로그램이 원격으로도 유발될 수 있는 충돌의 영향을 받지 않게 하려는 것, 타이밍 공격을 막으려는 것, 계정에 비밀번호를 설정하지 않을 수 있게 하려는 것 모두 이해할 만함.
다만 각 결정은 ‘다른 쪽에서 거부할 테니 *가 일치할 일은 없다’는 전제에 의존함.
AI가 보통 사람은 발견하거나 악용하기도 어려운 복잡한 버그를 찾는 데만 너무 집착하는 것 같음. 그런 버그 하나당, 설명을 듣고 나면 어떻게 이걸 그냥 넘겼나 싶은 실수 유발 설계나 단순한 버그가 대여섯 개는 있을 수 있음.
LLM이 가장 많이 찾아낼 유형도 이런 쪽이라고 봄. 다만 지금의 AI 보안 감사는 오탐이 너무 많아, 사소한 트집인지 실제로 인간의 어처구니없는 실수를 잡아낸 것인지 구별하기 어려움.
조금이라니? musl은 우스운 수준이고 이번 일도 또 하나의 증거임. 수많은 경고 신호가 있었는데도 왜 운영 환경에서 사용하는지 모르겠고, 계속 썼다면 스스로 책임져야 함.
공식 Alpine Docker 이미지에서 재현한 사람이 있는지 궁금함. root의 비밀번호 로그인을 활성화했지만, shadow 항목의 기본 비밀번호 값인 !에서는 256자 넘는 비밀번호로도 로그인되지 않음. passwd -l도 !를 설정하며, 수동으로 *로 바꿔도 안 됨.
내가 뭘 잘못한 걸까? 환경은 OpenSSH_10.3p1, OpenSSL 3.5.9 29 Sep 2026, PRETTY_NAME="Alpine Linux v3.24"임.
내 Firecracker VM에서도 재현하지 못함. 어차피 외부에 공개된 VM은 아님.
내가 이해하기로는 기본 구성에서는 작동하지 않음. musl-c와 OpenSSH를 사용하고 PAM은 없어야 함.
Alpine 3.20.10과 OpenSSH_9.7p1에서도 잘 안 됨. /etc/shadow의 마지막 두 항목은 test:*:20762:0:99999:7:::와 q3k:$6$snip.GgDQNTrqqX.A0:20762:0:99999:7:::임. test@로 SSH 접속하면서 틀린 비밀번호를 한 번 넣고 긴 비밀번호를 넣어도 안 됨. sshd_config에는 UsePAM no와 PasswordAuthentication yes를 설정한 상태임.
먼저 일반적인 길이의 틀린 비밀번호로 한 번 실패해 봤는지?
OpenWRT나 AsusWRT 등은 기본적으로 OpenSSH 대신 Dropbear를 쓰는 것으로 아는데, 그렇다면 영향을 받지 않는 것 아닌가?
사이트는 잘 만들었지만 별 감흥은 없음.
나는 재미있게 봤지만, *sshole이라는 이름과 sshhole.com이라는 도메인의 불일치가 거슬림. 이런 걸 찾아내고 글까지 쓸 만큼 집요하면서 h 개수는 왜 통일하지 않은 건지? 인간이든 LLM이든 둘이 섞인 존재든 상관없이 궁금함.
LLM 출력물에 대한 피로감 때문일까?
PAM 없이 musl을 사용하면서 비밀번호 인증을 켠 OpenSSH sshd를 실제로 운영하는 곳이 어디인지 궁금함. 가상의 Alpine 구성은 가능하겠지만, 정말 그런 식으로 돌리는 곳이 있는지?
공개 SFTP 서버가 해당할 수 있음. 예전에 익명 공개 SFTP에 빈 비밀번호를 허용한 적이 있고, 내 가상·물리 서버는 모두 Alpine Linux만 사용함. shadow 패키지(PAM)는 기본 설치되지 않았고, 설치 과정에서 명시적으로 선택해야 했음.
시험해 볼 수 있도록 하나 열어두겠음. sftp [email protected]로 접속하면 됨. 방화벽은 없으니 마음껏 시도해 봐도 됨. 설정은 PasswordAuthentication yes, PermitEmptyPasswords yes임.
Docker 컨테이너가 상당수 해당하지 않을까? 이런 조건으로 sshd를 돌리는 비율은 작겠지만, 전 세계 Alpine 컨테이너 수를 곱하면 절대적인 규모는 커짐. 조금만 찾아봐도 다운로드 수가 수백만인 공개 컨테이너를 찾을 수 있음.
요즘의 에이전트 샌드박스가 해당할 것 같음.
일반적인 퍼저 중 무엇이라면 10년 전에도 이걸 찾았을지 궁금함. 정말 256자를 넘는 아무 비밀번호나 통한다면, musl Linux의 OpenSSH를 아무도 퍼징하지 않았다는 뜻임.
솔직히 2026년에 어떤 플랫폼이든 PasswordAuthentication=no 없이 SSH를 운영하는 사람에게는 동정심이 전혀 들지 않음. 문제가 생길 수도 있는 게 아니라, 언제 생기느냐의 차이일 뿐임.
SSH를 엉뚱한 포트로 옮겼다고 해도 봇은 금세 찾아냄. 직장에서 실험해 보니 두 시간도 안 돼 여러 봇이 발견함. 그래서 SSH 설정을 강화해야 하고, 운영체제도 보안이 강화된 것을 쓰는 편이 좋음.
이 버그는 비밀번호 인증을 꺼도 작동함.
로컬 도구 호출을 지원하는 AI 시스템 상당수는 사용자를 대신해 SSH를 실행할 수 있으므로, LLM 주변에 둘러놓은 보여주기식 보안 장치를 우회할 수 있음.