기술자료

적용 환경

가장 먼저 확인할 항목

Permission denied (publickey)는 네트워크 연결 자체가 실패했다는 뜻이 아닙니다. 일반적으로 TCP 연결과 SSH 프로토콜 협상은 완료되었지만 서버가 클라이언트가 제시한 공개키 인증을 받아들이지 않았을 때 표시됩니다.

먼저 실제로 어떤 사용자명, 서버 주소, 포트와 개인키를 사용해 접속하는지 명시하여 재현합니다.

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 [email protected]

SSH 포트를 변경한 서버라면 실제 포트를 지정합니다.

ssh -p 2222 -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 [email protected]

이 명령에서도 같은 오류가 발생하면 다음 항목을 순서대로 확인합니다.

1. 접속 사용자명이 실제 공개키를 등록한 계정과 같은지 확인
2. 클라이언트가 의도한 개인키를 실제로 제시하는지 확인
3. 서버의 authorized_keys에 대응하는 공개키가 존재하는지 확인
4. 홈 디렉터리와 .ssh 권한·소유권 확인
5. 서버의 유효 OpenSSH 설정과 Match 규칙 확인
6. 서버의 실시간 SSH 인증 로그 확인

클라이언트에서 ssh -vvv로 확인

가장 먼저 클라이언트가 어떤 키를 찾고 어떤 키를 서버에 제시하는지 확인합니다. OpenSSH 클라이언트의 -vvv 옵션은 인증 과정을 자세히 표시합니다.

ssh -vvv -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 [email protected]

출력에서 다음과 같은 흐름을 확인합니다.

• identity file: 지정한 개인키 파일을 찾았는지 확인
• Offering public key: 클라이언트가 해당 키를 서버에 실제로 제시했는지 확인
• 키를 제시한 직후 인증이 계속 다음 단계로 넘어가는지 확인
• 마지막에 서버가 허용하는 인증 방식 목록에 publickey가 포함되는지 확인

개인키 파일이 실제로 존재하는지도 확인합니다.

ls -l ~/.ssh/id_ed25519
ssh-keygen -lf ~/.ssh/id_ed25519

Linux나 macOS에서 개인키의 권한이 너무 넓으면 OpenSSH가 해당 키 사용을 거부할 수 있습니다. 일반 개인키 파일은 소유자만 읽고 쓸 수 있도록 설정합니다.

chmod 600 ~/.ssh/id_ed25519

접속 사용자명 확인

SSH 공개키는 서버 전체에 공통으로 등록되는 것이 아니라 사용자 계정별로 관리됩니다. 예를 들어 admin_user의 authorized_keys에 키를 등록했다면 [email protected]으로 접속해서는 해당 키가 자동으로 사용되지 않습니다.

서버 콘솔이나 아직 접속 가능한 다른 관리자 세션에서 대상 계정과 홈 디렉터리를 확인합니다.

getent passwd admin_user
id admin_user

출력에서 계정이 실제로 존재하고 홈 디렉터리가 어디인지 확인합니다. 일반적으로 /home/admin_user이지만 클라우드 이미지, 시스템 계정 또는 수동 생성 계정에서는 경로가 다를 수 있습니다.

클라이언트에서 사용하는 사용자명이 SSH 설정 파일에 의해 다른 값으로 바뀌는지도 확인합니다.

ssh -G 203.0.113.10 | grep -E '^(user|hostname|port|identityfile) '

여기서 표시되는 user, port, identityfile이 의도한 값과 다른 경우 ~/.ssh/config 또는 시스템 전역 SSH 클라이언트 설정을 확인하십시오.

개인키와 서버 공개키 일치 확인

클라이언트가 개인키를 정상적으로 제시하더라도 서버에 대응하는 공개키가 등록되어 있지 않으면 인증은 실패합니다. 가장 확실한 방법은 키 지문을 비교하는 것입니다.

클라이언트에서 공개키 지문을 확인합니다.

ssh-keygen -lf ~/.ssh/id_ed25519.pub

공개키 파일이 없고 개인키만 있다면 개인키에서 공개키를 출력해 지문을 확인할 수 있습니다.

ssh-keygen -y -f ~/.ssh/id_ed25519 > /tmp/id_ed25519.pub
ssh-keygen -lf /tmp/id_ed25519.pub
rm /tmp/id_ed25519.pub

서버에서는 대상 사용자의 authorized_keys에 들어 있는 키 지문을 확인합니다.

sudo -u admin_user ssh-keygen -lf /home/admin_user/.ssh/authorized_keys

클라이언트의 지문과 서버에 등록된 지문 중 하나가 일치해야 합니다. 일치하지 않는다면 올바른 공개키를 다시 등록합니다.

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

비밀번호 인증이 이미 비활성화되어 ssh-copy-id를 사용할 수 없다면 서버 콘솔 또는 정상 접속 가능한 다른 관리자 계정으로 접속한 뒤 공개키 한 줄을 대상 계정의 authorized_keys에 추가해야 합니다.

authorized_keys 권한과 소유권 확인

OpenSSH는 기본적으로 StrictModes yes를 사용하여 로그인 전에 사용자의 홈 디렉터리와 SSH 관련 파일의 소유권 및 쓰기 권한을 검사합니다. 홈 디렉터리나 .ssh, authorized_keys가 다른 사용자에게 쓰기 가능하면 공개키를 정상 등록했더라도 거부될 수 있습니다.

경로 구성요소별 소유자와 권한을 확인합니다.

namei -l /home/admin_user/.ssh/authorized_keys
stat -c '%U:%G %a %n' \
  /home/admin_user \
  /home/admin_user/.ssh \
  /home/admin_user/.ssh/authorized_keys

일반적인 전용 사용자 홈 환경에서는 다음과 같이 소유권과 권한을 교정할 수 있습니다.

sudo chown -R admin_user:admin_user /home/admin_user/.ssh
sudo chmod go-w /home/admin_user
sudo chmod 700 /home/admin_user/.ssh
sudo chmod 600 /home/admin_user/.ssh/authorized_keys

chmod go-w /home/admin_user는 기존의 읽기·실행 권한은 유지하면서 그룹과 다른 사용자의 쓰기 권한만 제거합니다. 공유 홈 디렉터리나 특수한 ACL을 사용하는 서버에서는 기존 권한 정책을 먼저 확인해야 합니다.

OpenSSH 서버 설정 확인

Ubuntu 22.04에서는 /etc/ssh/sshd_config뿐 아니라 /etc/ssh/sshd_config.d/*.conf 설정 조각도 읽습니다. Ubuntu 기본 구성은 이 디렉터리를 메인 설정 파일 상단에서 포함하며, OpenSSH는 대부분의 지시어에서 먼저 읽은 값을 사용하므로 메인 파일만 확인하면 실제 적용값을 놓칠 수 있습니다.

먼저 설정 파일에서 공개키 인증과 접근 제어 관련 지시어를 찾습니다.

sudo grep -RniE '^[[:space:]]*(Include|PubkeyAuthentication|AuthorizedKeysFile|AuthenticationMethods|AllowUsers|DenyUsers|AllowGroups|DenyGroups|Match)[[:space:]]' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

기본 유효 설정을 확인합니다.

sudo sshd -T | grep -E '^(pubkeyauthentication|authorizedkeysfile|authenticationmethods|permitrootlogin) '

일반적인 기본 환경에서는 pubkeyauthentication yes가 적용되어야 하며, AuthorizedKeysFile은 사용자의 홈 디렉터리를 기준으로 .ssh/authorized_keys를 포함합니다.

PubkeyAuthentication이 no인 경우

공개키 인증이 명시적으로 비활성화되어 있다면 설정 조각을 사용해 활성화할 수 있습니다.

sudo tee /etc/ssh/sshd_config.d/00-publickey-fix.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
EOF

sudo sshd -t

문법 검사에서 오류가 없을 때만 SSH 서비스를 다시 시작합니다.

sudo systemctl restart ssh.service
sudo systemctl is-active ssh.service
sudo sshd -T | grep '^pubkeyauthentication '

AllowUsers, DenyUsers, Match 규칙 확인

키와 권한이 모두 정상인데 특정 사용자나 특정 IP에서만 실패한다면 AllowUsers, DenyUsers, 그룹 제한 또는 Match 블록이 영향을 줄 수 있습니다. 특히 Match User, Match Address 아래에서 PubkeyAuthentication이나 AuthenticationMethods가 별도로 정의되어 있지 않은지 확인하십시오.

특정 사용자와 접속 원본 주소에 적용되는 최종 설정을 확인하려면 -C 조건을 사용할 수 있습니다.

sudo sshd -T -C user=admin_user,addr=198.51.100.20 | \
  grep -E '^(pubkeyauthentication|authorizedkeysfile|authenticationmethods|permitrootlogin) '

예시 클라이언트 IP 198.51.100.20은 실제 접속 원본 IP로 변경해야 합니다.

서버 로그에서 거부 원인 확인

클라이언트의 ssh -vvv만으로 원인이 분명하지 않다면 서버에서 SSH 로그를 실시간으로 확인하는 것이 가장 빠릅니다. 기존 관리 세션 또는 콘솔에서 다음 명령을 실행한 채 다른 터미널에서 접속을 재시도합니다.

sudo journalctl -fu ssh.service

최근 부팅 이후 SSH 로그 전체를 확인하려면 다음 명령을 사용합니다.

sudo journalctl -u ssh.service -b --no-pager

Ubuntu 22.04에서 rsyslog가 동작하는 환경이라면 인증 기록이 /var/log/auth.log에도 저장될 수 있습니다.

sudo tail -f /var/log/auth.log

로그에서 특히 확인할 내용은 다음과 같습니다.

• 사용자 홈 또는 authorized_keys의 소유권·모드 문제
• 대상 사용자가 존재하지 않거나 접근 정책에서 제외된 경우
• 클라이언트가 제시한 키를 서버가 찾지 못한 경우
• 공개키 알고리즘 또는 서명 알고리즘이 서버 정책에 맞지 않는 경우
• AuthenticationMethods에 의해 공개키 외의 추가 인증이 요구되는 경우

추가로 확인할 원인

authorized_keys가 다른 경로로 설정된 경우

관리자가 AuthorizedKeysFile을 변경한 서버라면 ~/.ssh/authorized_keys에 키를 넣어도 사용되지 않을 수 있습니다. 유효 경로를 확인합니다.

sudo sshd -T | grep '^authorizedkeysfile '

출력된 경로가 기본값과 다르면 실제 경로의 파일 존재 여부, 소유권과 권한을 확인하십시오.

오래된 RSA 클라이언트와 알고리즘 호환성

Ubuntu 22.04의 OpenSSH는 RSA 키 자체를 사용할 수 있지만 기본 허용 목록은 RSA SHA-2 서명 알고리즘을 포함하고 오래된 ssh-rsa SHA-1 서명 방식은 기본 목록에 포함하지 않습니다. 매우 오래된 SSH 클라이언트가 RSA SHA-2를 지원하지 않는 경우 키가 맞아도 호환성 문제가 발생할 수 있습니다.

클라이언트가 지원하는 공개키 알고리즘을 확인합니다.

ssh -Q PubkeyAcceptedAlgorithms

호환성 문제라면 서버에서 오래된 SHA-1 알고리즘을 무작정 다시 허용하기보다 클라이언트를 업데이트하거나 Ed25519 또는 현대적인 RSA SHA-2 서명을 지원하는 환경으로 전환하는 것이 안전합니다.

authorized_keys의 from= 제한

authorized_keys의 키 앞에 from="..." 옵션이 설정되어 있으면 지정한 호스트 또는 IP 범위에서만 해당 키를 사용할 수 있습니다. 현재 접속 IP가 조건과 맞는지 확인합니다.

sudo sed -n '1,120p' /home/admin_user/.ssh/authorized_keys

키 앞에 제한 옵션이 있다면 의미를 확인한 뒤 수정하십시오. 운영 중인 다른 자동화 작업이나 접속 정책에 필요한 제한일 수 있으므로 원인을 확인하지 않고 삭제하지 않는 것이 좋습니다.

계정 만료와 접근 정책

공개키가 정상이어도 계정 자체가 만료되었거나 시스템 접근 정책에서 차단되면 로그인이 거부될 수 있습니다. 계정 상태와 만료일을 확인합니다.

sudo passwd -S admin_user
sudo chage -l admin_user

단순히 비밀번호가 잠겨 있다는 사실만으로 공개키 로그인이 반드시 차단되는 것은 아닙니다. 계정 만료, 접근 제어 또는 PAM 정책이 실제 로그에서 어떻게 처리되는지를 함께 확인하십시오.

해결 여부 확인

수정 후에는 다른 인증 방법에 우연히 성공한 것이 아니라 의도한 개인키로 공개키 인증이 성공하는지 확인합니다.

ssh -vv -o IdentitiesOnly=yes \
  -o PreferredAuthentications=publickey \
  -i ~/.ssh/id_ed25519 \
  [email protected]

로그인에 성공하면 서버에서 실제 사용자와 접속 정보를 확인합니다.

whoami
printf '%s\n' "$SSH_CONNECTION"

서버 로그에서도 해당 접속이 공개키 방식으로 승인되었는지 확인합니다.

sudo journalctl -u ssh.service -n 50 --no-pager

오류 유형별 원인과 해결 방법

변경 사항 원상복구

이 문서에서 /etc/ssh/sshd_config.d/00-publickey-fix.conf를 새로 만들었다면 문제가 해결된 뒤 기존 정책으로 되돌릴 필요가 있는 경우 파일을 제거할 수 있습니다.

sudo rm /etc/ssh/sshd_config.d/00-publickey-fix.conf
sudo sshd -t
sudo systemctl restart ssh.service
sudo sshd -T | grep '^pubkeyauthentication '

권한을 변경하기 전에 기존 값을 기록해 두었다면 chmod와 chown으로 원래 정책에 맞게 복원합니다. 단, 다시 다른 사용자에게 쓰기 가능한 상태로 되돌리면 OpenSSH의 StrictModes 검사 때문에 공개키 인증이 재차 실패할 수 있습니다.

관련 지구 IDC 기술자료

• Ubuntu 22.04에서 SSH 공개키 인증을 설정하는 방법
• Ubuntu 22.04에서 Fail2ban으로 SSH 무차별 대입 공격을 차단하는 방법
• SSH key 로그인 방법

공식 참고자료

자주 묻는 질문

Permission denied (publickey)는 방화벽 문제인가요?

일반적으로 아닙니다. 이 메시지가 보인다는 것은 대개 SSH 서버와 통신하여 인증 단계까지 도달했다는 의미입니다. 방화벽이나 포트가 완전히 차단되어 있다면 보통 연결 시간 초과 또는 연결 거부와 같은 다른 증상이 나타납니다.

authorized_keys 권한은 반드시 600이어야 하나요?

600은 가장 일반적이고 안전한 설정입니다. 핵심은 인증 대상 사용자 외의 계정이 파일을 쓰거나 변경할 수 없어야 한다는 점입니다. .ssh 디렉터리도 다른 사용자가 수정할 수 없도록 관리해야 합니다.

공개키가 맞는데도 root 로그인만 실패할 수 있나요?

가능합니다. PermitRootLogin, AllowUsers, DenyUsers 또는 Match 설정에 따라 root 계정만 별도로 제한될 수 있습니다. sshd -T와 서버 로그에서 실제 정책을 확인하십시오.

PuTTY의 .ppk 파일을 OpenSSH의 -i 옵션에 바로 사용할 수 있나요?

PuTTY 전용 형식의 키라면 일반 OpenSSH 개인키와 형식이 다를 수 있습니다. PuTTY에서 접속할 때는 PuTTY가 지원하는 키 형식을 사용하고, OpenSSH 클라이언트에서 사용하려면 PuTTYgen 등을 통해 OpenSSH 형식으로 변환한 뒤 사용해야 합니다.

키를 다시 생성하는 것이 가장 빠른 해결 방법인가요?

반드시 그렇지는 않습니다. 키를 다시 만들어도 사용자명, authorized_keys 경로, 권한 또는 sshd 접근 정책이 잘못되어 있다면 같은 오류가 반복됩니다. 먼저 ssh -vvv와 서버 로그로 실제 실패 지점을 확인한 뒤 필요한 부분만 수정하는 것이 좋습니다.