기술 · 실용 가이드
SCP의 “Received message too long”? SSH를 바꾸기 전에 불필요한 바이트를 캡처하세요
이 숫자는 예상치 못한 텍스트의 첫 4바이트를 SFTP 패킷 길이로 오해한 값일 수 있습니다. 같은 계정과 경로로 재현해 시작 파일, 서브시스템, 제한적 호환성을 구분하세요.
이 오류는 파일 크기가 아니라 프로토콜 증상인 경우가 많습니다. 최신 scp는 기본적으로 SFTP를 사용하므로 전송 전 텍스트가 이진 길이로 해석될 수 있습니다.
같은 계정에서 바이트를 보존하고 출력 원인을 찾은 뒤 한 경계만 수정하고 전송과 대화형 로그인을 모두 검증하세요.
편집하기 전에 실패 경로를 정확히 재현하세요
클라이언트 오류 전체, 명령, 호스트 별칭, 사용자 이름, 포트, 점프 호스트, 인증 방식을 저장합니다. 같은 전송을 상세 로그로 실행하되 키와 토큰은 가립니다. 대화형 ssh 로그인이 성공해도 다른 명령 경로를 쓰는 SFTP 서브시스템이 깨끗하다는 뜻은 아닙니다.
같은 계정과 SSH 설정으로 ssh -T host /usr/bin/true 같은 비대화형 무작업 명령을 실행합니다. 정상 기준은 stdout이 비어 있는 것입니다. 프로토콜 시작 전에 보이는 배너, debug echo, 명령 누락 메시지, 시작 오류를 그대로 캡처하고 증거로 보존합니다.
숫자를 앞의 불필요한 4바이트 단서로 사용하세요
SFTP 패킷은 4바이트 길이로 시작합니다. 텍스트가 먼저 도착하면 클라이언트가 첫 네 글자를 거대한 십진 길이로 해석해 “Received message too long”에서 멈출 수 있습니다. 보고된 값을 16진수와 ASCII로 바꾸는 것은 단서일 뿐이며, 반드시 캡처한 출력과 대조해야 합니다.
첫 글자가 파일 이름, 배너, 오류의 일부처럼 보이면 그 출력을 만든 위치를 추적합니다. 이 가이드에서 확인한 macOS 사례는 값을 “.bas”로 해독한 뒤 .bashrc 출력임을 확인했습니다. 다른 값은 다른 원인을 가리킬 수 있으므로 편집 전에 실제 바이트를 보존합니다.
실제로 실행되는 시작 파일을 추적하세요
Bash에서는 sshd가 시작한 비대화형 경로가 ~/.bashrc를 읽는지, BASH_ENV가 다른 파일을 지정하는지, 시스템 profile이나 wrapper가 출력하는지 확인합니다. 다른 셸은 규칙이 다릅니다. 관리자 계정이 아니라 실제 전송 계정으로 검사합니다.
인사말, 상태 명령, 진단은 대화형 셸임을 확인한 분기 안으로 옮기거나 프로토콜을 손상시키지 않는 채널로 보냅니다. 시작 파일 맨 위의 무조건 return은 자동 작업에 필요한 환경 변수까지 건너뛸 수 있습니다. 변경 후 로그인과 비대화형 무출력 프로브를 모두 다시 검사합니다.
시작 출력과 서브시스템 누락을 분리하세요
무작업 경로가 조용한데도 SFTP가 실패하면 Subsystem sftp 설정, 계정 shell, chroot, forced command, 정책 로그를 검사합니다. internal-sftp는 외부 서버 프로그램과 일부 셸 시작 경로를 피할 수 있지만 sshd_config 변경은 서버 전체에 영향을 주므로 설정 검증과 안전한 롤백 경로가 필요합니다.
유일한 관리 세션에서 sshd를 무작정 재시작하지 않습니다. 설정을 검증하고 정책이 허용하면 두 번째 관리 세션을 유지한 채 같은 계정으로 테스트합니다. 사용자 지정 또는 제한 셸에는 전역 셸 교체가 아니라 명시적인 SFTP 설계가 필요할 수 있습니다.
레거시 SCP는 제한된 호환성 시험에만 쓰세요
최신 OpenSSH scp는 기본적으로 SFTP를 사용합니다. -O는 SFTP가 없는 서버나 특정 예전 경로·와일드카드 동작을 위해 레거시 SCP를 선택합니다. scp -O만 성공한다면 그 차이를 기록하되 서버가 올바르게 구성됐다는 증거로 보지는 않습니다.
-O를 알려진 장비, 계정, 경로에 대한 문서화된 예외로 제한하고 보편적인 영구 해결책으로 삼지 않습니다. 레거시 모드는 일부 동작에서 원격 shell을 실행하며 인용 규칙도 다릅니다. 서버를 관리한다면 지원되는 SFTP 서브시스템이나 시작 출력을 고칩니다.
전송과 로그인 경계를 모두 검증하세요
같은 계정과 경로로 원래 명령을 반복합니다. 종료 상태 0, 파일 크기, 가능하면 체크섬을 확인하고 비대화형 프로브 stdout에 예상치 못한 바이트가 없는지 검사합니다. 그 다음 대화형 로그인이 의도한 prompt와 환경을 계속 불러오는지도 확인합니다.
실제 출력 원인, 변경한 파일 또는 서브시스템, 사용한 프로토콜, 변경 이유를 기록합니다. 자동화에는 원격 무작업 명령이 바이트를 출력하면 실패하는 스모크 테스트를 추가할 수 있습니다. 그러면 재발 시 dotfile을 추측하는 대신 명확한 회귀로 처리할 수 있습니다.
