SSH 접속 시 invalid format, 범인은 CRLF?
인프라팀으로부터 전달받은 새로운 서버의 키페어(Keypair) 파일을 이용해 맥북에서 SSH 접속을 시도했는데 난데없이 invalid format 에러가
발생한 적이 있으신가요?
분명 파일은 문제없이 다운로드되었는데 형식이 잘못되었다니 당황스러울 수 있습니다. 이 문제의 원인은 아주 사소하지만 중요한 '줄 바꿈 문자'의 차이인 CRLF 때문일 확룔이 높습니다. 이 에러가 발생하는 이유와 해결 방법, 그리고 그 뒤에 숨겨진 재미있는 타자기의 역사까지 알아볼게요.
에러가 왜 발생할까?
보통 인프라 팀이나 협업하는 동료가 Windows 환경을 사용하고, 나는 macOS를 사용할 때 이런 문제가 발생합니다.
- Windows: 줄 바꿈을 할 때 "CRLF (
\r\n)"를 사용합니다. - macOS/Linux: 줄 바꿈을 할 때 "LF (
\n)"를 사용합니다.
윈도우에서 생성된 키페어 파일은 줄 끝마다 눈에 보이지 않는 \r (Carriage Return) 문자가 포함되어 있습니다. Unix 계열인
맥에서 이 파일을 열면 줄 끝마다 ^M이라는 문자가 붙어있는 것을 볼 수 있어요. SSH 클라이언트는 이 형식을 이해하지 못해 invalid format
에러를 뱉는 것입니다.
참고로 CRLF는 2바이트, LF는 1바이트를 사용하므로 용량 측면에서도 LF가 더 효율적이라 보통 LF 사용을 권장합니다.
해결책: 맥에서 포맷 변환
가장 확실한 해결책은 모든 OS에서의 작업 환경을 LF로 통일하는 것이지만, 이미 받은 파일이 문제라면 아래 명령어로 간단히 수정할 수 있습니다. 터미널을 열고 키페어 파일이 있는 경로에서 다음 순서대로 명령어를 수행하세요.
# 1. 파일 수정 권한 부여
$ chmod 666 [키페어_파일명]
# 2. sed 명령어로 파일 내의 CR(\r) 문자를 모두 제거 (MacOS 기준)
$ sed -i '' 's/\r//g' [키페어_파일명]
# 3. 파일 끝에 개행 문자 추가
$ echo "" >> [키페어_파일명]
# 4. SSH 접속을 위해 키 파일 권한을 400으로 변경 (필수)
$ chmod 400 [키페어_파일명]
역사적 배경: 왜 이런 차이가 생겼을까?
"도대체 왜 통일하지 않고 서로 다른 방식을 쓰는거야?"라고 의문이 들 수도 있는데 이 CRLF의 유래는 컴퓨터가 발명되기도 전인 타자기 시대로 거슬러 올라갑니다.
이 용어는 타자기의 하드웨어 동작 방식에서 유래했어요.
- CR (
Carriage Return): 타자기의 캐리지(Carriage)를 오른쪽 끝에서 왼쪽 끝으로 휙 밀어버리는 동작입니다. 종이 위의 커서를 줄의 시작 부분으로 옮기는 것이에요. - LF (
Line Feed): 종이를 감싸고 있는 원통형 롤러인 플래튼(Platen)을 돌려 종이를 한 줄 위로 올리는 동작입니다. 커서를 다음 줄로 이동시키는 것이에요.
초기 컴퓨터 시스템은 텔레타이프(전신 타자기)의 이 개념을 그대로 가져왔습니다.
- Windows는 타자기의 물리적 동작을 모방하여 CR과 LF가 모두 필요하다고 판단해
\r\n을 사용하게 되었어요. - 반면, Unix/Linux는 효율성을 위해 LF(
\n) 하나만으로도 충분하다고 정의했습니다. - 참고로 옛날 Mac OS 9 이전 버전은 CR만 사용하기도 했다고 합니다.
이러한 하드웨어의 동작 방식이 현대의 디지털 환경까지 이어져 오늘날 우리가 겪는 호환성 문제의 원인이 되었어요.
백문이 불여일견
글로만 봐서는 타자기의 동작이 잘 상상되지 않을 수 있습니다. 아래 영상을 참고하시면 쉽게 이해되실 거에요.
CRLF는 단순한 관습이 아니라, 컴퓨터 역사의 유물과도 같은 개념이라고 생각되니 이제 invalid format 에러를 만났을 때
반가울 수 밖에 없겠죠?