SSH 접속이 막혔는데, 원인은 내 Mac에 있었다
최근 Mac에서 Ubuntu 서버에 SSH로 접속하다가 이런 오류를 만났다.
Permissions 0644 for '/Users/apple/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/Users/apple/.ssh/id_rsa": bad permissions해결은 한 줄이었다. 서버가 아니라 개인키가 있는 내 Mac의 터미널에서 실행했다.
chmod 600 ~/.ssh/id_rsa다시 접속하니 문제가 해결됐다. 그런데 궁금해졌다. 왜 600일까? 644는 왜 안 될까?
오류를 정확히 읽으면, Mac의 SSH 클라이언트가 “다른 사용자도 접근할 수 있는 개인키라서 사용하지 않겠다”고 판단한 것이다. 이 키가 무시되면서 해당 키를 이용한 인증이 실패했다. 다른 인증 수단이 있다면 접속 자체는 이어질 수도 있다.
파일 권한은 ‘누가 무엇을 할 수 있는가’다
Unix는 여러 사용자가 한 컴퓨터를 함께 사용하는 환경을 고려한 운영체제다. 모든 사용자가 모든 파일을 읽거나 수정할 수 있다면, 개인 자료를 지키기도 어렵고 다른 사람의 작업을 실수로 망가뜨리기도 쉽다.
그래서 파일마다 접근 대상을 세 부류로 나눈다.
| 구분 | 의미 |
|---|---|
| owner | 파일 소유자 |
| group | 파일에 지정된 그룹에 속한 사용자 |
| others | 소유자도 아니고 해당 그룹에도 속하지 않는 사용자 |
여기서 ‘다른 사용자’는 인터넷 사용자를 뜻하는 것이 아니라, 기본적으로 그 컴퓨터의 다른 사용자 계정을 말한다. 프로그램도 실행 중인 계정의 권한으로 파일에 접근한다.
각 대상에는 읽기·쓰기·실행 권한을 부여할 수 있다.
| 권한 | 문자 | 일반 파일에서의 의미 |
|---|---|---|
| read | r | 내용을 읽기 |
| write | w | 내용을 수정하기 |
| execute | x | 프로그램이나 스크립트로 실행하기 |
권한이 없으면 해당 자리에 하이픈(-)을 표시한다. 기본 권한 모델에서는 소유자라면 owner, 그 외에 그룹 구성원이면 group, 나머지라면 others의 권한이 적용된다. 세 묶음을 모두 합치는 방식은 아니다. Apple의 Unix 권한 설명
ls -l 결과 읽기
ls -l ~/.ssh/id_rsa결과가 다음과 같다고 해보자. 가운데 일부 정보는 생략했다.
-rw------- 1 user staff ... id_rsa맨 앞의 -는 일반 파일이라는 뜻이다. 디렉터리라면 d가 표시된다. 그다음 아홉 글자를 세 개씩 나누면 된다.
- | rw- | --- | ---
종류 owner group others즉, 소유자는 읽고 쓸 수 있지만 실행할 수는 없다. 그룹과 다른 사용자에게는 권한이 없다. 뒤의 1은 하드 링크 수, user는 소유자, staff는 파일에 지정된 그룹이다. 그 뒤에는 보통 크기, 수정 시각, 파일 이름이 나온다.
chmod 600, 755, 644는 어떻게 읽을까?
chmod는 파일이나 디렉터리의 권한을 바꾸는 명령이다. 숫자 방식에서는 owner → group → others 순서로 한 자리씩 지정한다.
| 권한 | 숫자 | 비트 표현 |
|---|---|---|
| r | 4 | 100 |
| w | 2 | 010 |
| x | 1 | 001 |
왜 더해서 표현할까? 각 권한을 켜고 끄는 스위치 하나로 생각하면 쉽다. 세 스위치를 이진수 세 자리로 표현하고, 그 값을 0~7의 숫자 하나로 줄여 쓰는 것이다. 4, 2, 1은 서로 다른 비트라서 어떤 권한을 골라도 합계로 조합을 구분할 수 있다.
읽기 + 쓰기 = 4 + 2 = 6 = rw-
읽기 + 실행 = 4 + 1 = 5 = r-x
읽기 + 쓰기 + 실행 = 4 + 2 + 1 = 7 = rwx
권한 없음 = 0 = ---따라서 이 숫자들은 십진수 육백 같은 크기를 뜻하는 것이 아니라, 8진수로 표현한 권한 비트다. 아래는 파일 종류 문자를 제외한 아홉 자리 권한이다.
| 숫자 | 문자 표현 | 의미 |
|---|---|---|
| 600 | rw------- | 소유자만 읽기·쓰기 |
| 755 | rwxr-xr-x | 소유자는 모두, 나머지는 읽기·실행 |
| 644 | rw-r--r-- | 소유자는 읽기·쓰기, 나머지는 읽기 |
처음 오류의 0644에서 앞의 0은 특수 권한이 없는 일반적인 모드 표현이며, 여기서는 644와 같은 기본 권한이다. 644에서 600으로 바꾸면 그룹과 others의 읽기 권한이 사라진다. Apple의 chmod와 숫자 모드 설명
SSH는 왜 개인키 권한에 민감할까?
개인키(private key)는 비밀번호처럼 나임을 증명하는 데 쓰이는 민감한 정보다. 다른 사용자가 복사해 갈 수 있다면 나를 사칭하는 데 악용할 위험이 있다.
그래서 OpenSSH는 다른 사용자가 접근할 수 있는 개인키 파일을 무시한다. 644는 일반 문서에는 쓸 수 있어도, 개인키에는 그룹과 others의 읽기 권한이 너무 넓다. 600은 소유자에게 필요한 읽기·쓰기만 남기는 흔한 설정이다. 읽기만 허용한 400도 가능하므로, 반드시 숫자 600만 정답인 것은 아니다.
개인키에 암호문구(passphrase)를 걸어 보호할 수도 있지만, 그것이 파일 권한을 넓혀도 된다는 뜻은 아니다. 그리고 chmod는 접근 권한을 바꾸는 명령이지, 파일을 암호화하는 명령은 아니다. OpenSSH 개인키 파일 권한 안내
공개키 인증: 비밀을 보내지 않고 보유 사실을 증명한다
이번에 사용한 RSA 키를 기준으로 파일을 정리하면 다음과 같다. 다른 키 종류를 쓰면 파일 이름은 달라질 수 있다.
클라이언트(Mac)
~/.ssh/id_rsa → 개인키: 내 컴퓨터에서 보호
~/.ssh/id_rsa.pub → 공개키: 서버에 등록할 수 있는 정보
서버(Ubuntu의 접속 대상 계정)
~/.ssh/authorized_keys → 접속을 허용할 공개키 목록물결표(~)는 현재 계정의 홈 디렉터리를 뜻한다. Mac에서의 홈과 서버에서의 홈은 서로 다른 위치다.
키를 만들면 서로 대응하는 개인키와 공개키가 생긴다. 개인키로부터 공개키를 얻을 수 있지만, 공개키만으로 개인키를 알아내는 것은 현실적으로 어렵도록 설계되어 있다.
등록과 인증을 나누면 흐름이 더 분명해진다.
[등록]
클라이언트 개인키
↓ 대응하는 공개키
클라이언트 공개키(.pub)
↓ 공개키 내용을 등록
서버의 authorized_keys
[접속할 때]
클라이언트: 개인키로 이번 연결의 인증 데이터에 서명
↓ 공개키와 서명 전달
서버: 허용된 공개키인지 확인하고 그 공개키로 서명 검증
↓
대응하는 개인키를 보유했는지 확인개인키 자체는 서버로 전달되지 않는다. 서버가 받는 서명은 개인키를 그대로 보여주는 대신 보유 사실을 증명하는 값이다. 이번 연결에 묶인 데이터를 서명하므로 이전 접속에서 얻은 서명을 그대로 재사용하는 것도 막는다. 공개키가 등록되어 있고 서명 검증과 서버의 다른 인증 조건까지 충족하면 접속이 허용된다. SSH 인증 프로토콜 RFC 4252, 7절
authorized_keys는 서버 계정의 ‘공개키 허용 목록’이다
쉽게 말하면 “이 서버에 접속을 허용할 공개키 목록”이다. 더 정확히는 이 서버의 해당 사용자 계정으로 인증할 때 허용하는 공개키 목록이다.
공개키는 보통 한 줄에 하나씩 들어간다. 내 노트북과 다른 작업용 컴퓨터의 공개키를 함께 등록할 수도 있다. 공개키를 안다고 접속할 수 있는 것은 아니다. 대응하는 개인키로 유효한 서명을 만들어야 한다.
이 파일에서 특히 중요한 것은 다른 사용자가 마음대로 수정하지 못하게 하는 것이다. 누군가 자기 공개키를 추가할 수 있다면 접속 허용 목록을 바꾸는 셈이기 때문이다.
그래서 600을 권장한다. 다만 개인키와 달리 공개키 목록은 남이 읽을 수 있다는 이유만으로 반드시 거부되는 것은 아니다. 기본 설정에서는 소유권과 쓰기 권한 등이 안전하면 644도 허용될 수 있다. OpenSSH authorized_keys 안내
서버의 StrictModes는 기본값이 yes이며, 로그인 전에 관련 파일과 홈 디렉터리의 소유권·권한을 확인한다. 앞에서 만난 클라이언트의 개인키 검사와는 별개의 검사다. OpenSSH StrictModes 설명
Mac에서도 Ubuntu와 같은 명령을 쓰는 이유
macOS는 Darwin/BSD 기반의 Unix 계열 운영체제이고, Ubuntu는 Linux 배포판이다. 기반이 완전히 같지는 않지만 전통적인 Unix 권한 모델을 공유하기 때문에 다음 개념을 거의 동일하게 사용할 수 있다.
chmod → 파일·디렉터리 권한 변경
chown → 소유자 변경
rwx → 읽기·쓰기·실행 권한 표시
~/.ssh → 사용자별 SSH 설정과 키를 두는 일반적인 위치즉, Mac에서 익힌 권한 개념이 Ubuntu 서버에서도 그대로 도움이 된다. 다만 명령의 세부 옵션과 ACL 같은 추가 접근 제어는 차이가 있을 수 있다. 이 글은 기본 rwx 권한을 중심으로 이해하면 된다. Apple의 BSD 권한과 소유권 설명
실무에서는 이렇게 적용한다
| 대상 | 흔히 쓰는 권한 | 의도 |
|---|---|---|
| SSH 디렉터리 | 700 | 소유자만 목록 확인·항목 관리·접근 |
| 개인키 파일 | 600 | 소유자만 읽기·쓰기 |
| 서버의 공개키 허용 목록 | 600 | 소유자만 읽기·쓰기 |
개인키가 있는 Mac에서는 다음과 같이 설정한다.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa서버에서는 접속을 허용할 계정으로, 이미 존재하는 공개키 목록의 권한을 설정한다.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys여기서 디렉터리에만 x가 있는 이유도 알아두면 좋다. 디렉터리의 r은 파일 이름 목록을 읽는 권한, w는 항목을 생성·삭제하는 권한, x는 그 디렉터리를 통과해 내부 항목에 접근하는 권한이다. 실제 생성·삭제에는 보통 w와 x가 함께 필요하다. 디렉터리의 x는 “폴더를 프로그램처럼 실행한다”는 뜻이 아니다.
설정 후에는 이렇게 확인할 수 있다.
# 클라이언트에서
ls -ld ~/.ssh
ls -l ~/.ssh/id_rsa
# 서버의 해당 계정에서
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys권한 숫자뿐 아니라 소유자도 함께 보자. 600이어도 엉뚱한 계정이 소유하면 내가 읽지 못할 수 있다. 이 설정은 일반 사용자 사이의 접근을 제한하는 것이며, 관리자 권한까지 막는 장치는 아니다.
이번 오류로 이해한 것
예전에는 chmod 600이라는 명령을 ‘SSH 오류가 나면 입력하는 명령’ 정도로 외웠다.
하지만 알고 보니 그 뒤에는 Unix의 사용자 권한 모델과 SSH 공개키 인증 구조가 연결되어 있었다. 운영체제는 개인키 파일을 누가 읽을 수 있는지 제한하고, SSH는 그 개인키를 서버에 보내지 않은 채 보유 사실을 증명한다.
이제 권한 오류를 보면 숫자부터 외우기보다 먼저 물어볼 것 같다.
“이 파일은 누가 읽고, 누가 쓰고, 누가 실행할 수 있어야 하지?”
이번에 얻은 것은 접속을 복구하는 한 줄뿐만 아니라, 그 한 줄이 필요한 이유였다.
댓글