압축 사전 끄고 달러 기호 막았다: 보안을 위해 호환성을 깬 OpenSSH 10.6 심층 분석
OpenSSH 10.6이 LZ77 압축과 커맨드라인 특수문자 입력을 전격 차단했습니다. AI 취약점 발굴 시대에 대응하는 인프라 보안 변경점과 실무 점검 가이드를 정리합니다.
발행일: 2026.10.08
에디터 총평 (The Verdict)
공식 사이트 확인OpenSSH 10.6이 LZ77 압축과 커맨드라인 특수문자 입력을 전격 차단했습니다. AI 취약점 발굴 시대에 대응하는 인프라 보안 변경점과 실무 점검 가이드를 정리합니다.
데이터 누출을 막기 위해 20년 묵은 편의 기능을 스스로 끊어낸 OpenSSH 10.6
전 세계 리눅스 서버와 클라우드 인프라의 관문 역할을 하는 OpenSSH 개발팀이 2026년 10월 6일 공개한 10.6 업데이트에서 파격적인 결단을 내렸다. 기존 스크립트와 사용자 워크플로가 깨질 위험을 알면서도, 보안을 위해 핵심 동작 방식 두 가지를 의도적으로 중단한 것이다.
이번 조치의 첫 번째 대상은 SSH 터널 내부에서 패킷 크기를 줄여주던 LZ77 딕셔너리 압축 기능이다. 하나의 암호화 통로 안에 여러 가상 채널(셸 터미널, 포트 포워딩, 프록시 등)을 한 번에 묶어 쓸 때, 채널끼리 단어 사전을 공유하면서 암호문 크기 변화만으로 내부 평문 비밀번호나 토큰을 역추적할 수 있는 취약점이 드러났기 때문이다. 두 번째 대상은 명령줄(CLI) 환경에서 계정 이름에 달러($)와 역슬래시(\) 기호를 직접 입력하는 기능이다. CI/CD 자동화 파이프라인이나 관리 스크립트에서 외부 입력을 받아 실행할 때, 이 기호들이 셸 명령어 실행(ProxyCommand, Match exec 등)으로 이어지는 공격을 막기 위함이다.
더 주목할 지점은 이번 업데이트가 공개된 배경이다. 루르 대학교 보훔(Ruhr University Bochum) 연구진이 이번 압축 부채널 취약점 증명 코드(PoC)를 구축하고, 앤스로픽 연구팀이 추가 버그를 찾아내는 과정에서 최신 AI 모델(Claude Code 등)이 결정적인 역할을 했다. OpenSSH 팀은 “AI 도구를 활용해 취약점을 찾는 사례가 급증하고 있으며, 오픈소스 팀에 제보하지 않는 공격자들도 똑같이 이 취약점들을 발견할 수 있다”고 경고했다. 이에 따라 수개월씩 묶어서 패치하던 기존 정기 배포 주기를 버리고, 버그가 확인되는 즉시 수시로 업데이트를 쏟아내는 긴급 방어 체제로 전환하기로 선언했다.
OpenSSH 10.6 핵심 보안 변경 구조
취약점 발견부터 프로토콜 차단 및 실무 대응 흐름
공유 압축 사전과 셸 인젝션 위험 노출
멀티플렉싱 채널의 암호문 길이 측정으로 평문이 유출되고 명령줄 특수문자로 셸 탈취 가능
AI 분석 도구 발전으로 취약점 재발굴 급증
공격자가 보고되지 않은 보안 결함을 독립적으로 찾아내 공격 코드를 제작할 확률 상승
OpenSSH 10.6 기능 비활성화 및 배포 주기 단축
LZ77 사전 인코더 전면 제거, 특수문자 차단, 그리고 수시 배포 체제로 전환
276번의 추측으로 비밀번호가 털리던 압축 결함: 버전 간 변경 팩트 비교
이번에 문제가 된 압축 취약점은 과거 웹 암호화(HTTPS)를 뒤흔들었던 CRIME 및 BREACH 공격과 같은 원리다. 압축 알고리즘(Deflate)은 앞서 나온 단어를 기억하는 사전(LZ77)과 자주 쓰는 값에 짧은 비트를 부여하는 방식(허프만 코딩)을 함께 쓴다. 만약 공격자가 SSH 세션의 한쪽 채널에 자신이 만든 글자를 집어넣고, 비밀 토큰이 오가는 다른 채널과 압축 사전을 공유하게 되면 문제가 생긴다. 공격자가 던진 글자가 실제 비밀값과 일치하는 순간 전체 압축 결과물의 길이가 미세하게 줄어들기 때문에, 네트워크 패킷 길이만 엿보고 있어도 원래 평문을 한 글자씩 알아맞힐 수 있다.
연구진의 시험 결과, 26개 알파벳으로 구성된 8글자 비밀값을 찾아내는 데 잡음이 적은 환경에서는 평균 276번의 시도만으로 평문 전체가 복원되었다. 네트워크 잡음이 섞인 브라우저 연계 환경에서도 약 27,600번의 시도면 복원이 가능했다. OpenSSH 10.6은 이 위험을 뿌리뽑기 위해 패킷 크기를 줄여주던 LZ77 딕셔너리 인코더를 완전히 비활성화했다. 허프만 코딩은 여전히 작동하지만 전송 대역폭 절감 효율은 이전보다 떨어지게 된다.
| 점검 항목 | OpenSSH 10.5 이전 버전 | OpenSSH 10.6 (신규 적용) | 인프라 운영 영향 |
|---|---|---|---|
| 전송 압축 방식 | LZ77 딕셔너리 + 허프만 코딩 결합 | 허프만 코딩만 유지 (LZ77 완전 비활성화) | 전송 레벨 압축률 하락, 대용량 텍스트 전송 시 대역폭 소모 소폭 증가 |
| 압축 부채널 평문 공격 | 다중 채널 공유 시 평문 복원 위험 노출 | 압축 사전 공유 원천 차단으로 방어 완료 | 별도 설정 없이도 크로스 채널 데이터 탈취 차단 |
| 명령줄 사용자명 입력 | $, \ 등 특수문자 전달 허용 | 명령줄 계정명 내 $, \ 입력 즉시 차단 | 배포 스크립트 내 변수 파싱 오류 발생 가능 |
| 설정 파일(ssh_config) 예외 | User 지시어로 자유롭게 지정 | ssh_config 내 User 항목은 기존처럼 허용 | 정당한 계정은 설정 파일 매핑 방식으로 우회 필요 |
| 양자 내성 서명 알고리즘 | ssh-mldsa44-ed25519@openssh.com (실험용) | ssh-mldsa44-ed25519 (공식 표준 승격) | 이전 실험용 키를 생성해 쓰던 환경은 키 재발급 필수 |
| 약한 암호화 감지 (서버) | 기본 비활성화 (클라이언트만 일부 제공) | WarnWeakCrypto 데몬 기본값 켜짐 | 양자 내성이 없는 키 교환 협상 시 로그 기록 |
| 보안 패치 릴리스 주기 | 분기별 정기 통합 배포 위주 | 취약점 확인 시 수시 긴급 배포 체제 | 서버 관리팀의 주기적 패치 반영 빈도 증가 |
기업 실무 환경과 자동화 파이프라인을 흔드는 3가지 직접적 파급력
네트워크 대역폭 비용과 애플리케이션 압축 전가
OpenSSH는 기본 설정에서 압축 옵션(Compression)이 꺼져 있지만, 지점 간 전용선 비용을 아끼거나 해외 리전 간에 방대한 로그를 rsync로 전송하던 엔지니어링 팀은 관행적으로 -C 옵션을 켜두는 경우가 많았다. LZ77이 꺼지면서 반복되는 텍스트 패턴을 긴 단위로 압축하는 능력이 상실되었다.
동일한 양의 JSON 로그나 비구조화 텍스트 파일을 전송할 때 네트워크 통신량이 약 15–30%가량 덜 줄어들게 된다. 결과적으로 클라우드 간 데이터 전송(Data Transfer Out) 비용이 늘어날 수 있다. OpenSSH 유지보수팀은 “전송 계층(SSH) 압축에 의존하지 말고, 데이터를 보내기 전 애플리케이션 계층(gzip, zstd 등)에서 먼저 묶어 전송하는 방식이 훨씬 빠르고 안전하다”고 명시했다.
명령줄 자동화 및 CI/CD 배포 스크립트 중단
수많은 기업이 사내 배포 도구나 젠킨스, 깃허브 액션 등에서 ssh "$USER_VARIABLE@target-server" 형태의 스크립트를 사용한다. 만약 외부 인증 시스템(Active Directory, LDAP)이나 사내 SSO 연동 과정에서 도메인 구분자 역슬래시(CORP\john)를 계정명에 포함하거나, 템플릿 환경변수가 제대로 치환되지 않아 $USER 리터럴이 그대로 전달되면 OpenSSH 10.6 클라이언트는 즉시 연결을 거부하고 에러를 뿜어낸다.
이 기능은 ProxyCommand나 Match exec 지시어가 셸 환경에서 실행될 때 명령어가 엉뚱하게 해석되어 서버가 해킹당하는 참사를 막기 위해 들어갔다. 하지만 현장에서는 원격 배포 자동화 파이프라인이 하루아침에 멈춰 서는 운영 중단 사태로 이어질 수 있으므로 스크립트 전수 조사가 불가피하다.
짧아진 배포 주기로 인한 인프라 운영 관리 부담 증가
OpenSSH는 통상 긴 호흡을 두고 안정성 검증을 거친 뒤 새 버전을 내놓았다. 하지만 AI 기반 취약점 탐지 도구가 보편화되면서 보안 연구원뿐 아니라 외부 공격자도 제로데이 결함을 찾아내는 속도가 비약적으로 빨라졌다.
OpenSSH 개발팀이 패치가 나오는 대로 즉시 배포하겠다고 공언함에 따라, 시스템 관리자들은 이제 ‘연 1–2회 정기 OS 패치’ 방식에 안주할 수 없게 되었다. 새로운 OpenSSH 버전이 출시될 때마다 패키지 호환성을 검증하고 무중단 재배포를 수행하는 인프라 파이프라인의 민첩성이 시험대에 올랐다.
대역폭 손실과 스크립트 충돌을 막아내는 3단계 실무 완충 방안
이번 변경 사항으로 인해 파이프라인이 깨지거나 불필요한 대역폭 요금이 늘어나는 현상을 막으려면 인프라 전반의 데이터 이동 방식을 손봐야 한다.
OpenSSH 10.6 업그레이드 전후 실무 득실 대조
보안 강화로 얻는 이점과 인프라 현장에서 감수해야 할 변경 작업
확보되는 강력한 보안 이점
- ✓ 멀티플렉싱 세션 내 평문 패스워드 탈취 경로 원천 차단
- ✓ 셸 메타문자를 이용한 원격 명령 삽입(Injection) 차단
- ✓ 포스트 퀀텀(양자 내성) 표준 암호화 기본 체계 안착
현장 엔지니어가 감수할 작업 비용
- • LZ77 부재로 인한 SSH 레벨 전송 압축 효율 15–30% 하락
- • 특수문자가 포함된 CI/CD 및 AD 계정 스크립트 수정 필요
- • 잦은 보안 릴리스에 맞춘 자동화 패치 파이프라인 점검
첫째, 대용량 데이터를 정기적으로 동기화하던 작업은 전송 파이프라인 앞단에 전문 압축 엔진을 배치해야 한다. SSH의 -C 플래그를 끄고, 스트리밍 단계에서 Datadog 같은 모니터링 에이전트로 트래픽 증가 폭을 계측하면서 zstd나 pigz 파이프라인을 거쳐 넘기도록 설정을 변경한다. 이렇게 하면 SSH 레이어의 압축 사전 누출 위험 없이도 CPU 자원을 덜 쓰면서 훨씬 높은 압축률을 달성할 수 있다.
둘째, 계정명에 역슬래시나 특수문자가 들어가는 레거시 엔터프라이즈 환경은 커맨드라인 인라인 전달을 즉시 중단해야 한다. 배포 에이전트가 ssh CORP\deploy@server를 직접 호출하지 않도록 막고, ~/.ssh/config 파일에 호스트별 User CORP\deploy 블록을 선언하여 매핑하는 방식으로 전환해야 한다. OpenSSH 10.6은 설정 파일 내의 User 지시문에 대해서는 이전과 동일하게 특수문자 사용을 허용하므로 배포 프로세스를 깨뜨리지 않고 보안 규정을 준수할 수 있다.
셋째, 하이브리드 양자 내성 암호 알고리즘(ssh-mldsa44-ed25519) 도입에 대비해야 한다. 기존 10.5 버전 이하에서 실험적으로 제공하던 접미사(@openssh.com)가 붙은 키는 10.6에서 인식되지 않으므로, 양자 암호 테스트를 진행하던 조직은 새 표준 명칭에 맞추어 키를 재발급하고 WarnWeakCrypto 경고 로그를 사전에 필터링해 두어야 한다.
도입 적합 대상 판정: 우리 팀은 언제 올려야 하는가
이번 OpenSSH 10.6 업데이트는 모든 서버에 맹목적으로 동시에 밀어넣기보다, 현재 구축된 시스템의 구성 방식에 따라 순차적으로 적용하는 전략이 현명하다.
지금 즉시 도입해야 할 기업
- 다중 채널 포워딩과 프록시 터널을 상시 운영하는 환경: 단일 SSH 커넥션 위에서 관리 콘솔과 포트 포워딩, SOCKS 프록시를 동시에 띄워 사내망에 접근하는 엔지니어링 팀은 공격 대상이 될 확률이 매우 높으므로 즉시 10.6으로 올려야 한다.
- 클라우드 취약점 진단 점수가 핵심 컴플라이언스인 기업: SOC2, ISO27001 등 대외 규제 준수를 위해 제로데이 및 AI 발굴 취약점을 최소 시간 내에 완벽 방어해야 하는 금융·핀테크·헬스케어 인프라.
- 양자 내성 암호화 도입 로드맵을 선제적으로 밟고 있는 조직: 실험용 꼬리표를 떼고 정식 표준으로 승격된 ML-DSA 기반 하이브리드 키 서명을 사내 인프라 표준으로 채택하려는 엔터프라이즈 보안팀.
도입을 보류하고 스크립트부터 검증해야 할 기업
- 윈도우 액티브 디렉터리(AD) 도메인 계정으로 리눅스 서버에 접근하는 조직: 명령줄에서
DOMAIN\username형태를 그대로 파싱해 전달하는 자동화 스크립트나 Bastion 도구가 다수 존재하는 곳은 일괄 업데이트 시 전사 원격 접속이 차단될 수 있다. - 원격지 간 대용량 로그 백업을
ssh -C파이프라인에 의존하는 환경: 애플리케이션 계층 압축(zstd등)으로 전환하는 사전 작업 없이 패치부터 적용할 경우, 대역폭 처리 한계에 부딪혀 데이터 전송 지연이 발생할 수 있다. - 정기 유지보수 일정이 분기 단위로 경직되어 있는 운영 조직: OpenSSH 팀의 릴리스 주기 단축 방침에 맞춰 인프라를 빠르게 재검증할 수 있는 테스트 자동화 파이프라인이 갖춰지지 않았다면, 배포 절차 자동화부터 먼저 구축해야 한다.