SSH 키 인증 실패 디버깅: Permission denied 조치 과정

개요

얼마 전 Palworld 정식 출시 일정 발표를 보고 오랫동안 묵혀뒀던 데디케이트 서버를 다시 살려봤다. 당시엔 AI 지원도 부족했고 주먹구구식으로 구축했던 서버라, 이번엔 제대로 최적화해보려고 Claude Code와 Codex의 도움을 받기로 했다. 그런데 개발 서버에서 SSH 키를 발급하고 대상 서버에 등록했더니 계속 Permission denied가 발생했다. 설정은 이상이 없어 보이는데 뭐가 문제인지, 원인을 찾아가는 과정을 기록한다.

환경

클라이언트: Rocky Linux 9.8 (OpenSSH 9.9)
서버: Rocky Linux 9.8 (OpenSSH 9.9, 포트를 22가 아닌 다른 포트로 변경한 상태)
인증 방식: ed25519 공개키

1단계: 공개키 등록 — 잘못된 위치

처음에 서버에서 다음 명령어로 공개키를 등록했다.

mkdir -p ~/.ssh
echo "ssh-ed25519 AAAA..." >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

문제는 이 명령어를 root 계정에서 실행했다는 것이다. 접속하려는 계정은 stmcmd였는데, 키가 /root/.ssh/authorized_keys에 등록됐다.

sudo -i나 su - 상태에서 ~는 현재 유효 사용자(root)의 홈을 가리킨다. 반드시 대상 계정으로 전환 후 등록하거나 절대 경로를 사용해야 한다.

2단계: 올바른 계정에 등록했지만 여전히 실패

stmcmd 계정으로 전환 후 /home/stmcmd/.ssh/authorized_keys에 키를 다시 등록했다. 그런데도 Permission denied가 계속 발생했다.

stmcmd@192.168.0.31: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)

이 시점에서 체크한 항목들:

항목	결과
authorized_keys 파일 권한 (600)	✓
.ssh 디렉토리 권한 (700)	✓
SELinux 상태	Disabled ✓
PubkeyAuthentication 설정	기본값(yes) ✓
키 지문(fingerprint) 일치 여부	✓
파일 인코딩 (CRLF 여부)	✓

모든 항목이 정상이었다.

3단계: sshd DEBUG 로그로 원인 발견

/var/log/secure를 보면 Failed password만 찍히고 Failed publickey가 없었다. 이는 공개키 사전 검증(pre-check) 단계에서 조용히 거부되고 있다는 신호다.

sshd 로그 레벨을 올려서 상세 로그를 확인했다.

# /etc/ssh/sshd_config.d/10-debug.conf
LogLevel DEBUG3

systemctl restart sshd

다시 접속을 시도하자 핵심 로그가 찍혔다.

debug1: trying public key file /opt/stmcmd/.ssh/authorized_keys
debug1: Could not open user 'stmcmd' authorized keys
        '/opt/stmcmd/.ssh/authorized_keys': No such file or directory

원인 발견: sshd가 참조한 경로는 /home/stmcmd가 아니라 /opt/stmcmd였다.

4단계: 원인 분석

stmcmd 계정의 실제 홈 디렉토리가 /opt/stmcmd로 설정되어 있었다. /etc/passwd를 확인하면 각 계정의 홈 디렉토리를 알 수 있다.

grep stmcmd /etc/passwd
# stmcmd:x:996:993::/opt/stmcmd:/bin/bash

sshd의 AuthorizedKeysFile 설정은 기본값인 .ssh/authorized_keys(상대 경로)이며, 이는 계정의 홈 디렉토리 기준으로 해석된다. 홈이 /opt/stmcmd이므로 sshd는 /opt/stmcmd/.ssh/authorized_keys를 찾고 있었던 것이다.

우리가 등록한 /home/stmcmd/.ssh/authorized_keys는 sshd가 전혀 읽지 않는 위치였다.

해결

mkdir -p /opt/stmcmd/.ssh
echo "ssh-ed25519 AAAA..." > /opt/stmcmd/.ssh/authorized_keys
chmod 700 /opt/stmcmd/.ssh
chmod 600 /opt/stmcmd/.ssh/authorized_keys
chown -R stmcmd:stmcmd /opt/stmcmd/.ssh

이후 즉시 접속 성공.

핵심 요약

SSH 키 인증이 안 될 때 대부분은 권한 문제나 파일 경로 문제다. 이번 케이스처럼 홈 디렉토리가 관례(/home/<user>)와 다른 경우는 흔치 않아서 놓치기 쉽다.

디버깅 순서 체크리스트:

cat -A ~/.ssh/authorized_keys — CRLF 등 이상 문자 확인
ls -la ~ ~/.ssh/ — 권한 및 소유자 확인
grep stmcmd /etc/passwd — 실제 홈 디렉토리 확인
LogLevel DEBUG3 후 /var/log/secure — sshd가 어느 경로를 읽는지 확인
ssh-keygen -l -f authorized_keys — 키 지문 일치 여부 확인

3번을 먼저 확인했다면 훨씬 빨리 해결했을 것이다.

아무래도 오래전에 구성한 서버인 데다, 당시엔 인터넷 자료를 이것저것 주워가며 설정했던 터라 이런 세부 설정이 있었다는 것 자체를 기억하지 못했다.

앞으로는 이번 경험을 바탕으로 같은 실수를 반복하지 않도록 서버 구성 내용을 문서로 남겨두는 습관을 들여야겠다.