SSH 공개키 접속 Permission denied: authorized_keys와 파일 권한 확인

공개키를 서버에 등록했다고 생각했는데 SSH 접속은 계속 Permission denied (publickey)로 끝난다. 다시 키를 만들기 전에 어느 사용자로 접속하는지, 그 사용자의 어느 파일에 공개키가 들어 있는지, 파일 권한이 지나치게 열려 있지 않은지를 따로 확인하자. 키 생성과 등록, 실제 인증은 서로 다른 단계다.

공개키는 접속할 사용자의 authorized_keys에 있어야 한다

도식의 공개키는 서버 전체가 아니라 접속 대상 계정의 홈 디렉터리로 들어간다. 키가 맞아도 ~/.ssh와 authorized_keys의 소유자·권한이 허용 범위를 벗어나면 sshd가 읽기를 거부할 수 있다.

ssh-keygen은 개인키와 공개키의 쌍을 만든다. 개인키는 접속하는 쪽에서 안전하게 보관하고, 공개키만 접속 대상 계정의 ~/.ssh/authorized_keys에 등록한다. ssh-copy-id는 공개키를 해당 사용자 계정에 등록하는 데 쓰는 도구다.

ssh-copy-id learner@example.invalid
ssh learner@example.invalid

주소는 설명용이다. 첫 명령이 성공했다고 두 번째 명령도 반드시 성공하는 것은 아니다. 다른 사용자로 접속했다면 다른 홈 디렉터리의 authorized_keys를 보게 된다. 명령에 쓴 사용자 이름, 대상 호스트, 실제 등록 계정이 같은지 확인한다. 접속 문제를 고치려고 개인키 내용을 채팅이나 이슈에 붙여 넣어서는 안 된다.

파일 권한은 어디를 확인할까?

서버에서 해당 사용자 계정으로 파일이 있는지와 권한을 확인한다. 다음 명령은 교육 자료가 다루는 공개키 등록 파일의 기본 점검 예다.

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

chmod 600은 소유자에게 읽기·쓰기를 허용하고 다른 사용자에게는 권한을 주지 않는다. 그러나 명령을 무턱대고 실행하기 전에 현재 로그인한 계정이 실제 접속 대상인지 확인해야 한다. 다른 계정의 홈에서 권한을 바꿔도 원래 문제는 남는다. .ssh 디렉터리와 파일의 소유자, 상위 경로의 권한도 함께 확인한다. 파일 하나의 숫자만 맞췄다고 모든 SSH 인증 문제가 해결되는 것은 아니다.

그래도 거부되면 무엇을 비교할까?

클라이언트가 실제로 어느 키를 제시하는지, 서버가 기대하는 공개키와 짝인지 확인한다. 여러 개인키가 있는 환경이라면 의도한 키를 선택했는지 살펴보고, 서버의 SSH 인증 로그에서 공개키 거부 이유가 있는지도 점검한다. 다만 로그나 진단 출력에는 사용자 이름·호스트 정보가 포함될 수 있으니 공유 전 가린다.

문제 해결을 위해 공개키 인증을 끄고 비밀번호 로그인을 무작정 열거나, .ssh와 키 파일을 모든 사용자에게 읽히게 만드는 방식은 피한다. 접속이 끊기면 복구할 경로가 있는지 먼저 확인한 뒤 한 항목씩 수정한다. 서비스 운영 중이라면 접근 정책과 접속 기록도 함께 고려해야 한다.

핵심 요약: 사용자·등록 위치·권한을 순서대로 본다

Permission denied (publickey)라면 키를 곧바로 다시 만들지 말고 접속 사용자, 그 사용자의 authorized_keys, 파일·디렉터리 소유권과 권한을 확인한다. 개인키는 공유하지 않고, 권한을 넓혀서 임시로 통과시키는 식의 해결은 피한다.