SSD Nodes Learn 🎉 VPS $5.50/월부터
가이드 Matt Connor작성자 Matt Connor · 업데이트됨 2026-08-13

SSH Permission denied (publickey) 해결 방법

Permission denied (publickey) 오류는 5가지 원인으로 나뉩니다. ssh -v 명령어를 사용하여 서버가 거부한 정확한 이유를 확인하고, 계정 잠금 없이 안전하게 인증 문제를 해결하는 방법을 단계별로 안내합니다.

Permission denied (publickey) 오류의 실제 의미

Permission denied (publickey)는 클라이언트가 하나 이상의 공개 키를 전송했으나 서버가 이를 모두 거부했음을 의미합니다. 네트워크는 정상이며 sshd도 실행 중입니다. 즉, 인증의 마지막 단계에서 거부가 발생한 것입니다. ssh -v 명령어를 사용하면 5가지 원인 중 무엇인지 정확히 알 수 있으므로, 추측으로 문제를 해결하려 해서는 안 됩니다.

괄호 안의 단어는 서버가 허용하고자 하는 인증 방식입니다. Permission denied (publickey)만 표시된다면 해당 서버에서 비밀번호 로그인이 비활성화되어 있어 대체할 비밀번호 인증 수단이 없다는 뜻입니다. Permission denied (publickey,password)은 비밀번호 인증이 제공되었으나 해당 인증마저 실패했음을 의미합니다.

이 메시지 하나가 5가지의 서로 다른 오류를 포괄하며, 의도적으로 모호하게 설계되었습니다. 만약 서버가 "사용자 없음"이나 "설치되지 않은 키"라고 구체적으로 응답한다면, 유효한 계정을 찾는 공격자에게 정보를 제공하는 꼴이 되기 때문입니다. 따라서 무작정 키를 교체하거나 설정 파일을 수정하지 마십시오. 명령어 하나를 실행하여 출력되는 세 줄의 내용을 읽으면, 5가지 가능한 원인을 하나로 좁힐 수 있습니다.

ssh -v를 먼저 실행하고 세 줄을 확인하십시오

실패한 명령어를 -v 플래그를 추가하여 다시 실행하십시오:

ssh -v deploy@203.0.113.10

정제되었으나 실제와 유사한 실행 결과는 다음과 같습니다:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

필요한 모든 정보는 세 줄에 담겨 있습니다.

Authenticating to 203.0.113.10:22 as 'deploy'은 실제로 사용될 사용자 이름입니다. 의도했던 이름이 아니라, 명령줄이나 ~/.ssh/config, 또는 로컬 로그인 이름으로부터 ssh가 도출해낸 이름입니다.

Authentications that can continue: publickey은 키를 시도하기 전에 서버가 보낸 허용된 인증 방식 목록입니다. 만약 첫 번째 목록에 publickey이 없다면, 서버에서 공개 키 로그인이 비활성화된 것이므로 어떤 키도 작동할 수 없습니다.

Offering public key: ...는 클라이언트가 실제로 전송한 각 키에 대한 한 줄의 정보이며, 키가 포함된 파일명과 SHA256 지문을 나타냅니다. Offering 줄이 없는 키는 서버로 전송된 적이 없는 것입니다.

이제 문제를 두 가지로 나누어 보십시오:

  • 예상한 키에 대한 Offering public key 줄이 없습니다. 서버가 키를 전혀 받지 못했으므로 문제는 로컬 머신에 있습니다.
  • 키가 제공되었으나 Authentications that can continue: publickey가 다시 돌아옵니다. 서버가 해당 키를 받았으나 거부했으므로 문제는 서버에 있습니다.

아래의 원인들은 발생 빈도가 높은 순서대로 나열되어 있습니다.

원인 1: 잘못된 사용자 이름으로 접속 시도

가장 흔한 원인이지만 가장 단순한 문제이기도 합니다. SSH 서버 데몬인 sshd는 계정이 존재하지 않는다는 사실을 알려주지 않습니다. 존재하지 않는 사용자 이름으로 접속을 시도해도 전체 교환 과정을 모두 수행한 뒤 마지막에 동일한 거부 메시지를 출력하는데, 이는 유효한 계정 이름을 노출하는 것이 공격자에게 도움을 줄 수 있기 때문입니다. 사용자 이름의 오타는 마치 키가 손상된 것처럼 보입니다.

다른 작업을 수행하기 전에 Authenticating to ... as 줄을 먼저 확인하십시오. 만약 서버 계정이 아닌 본인 노트북의 로그인 계정이 지정되어 있다면, 명령어에서 사용자 이름을 생략한 것입니다.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

기본 계정은 서비스 제공업체가 빌드한 이미지에 따라 다릅니다. 2026년 8월 기준으로 Ubuntu 클라우드 이미지는 보통 ubuntu 계정을 제공하며, Debian 이미지는 debian 또는 admin를, Rocky Linux와 AlmaLinux는 rocky 및 almalinux을 제공합니다. 많은 VPS 제공업체는 대신 사용자의 키를 root에 직접 설치합니다. 어떤 계정이 생성되었는지는 제공업체의 제어판에서 확인할 수 있습니다. 서버 외부에서 실행하는 명령어로는 이를 확인할 수 없습니다.

~/.ssh/config 내의 Host 블록 또한 사용자 이름을 설정하며, 이 설정은 로컬 로그인 이름보다 우선합니다.

Host vps-prod
  HostName 203.0.113.10
  User deploy

직접 계정을 생성한 후 해당 계정으로 로그인할 수 없다면, 키가 이미지의 기본 사용자에게만 설치되고 복사되지 않았을 가능성이 큽니다. 해당 단계는 새 VPS 설정 후 첫 10분 과정에 포함되어 있으며, 간과하기 쉽습니다.

원인 2: 전송하려는 키와 실제 전송되는 키가 일치하지 않음

기본적으로 ssh는 ssh-agent에 보관된 키와 ~/.ssh에 정의된 고정된 파일 이름들(id_ed25519, id_ecdsa, id_rsa 및 해당 이름의 하드웨어/DSA 변형)만 제공합니다. ~/.ssh/vps-prod으로 저장된 키는 명시적으로 지정하기 전까지 ssh가 인식하지 못하며, 이것이 상세 출력(verbose output)에서 해당 키에 대한 Offering public key 줄이 나타나지 않는 이유입니다.

파일 이름을 지정하고 에이전트 키가 우선권을 갖지 못하도록 설정하십시오.

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

에이전트가 키를 보유하고 있을 때 -i만 사용하는 것으로는 충분하지 않습니다. ssh는 여전히 에이전트의 키를 먼저 제공하고 지정된 파일은 마지막에 시도하기 때문입니다. 서버는 거부된 모든 키를 MaxAuthTries(기본값 6)에 포함하므로 이 점이 중요합니다. 에이전트가 7개의 키를 보유하고 있다면 올바른 키에 도달하기 전에 제한 횟수를 모두 소진하게 되며, 메시지는 다음과 같이 변경됩니다.

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

IdentitiesOnly=yes는 시도 대상을 전달한 파일로 제한합니다. ssh-add -l로 에이전트가 보유한 키 목록을 확인하고, 오래된 키가 쌓여 있다면 ssh-add -D으로 비우십시오. 그런 다음 다음 로그인 시 플래그를 기억할 필요가 없도록 설정을 기록해 두십시오.

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

클라이언트 측의 또 다른 함정이 있습니다. ssh는 로컬 머신의 다른 계정이 읽을 수 있는 개인 키 사용을 거부합니다. 경고를 출력한 뒤 해당 키를 무시하므로, 키가 제공되지 않아 서버는 이를 인식할 수 없습니다.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod로 이 문제를 해결할 수 있습니다. USB 메모리나 Windows 공유 폴더를 통해 키를 이동할 때 권한 모드가 손실되는 경우가 흔합니다. 키의 저장 위치와 명명 규칙은 SSH 키 관리 기초에서 다룹니다.

원인 3: 공개 키가 authorized_keys에 도달하지 않음

ssh -v 명령으로 키가 전송되었음에도 서버가 여전히 접속을 거부한다면, 해당 키가 계정의 authorized_keys 파일에 존재하는지 확인해야 합니다. SSH로 로그인하여 확인할 수 없으므로, 서비스 제공업체의 콘솔을 열어 확인하십시오.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

authorized_keys 파일에 대해 ssh-keygen -lf 명령을 실행하면 항목당 하나의 핑거프린트를 출력합니다.

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

이 출력값과 Offering public key 줄에 있는 핑거프린트를 비교하십시오. 목록에 없다면, 본인이 수행했다고 기억하는 작업과 관계없이 해당 계정에 키가 설치되지 않은 것입니다.

다음은 흔히 발생하는 네 가지 오류 사례입니다.

  • .pub 파일 대신 개인 키를 붙여넣은 경우입니다. 공개 키 줄은 ssh-ed25519 또는 ssh-rsa로 시작합니다. 개인 키는 -----BEGIN OPENSSH PRIVATE KEY-----으로 시작합니다.
  • 붙여넣기 과정에서 여러 줄로 줄 바꿈이 발생한 경우입니다. 각 항목은 반드시 한 줄로 작성되어야 하므로, 줄 바꿈이 된 키는 여러 개의 깨진 항목으로 인식되어 일치하는 키를 찾을 수 없습니다.
  • deploy 계정으로 로그인하는 동안 키가 /root/.ssh/authorized_keys에 저장된 경우(또는 그 반대)입니다. 이 파일은 계정별로 존재하며 공유되지 않습니다.
  • 서비스 제공업체의 "내 키 추가(add my key)" 입력란이 이미지의 기본 사용자에게만 키를 기록하여, 나중에 생성한 계정의 .ssh 디렉터리가 비어 있는 경우입니다.

콘솔에서 root 권한으로 키를 안전하게 추가하는 방법은 다음과 같습니다.

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

작업 후 sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys 명령을 다시 실행하십시오. 이제 새로운 핑거프린트가 목록에 나타날 것입니다. 비밀번호로 로그인할 수 있는 다른 머신이 있다면, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 명령을 사용하여 동일한 작업을 수행하고 권한 모드까지 올바르게 설정할 수 있습니다.

원인 4: sshd가 authorized_keys의 권한이 너무 개방되어 있을 때 이를 무시하는 이유

StrictModes yes는 sshd의 기본값입니다. 이 설정에 따라, authorized_keys 파일, .ssh 디렉터리, 또는 계정의 홈 디렉터리를 소유자 외의 다른 사용자가 수정할 수 있는 경우 sshd는 해당 파일을 읽지 않습니다. 이유는 명확합니다. 그룹이나 다른 사용자가 홈 디렉터리에 쓰기 권한을 가지면, 해당 접근 권한을 가진 계정은 언제든 authorized_keys를 교체하여 로그인을 탈취할 수 있기 때문입니다. sshd는 신뢰할 수 없는 경로를 키가 존재하지 않는 것과 동일하게 취급합니다.

클라이언트는 단순한 Permission denied 메시지를 보게 됩니다. 서버 로그에는 실제 원인이 기록됩니다.

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

또는 파일 자체가 문제인 경우 다음과 같이 기록됩니다.

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

sshd가 허용하는 조건은 다음과 같습니다.

  • 홈 디렉터리: 그룹 쓰기 권한 및 전체 쓰기 권한이 없어야 합니다. 755, 750, 700은 모두 통과합니다. 775와 777은 실패합니다.
  • ~/.ssh: 모드 700.
  • ~/.ssh/authorized_keys: 모드 600.
  • 소유권: 세 항목 모두 root가 아닌 로그인하려는 계정이 소유해야 합니다.

소유권은 모드만큼이나 중요합니다. /home/deploy/.ssh 내부의 파일이 root에 의해 소유된 경우 동일한 검사에서 실패합니다. 이는 sudo nano로 파일을 생성한 뒤 소유권을 변경하는 것을 잊었을 때 발생합니다. 다음 명령어로 두 문제를 한 번에 해결하십시오.

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

마지막 명령은 결과를 보여줍니다. 홈 디렉터리는 drwxr-xr-x 이하의 권한이어야 하며, .ssh은 drwx------여야 합니다. 해당 문자열이 아직 생소하다면 운영 중인 서버의 모드를 변경하기 전에 drwxr-xr-x와 같은 권한 문자열을 읽는 방법을 먼저 읽어보시기 바랍니다.

Rocky Linux 및 AlmaLinux에서는 SELinux(Security-Enhanced Linux)를 의심해 보아야 합니다. 비정상적인 경로로 생성된 .ssh 디렉터리는 잘못된 파일 레이블을 가질 수 있으며, 이 경우 모드가 올바르게 설정되어 있더라도 sshd의 읽기 접근이 거부됩니다. sudo restorecon -Rv /home/deploy/.ssh는 레이블을 복구하며, sudo ausearch -m avc -ts recent은 SELinux가 접근을 거부한 주체인지 확인해 줍니다.

원인 5: sshd 설정에 의한 거부

현재 Ubuntu나 Debian 시스템에서는 /etc/ssh/sshd_config를 읽는 것만으로는 충분하지 않습니다. 해당 파일은 Include /etc/ssh/sshd_config.d/*.conf로 시작하며, OpenSSH는 설정 항목이 중복될 경우 가장 먼저 발견된 값을 우선합니다. 따라서 50-cloud-init.conf과 같은 드롭인(drop-in) 파일이 먼저 읽히며, 메인 파일의 하단에 수정한 내용은 무시됩니다. 이것이 설정을 올바르게 변경했음에도 아무런 변화가 없는 이유입니다.

sshd가 실제로 사용 중인 설정을 확인하려면 다음 명령을 실행합니다.

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

정상적인 출력 결과는 다음과 같습니다.

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

출력 내용에서 확인해야 할 사항은 다음과 같습니다.

  • pubkeyauthentication no: 어떤 키도 허용되지 않습니다. 이는 ssh -v에서 publickey이 없는 첫 번째 Authentications that can continue: 목록으로도 나타납니다.
  • authorizedkeysfile: 다른 경로를 가리키고 있는지 확인하십시오(예: /etc/ssh/authorized_keys/%u). 이 경우 홈 디렉터리의 파일은 완전히 무시되며, 원인 4에서 언급한 권한 규칙이 새로운 경로에 적용됩니다.
  • allowusers 또는 allowgroups: 목록에 없는 모든 계정은 별도의 설명 없이 정확히 이 오류로 거부됩니다. denyusers와 denygroups도 반대 방식으로 동일하게 작동합니다.
  • permitrootlogin no: root 계정으로 로그인을 시도하는 경우입니다. prohibit-password은 유용한 중간 설정으로, root가 키를 사용할 수는 있지만 비밀번호는 사용할 수 없게 합니다.

Match 블록은 일반적인 sshd -T에는 나타나지 않습니다. 결과가 접속자에 따라 달라지기 때문입니다. 특정 접속에 대해 확인하려면 다음 명령을 사용하십시오.

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

오래된 키에 영향을 주는 설정이 하나 더 있습니다. OpenSSH 8.8부터는 SHA-1 서명(ssh-rsa)을 기본적으로 허용하지 않으므로, 서버 업그레이드 직후 수년간 잘 사용하던 RSA 키가 작동하지 않을 수 있습니다. 클라이언트는 이를 명확하게 알립니다.

debug1: send_pubkey_test: no mutual signature algorithm

올바른 해결책은 새로운 키를 생성하는 것입니다. ssh-keygen -t ed25519 -C "deploy@vps-prod"를 실행한 뒤 위에서 설명한 대로 .pub 파일을 설치하십시오. 서버에서 PubkeyAcceptedAlgorithms +ssh-rsa 설정을 사용하면 이전 서명을 다시 활성화하여 즉시 접속할 수 있지만, 이는 임시 방편일 뿐이므로 작업을 완료한 것으로 간주해서는 안 됩니다. 검토할 가치가 있는 나머지 서버 측 설정은 VPS의 SSH 서버 보안 강화에서 확인할 수 있습니다.

개인 키가 설치된 공개 키와 일치하는지 확인하는 방법

이 오류와 관련된 추측의 대부분은 두 파일이 한 쌍인지 알 수 없다는 데서 기인합니다. 다음 명령 하나로 이를 확인할 수 있습니다.

ssh-keygen -y -f ~/.ssh/vps-prod

이 명령은 개인 키에서 파생된 공개 키를 출력합니다. 이 명령은 옆에 있는 .pub 파일을 읽지 않으므로, 오래된 .pub 파일이 주장하는 내용이 아니라 개인 키의 실제 내용을 알려줍니다. 키에 암호(passphrase)가 설정되어 있다면 명령이 암호를 요구하며, 이는 사용자가 여전히 암호를 알고 있음을 증명합니다.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

첫 번째 명령은 공개 키 파일의 지문(fingerprint)을 출력합니다. 두 번째 명령은 에이전트가 보유한 지문을 출력합니다. 이제 동일한 문자열에 대한 네 가지 관점을 나란히 비교해 보십시오. ssh -v의 Offering public key 라인에 있는 지문, .pub 파일의 지문, 서버 authorized_keys 내 ssh-keygen -lf에 있는 지문, 그리고 서버 로그에 기록된 지문입니다. 이들이 일치하지 않는 지점이 바로 문제의 원인입니다.

로그인 실패 시 서버 로그 확인하기

클라이언트에는 의도적으로 유용한 정보가 표시되지 않습니다. 서버는 실제 실패 원인을 로그에 기록합니다. 콘솔 세션에서 로그 추적을 시작한 뒤, 노트북에서 실패하는 ssh 명령을 실행하십시오.

sudo journalctl -u ssh -f

Ubuntu 24.04는 기본적으로 rsyslog를 설치하지 않으므로 /var/log/auth.log이 존재하지 않을 수 있습니다. Rocky Linux 및 AlmaLinux에서는 유닛 이름이 sshd이며, 동일한 기록이 /var/log/secure에도 저장됩니다.

sshd 설정에서 LogLevel VERBOSE을 설정하고 서비스를 다시 불러오십시오. 이후 모든 시도마다 서버가 실제로 수신한 핑거프린트가 기록됩니다.

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

해당 줄을 통해 문제의 원인이 어느 쪽에 있는지 파악할 수 있습니다. 알고 있는 핑거프린트라면 키가 서버에 도달했으나 거부된 것이므로 원인 3, 4, 5를 확인하십시오. 알 수 없는 핑거프린트라면 클라이언트가 의도하지 않은 키를 보낸 것이므로 원인 2로 돌아가십시오.

로그가 여전히 불분명하다면 다른 포트에서 디버그 모드로 두 번째 sshd를 실행하십시오. 이 프로세스는 포그라운드에서 실행되며, 연결 하나를 처리하고 추론 과정을 출력한 뒤 종료됩니다.

sudo /usr/sbin/sshd -ddd -p 2222

동일한 서버의 콘솔 세션에서 루프백 주소를 통해 연결하십시오.

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

127.0.0.1을 경유하면 방화벽의 영향을 받지 않고 테스트할 수 있습니다. 디버그 출력에는 열린 파일, 비교된 핑거프린트, 그리고 Authentication refused: bad ownership or modes for directory /home/deploy과 같은 줄을 포함한 정확한 거부 사유가 표시됩니다. 답을 얻었다면 Ctrl+C를 누르십시오. 포트 22에서 실행 중인 실제 sshd는 테스트 내내 영향을 받지 않습니다.

서버 접근 차단을 방지하는 방법

서버 설정을 수정하는 모든 작업에는 SSH에 의존하지 않는 복구 경로가 필요합니다. SSH가 정상적으로 작동할 때 미리 설정해야 하며, 문제가 발생한 뒤에는 늦습니다.

  1. 제공업체의 콘솔을 통해 시리얼 또는 VNC(virtual network computing)로 접속하여 로그인이 가능한지 확인합니다.
  2. sudo 권한이 있는 계정의 로컬 비밀번호를 알고 있는지 확인합니다. 비밀번호가 없다면 먼저 제공업체 콘솔에서 root 비밀번호를 재설정하십시오.
  3. 현재 SSH 세션을 그대로 유지합니다. 열려 있는 세션은 systemctl restart ssh 이후에도 유지되므로, 새로운 설정이 잘못되었을 때 복구 수단이 됩니다.
  4. 재시작 전 구문 검사를 수행합니다. sudo sshd -t은 파일이 유효하면 아무것도 출력하지 않으며, 유효하지 않으면 파일명과 줄 번호를 출력합니다.
  5. 첫 번째 터미널을 닫기 전에 두 번째 터미널을 열어 새로 로그인을 시도합니다. 설정이 잘못되면 새로운 로그인은 차단되지만 기존 세션은 유지되므로, 현재 세션만으로는 변경 사항이 정상적으로 적용되었는지 확인할 수 없습니다.

Debian 및 Ubuntu에서는 sudo systemctl restart ssh로, Rocky Linux 및 AlmaLinux에서는 sudo systemctl restart sshd로 서비스를 재시작합니다. Ubuntu 24.04의 sshd는 소켓 유닛에서 시작되므로, Port 또는 ListenAddress를 변경한 경우 변경 사항이 적용되기 전에 sudo systemctl restart ssh.socket도 함께 실행해야 합니다.

FAQ

다른 서버에서는 잘 작동하는 키인데 왜 Permission denied (publickey) 오류가 발생합니까?

키 자체는 문제가 없으나 주변 설정이 잘못되었기 때문입니다. ssh -v을 실행하여 Offering public key 줄을 찾으십시오. 키가 목록에 없다면 ssh가 해당 키를 전송하지 않은 것입니다. 파일이 ~/.ssh에 기본 이름으로 존재하지 않거나 에이전트에 로드되지 않은 상태이므로 -i /path/to/key -o IdentitiesOnly=yes를 추가하십시오. 키가 목록에 있는데도 서버가 거부한다면, 해당 키가 계정의 authorized_keys에 등록되지 않았거나, 키 경로에 그룹 쓰기 권한이 있거나, sshd 설정이 해당 사용자를 차단하고 있는 경우입니다. 서버 로그를 확인하면 이 경우들을 구분할 수 있습니다.

SSH가 실제로 어떤 키를 전송하는지 어떻게 확인합니까?

ssh -v host은 키마다 debug1: Offering public key: 줄을 하나씩 출력하며, 각 줄에는 원본 파일명과 SHA256 지문(fingerprint)이 표시됩니다. ssh-add -l은 에이전트가 보유한 지문 목록을 보여줍니다. ssh-keygen -lf ~/.ssh/id_ed25519.pub는 단일 키 파일의 지문을 출력하고, ssh-keygen -y -f ~/.ssh/id_ed25519는 개인 키에서 실제로 파생된 공개 키를 출력합니다. 로그인이 성공하려면 Offering 줄의 지문이 서버의 authorized_keys을 대상으로 실행한 ssh-keygen -lf 결과에도 나타나야 합니다.

sshd가 왜 authorized_keys 파일을 무시합니까?

StrictModes가 기본적으로 활성화되어 있기 때문입니다. 파일이나 .ssh 디렉터리, 또는 홈 디렉터리에 그룹이나 다른 사용자의 쓰기 권한이 있거나 소유자가 잘못된 경우 발생합니다. sshd는 타인이 변경할 수 있는 경로를 신뢰하지 않으므로 키가 없는 것처럼 동작합니다. 홈 디렉터리 권한을 755 이하로, .ssh를 700으로, authorized_keys를 600로 설정하고 세 항목 모두 로그인 계정이 소유하도록 변경하십시오. LogLevel VERBOSE을 사용하면 서버가 Authentication refused: bad ownership or modes for directory /home/deploy/.ssh을 기록합니다.

서버 업그레이드 직후 키가 작동하지 않습니다. 무엇이 변경되었습니까?

RSA 키라면 SHA-1 관련 변경 사항일 가능성이 큽니다. OpenSSH 8.8부터는 ssh-rsa SHA-1 서명이 기본적으로 비활성화되었으므로, 해당 방식으로만 서명할 수 있는 키는 거부됩니다. 상세 모드 클라이언트 출력에 debug1: send_pubkey_test: no mutual signature algorithm가 표시됩니다. ssh-keygen -t ed25519으로 최신 키를 생성하고 .pub 파일을 설치하십시오. 즉시 접속해야 한다면 서버에서 PubkeyAcceptedAlgorithms +ssh-rsa를 설정하여 이전 서명을 다시 활성화할 수 있으나, 새 키가 작동하면 해당 줄을 삭제해야 합니다.

sshd_config를 수정했는데 이제 로그인이 전혀 되지 않습니다. 어떻게 복구합니까?

SSH를 거치지 않는 제공업체의 콘솔을 사용하십시오. 콘솔에서 로컬 비밀번호로 로그인한 뒤 sudo sshd -t을 실행하여 구문 오류와 해당 줄 번호를 확인하고, 변경 사항을 되돌린 후 서비스를 재시작하십시오. 그 후 /etc/ssh/sshd_config.d/의 파일이 메인 설정을 덮어쓰고 있을 수 있으므로 sudo sshd -T를 확인하여 실제 적용된 값을 점검하십시오. 로컬 비밀번호가 없다면 콘솔에서 root 비밀번호를 재설정한 뒤 파일을 복구하십시오.

#ssh#openssh#troubleshooting#permissions#vps