SSH Too many authentication failures 해결: agent 키·IdentitiesOnly·실제 설정 확인

올바른 키가 있는데 Too many authentication failures로 연결이 끊기면, 먼저 ssh-agent가 제공하는 키 목록과 클라이언트의 실제 IdentityFile 설정을 확인하세요. 필요한 호스트에 IdentitiesOnly yes와 맞는 키를 지정하는 것이 출발점입니다. 이 오류를 해결하려고 서버의 인증 제한을 무조건 높이거나 호스트 키 검증을 끄지 않습니다.

원인: 목적지 키에 도달하기 전에 다른 인증 후보가 시도될 수 있다

ssh-agent에는 여러 서비스용 키가 등록될 수 있습니다. 클라이언트 설정·에이전트가 제시하는 후보와 서버의 접속당 인증 제한이 만나면 원하는 키로 인증하기 전에 연결이 종료될 수 있습니다. 다만 모든 동일 문구가 agent 때문이라고 단정하지 말고 실제 로그와 적용 설정을 대조해야 합니다.

OpenSSH의 MaxAuthTries는 서버가 연결 한 번에 허용할 인증 시도 수와 관련됩니다. 서버 버전·정책·인증 수단에 따라 관찰되는 시도 방식이 다를 수 있으므로 “키 몇 개면 항상 실패한다”는 고정 계산을 적용하지 않습니다. 다른 사용자의 로그인에 영향을 주는 서버 제한 변경보다 클라이언트에서 불필요한 후보를 줄일 수 있는지 먼저 확인합니다.

관찰 결과	다음 확인	피할 처리
여러 identity 제시	agent 목록·IdentityFile 누적	원인 없이 접속 반복
필요한 키가 미제시	유효 Host 설정·경로	서버 제한부터 확대
키 제시 후 publickey 거부	계정·등록 키·서버 정책	개인 키 공개
서버 호스트 키 경고	신뢰할 지문·대상 주소	호스트 검증 해제

1. 접속 없이 agent 목록과 유효 설정을 확인한다

다음 예시는 OpenSSH가 설치된 Linux·macOS용입니다. deploy-prod는 실제 사용하는 호스트 별칭으로 바꿉니다. ssh-add -l은 공개 키 지문 목록을, ssh -G는 Host·Match 평가 뒤의 설정을 표시합니다. 다만 사용자 설정의 Match exec 같은 로컬 명령이 평가될 수 있으므로 신뢰한 설정을 사용하세요.

ssh -V
ssh-add -l
ssh -G deploy-prod | awk '/^(hostname|user|port|identityfile|identitiesonly|identityagent) /'

IdentityFile이 여러 줄 나오거나 Host *의 항목이 섞였는지 확인합니다. IdentityFile은 여러 선언이 누적될 수 있어 -i 하나를 적었다는 사실만으로 후보가 정확히 한 개라고 보장할 수 없습니다. agent가 없다는 결과와 키가 없다는 결과도 구분합니다. 출력에는 사용자명·호스트·로컬 경로·지문이 포함될 수 있으니 공개 질문에 원문을 그대로 붙이지 않습니다.

2. 해당 호스트 범위에서 필요한 identity를 지정한다

현재 클라이언트 설정을 별도 보관한 뒤 정확한 별칭에만 아래 구조를 적용합니다. 개인 키 경로와 사용자·포트는 실제 관리자 안내에 맞춥니다. IdentitiesOnly는 설정된 identity로 후보를 제한하지만 기본·명시된 키와 인증서까지 자동으로 하나로 만드는 옵션은 아닙니다.

Host deploy-prod
    HostName server.example
    User deploy
    Port 22
    IdentityFile ~/.ssh/id_ed25519_deploy
    IdentitiesOnly yes

# 파일 기반 키를 명시한 일회성 점검 예시
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_deploy deploy-prod

기존 Host *·Include·여러 IdentityFile이 있다면 다시 ssh -G로 최종 결과를 봅니다. agent만 가지고 있는 키·하드웨어 키·조직 인증서를 쓰는 환경에서는 로컬 개인 키 파일이 없을 수 있습니다. 이런 경우 에이전트를 일괄 끄면 정상 인증도 막힐 수 있으므로 조직의 키 사용 방식을 확인합니다. IdentityAgent none은 agent 사용을 끄는 별도 옵션이며 모든 환경의 기본 해결책으로 추가하지 않습니다.

확인 방법: 한 번의 진단 접속에서 제시된 키와 다음 오류를 분리한다

설정 확인 후 허가된 대상에 ssh -v deploy-prod로 한 번 접속해 어떤 identity를 제시했는지 봅니다. 반복 접속은 차단 정책이나 경보를 유발할 수 있으므로 설정을 바꾸지 않은 채 계속 시도하지 않습니다. 로그인 성공이 보이면 사용자·호스트가 맞는지도 확인합니다. 이 글의 예시는 문서 확인용이며 실제 서버 인증을 실행한 기록이 아닙니다.

정해진 키가 제시됐는데 Permission denied (publickey)로 바뀌면 대상 사용자·등록된 공개 키·권한·서버 정책을 따로 점검합니다. Host key verification failed라면 서버 신원 검증 단계입니다. 사용자 키 문제로 보고 known_hosts를 지우거나 StrictHostKeyChecking을 끄지 마세요. 별칭별 설정 변경이 원인이라면 보관한 해당 블록만 되돌리고 다시 유효 설정을 확인합니다.

주의사항: 전체 키 삭제나 서버 제한 확대를 첫 조치로 쓰지 않는다

ssh-add -D로 모든 agent 키를 제거하면 다른 서비스 작업까지 영향을 받습니다. 사용 중인 키 목록을 기록하고 대상 호스트의 선택 범위부터 줄이세요. 개인 키·비밀번호·에이전트 소켓 내용을 공유하거나 파일 권한을 넓히는 방법은 사용하지 않습니다. 서버 정책 변경이 꼭 필요하면 관리자와 별도로 검토해야 합니다.

FAQ

-i를 지정했는데도 왜 여러 키가 나오나요? agent와 다른 IdentityFile 설정을 함께 확인해야 합니다. 최종 후보는 ssh -G와 진단 로그로 대조합니다.

서버의 MaxAuthTries를 크게 하면 되나요? 불필요한 후보가 원인이라면 클라이언트 범위를 먼저 바로잡는 편이 영향이 작습니다.

이 설정이 호스트 키 경고도 해결하나요? 아닙니다. 사용자 인증 identity와 서버 호스트 키 신뢰는 다른 단계입니다.

공식 출처와 관련 글

공식 자료 확인일은 2026년 10월 16일입니다. 명령·설정은 공식 문서로 확인했으며 운영 서비스에서 직접 실행한 시험·속도·비용 결과가 아닙니다. 실제 적용 전 설치 버전과 대상 서비스의 지원 범위를 확인하세요.

IdentityFile·IdentitiesOnly·IdentityAgent와 설정 적용

서버의 MaxAuthTries와 접속 제한

agent 키 목록과 키 관리 옵션

유효 설정·진단 로그·키 파일 지정

관련 글: GitHub Actions의 SSH publickey 오류와 인증 대상 구분

직접 생성한 개념 이미지입니다. 필요한 사용자 키를 고르는 원리를 설명하며 실제 인증 성공 화면이나 보안 시험 결과가 아닙니다.