Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
OpenSSH 10.6p2가 치명적인 취약점 우회 조치를 담아 출시되었으며, SSH 보안 설정의 중요성을 강조합니다. 본문은 비밀번호 인증(PasswordAuthentication=yes) 사용에 대한 위험성을 지적하고, 키 기반 인증을 사용하는 것이 가장 안전한 방법임을 강력히 권장합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기/etc/shadow의 비밀번호 필드가 *인 사용자로 SSH 접속을 시도하면서 아무 비밀번호나 입력하면 되는 수준의 취약점 아닌가 싶음. 취약한 설정의 시스템이 실제로 존재한다면, 단순한 SSH 봇에 수년 전에 뚫리지 않았다는 게 놀라움.
전통적인 UNIX 계열 C API가 얼마나 형편없는지 새삼 떠오름. 해당 musl 코드도 황당하지만, 구현해야 하는 crypt() API 자체가 끔찍함. https://man.archlinux.org/man/crypt.3.en을 보면 이 함수를 올바르게 호출할 방법이 없음. sshd의 수정도 사실상 반환값이 너무 짧으면 성공이 아니라 오류로 간주하는 방식임. PAM도 별로지만 이건 더 심함.
내가 잘못 이해했을 수도 있지만, 다른 스레드에서 u/tonnydourado가 짚었듯 발동 조건이 모두 충족돼야 함. https://news.ycombinator.com/item?id=50378228#50380029.
처음에는 비밀번호 로그인이 불가능해야 하는 SSH 계정이 256~1024자짜리 비밀번호를 아무거나 받아들인다고 강조하지만, 실제로는 musl로 컴파일한 sshd이며 PAM을 사용하지 않고, 비밀번호 로그인이 활성화되어 있고, 비밀번호 해시가 *인 계정과 유효한 비밀번호를 가진 별도의 계정이 각각 있어야 함. 하나라도 빠지면 안전하므로, 그렇게 크게 떠들 정도의 문제는 아닌 듯함.
AI 에이전트가 같은 버그를 때로는 몇 시간 만에 재발견하기 때문에, 긴 공개 유예 기간은 주로 공격자에게 유리하다고 보고 문제를 안 지 하루 만에 서둘러 릴리스한다는 방침임. 앞으로 이런 방식이 표준이 될 가능성이 높아 보임. 다만 당분간 몇 달은 격랑을 겪게 될 듯함.
Alpine 기본 설치에서도 실제로 공격이 통하나? /etc/shadow에 * 대신 !를 쓰는 것 같고, 직접 공격을 시도해도 작동하지 않는 듯함.
musl에만 해당하며, 빠른 대응은 PasswordAuthentication=no 로 설정하는 것임. 평소에도 권장할 만한 설정임.
낯선 곳에서 깨어났는데 지갑, 열쇠, 스마트폰, 태블릿, 노트북까지 모두 사라졌다고 해보자. 인터넷에 연결된 노트북 하나만으로 디지털 생활에 복귀하려면 어떻게 해야 하나? 어딘가에는 비밀번호 인증이 켜져 있어야 하지 않나?
비밀번호 인증이 기본으로 켜져 있다는 게 늘 불편했고, 실제로 쓰는 사람이 있다는 것도 놀라웠음. 키를 쓰는 것보다 번거롭기도 함. SSH 키 인증은 비밀번호 관리자에 대응하는 방식처럼 느껴짐.
서버를 WireGuard 가상 네트워크에 넣고, 그 안에서만 SSH 접속을 허용하는 것도 권장함. SSH를 인터넷에 공개할 필요가 없음.
서버에 접속하는 기기의 홈 디렉터리가 암호화되어 있고 SSH 개인 키도 보호되는 경우에만 좋은 조언이라고 봄.
요즘도 PasswordAuthentication=yes 를 쓰는 사람이 있나?
대부분의 클라우드 제공업체가 기본으로 그렇게 설정하지 않나? 일부는 키를 쓰도록 명시적으로 배포해야 했고, 그래도 비밀번호 인증이 켜져 있어 따로 꺼야 하는 경우가 잦았음.
우리 고객 중에는 SFTP로 데이터를 보내는 은행과 보험사가 있으며, 규모도 다양하고 규제도 받는 곳들임. 키 기반 인증을 강력히 권장해도 무시하고 비밀번호 인증을 요청하는 비율을 보면 놀랄 것임.
대부분 시스템의 기본 설정임. 직접 끄지 않아도 됐던 때가 기억나지 않을 정도임.
안타깝게도 서버에서 Cockpit을 운영하려면 비밀번호 인증을 활성화해야 함.
AuthenticationMethods "publickey,password" 를 쓰는 경우임. 먼저 키를 제시한 다음 비밀번호도 입력해야 함.
올해 초 Alpine에 이 건과는 별개의 보안 문제를 신고했음. https://gitlab.alpinelinux.org/alpine/aports/-/work_items/16....
안전한 소프트웨어를 다루고 있다는 느낌을 받지 못했음. 복잡한 문제를 다루면서도 업계에서 수년 전에 정립된 기본조차 터무니없이 놓치는 것 같았음.
이 단순한 권한 설정을 똑같이 잘못한 다른 배포판은 Ubuntu뿐이었음. 최근 TCP 취약점 수정까지 지연되는 것을 보면, 다가올 보안 환경에서 이 배포판들을 신뢰하기 어렵다는 생각이 더 강해짐.
PasswordAuthentication=yes 자체가 취약점이라고 봄.
musl의 설계 결정들이 하나같이 끔찍해 보임. 앞으로는 피해야겠음.
실수는 인간의 숙명이라, 안타깝지만 완전히 피할 수는 없음.
OpenBSD는 기본 설치에 OpenSSH가 포함되고 활성화되니, 이제 유명한 기본 설치의 원격 취약점은 오랜 세월 동안 단 두 개뿐이라는 문구를 수정해야 하나? https://www.openbsd.org/.
OpenBSD는 영향받지 않으니 뭔가 제대로 하고 있는 셈임. 다만 glibc를 쓰는 Linux나 PAM을 쓰는 Linux도 영향받지 않으며, 원격 취약점은 musl을 쓰는 Linux에만 해당함.
OpenBSD는 musl에 링크된 OpenSSH를 기본 제공하지 않으므로, 아직 수정할 필요가 없음.