SSH “too many authentication failures”? 서버를 바꾸기 전에 제시된 키부터 세세요

1. 실패한 대상과 실제 설정을 고정하세요

실패한 것과 같은 셸, 호스트 별칭, 사용자 이름을 사용하세요. 비밀을 제외한 명령을 기록하고 Git·IDE·자동화가 SSH를 실행했다면 실제 전달한 호스트와 사용자를 확인하세요.

`ssh -G your-host | grep -Ei "^(hostname|user|identityfile|identityagent|identitiesonly|preferredauthentications) "`를 실행하세요. 먼저 HostName과 User를 확인하고 모든 IdentityFile을 검토하세요. Include와 일치 블록 때문에 누적될 수 있습니다.

호스트나 사용자가 틀리면 경로를 먼저 고치고 같은 진단을 반복하세요. 잘못된 계정을 키 삭제로 보정하지 마세요.

2. 사용 가능한 키와 실제 제시 순서를 비교하세요

실패한 셸에서`ssh-add -l -E sha256`를 실행하세요. 연결된 에이전트의 지문 목록일 뿐 모두 제시된다는 뜻도, 클라이언트가 파일에서 직접 읽는 모든 키 목록도 아닙니다.

`ssh -vvv user@your-host`를 한 번 실행하고 각 “Offering public key” 줄에서 키 종류와 SHA256 지문만 순서대로 기록하세요. 공유 전 주소·사용자·개인 경로를 가리고, 의도한 지문이 끊기기 전에 나타나는지 봅니다.

예상하지 못한 키가 여러 개 먼저 제시되면 선택 순서 문제입니다. 의도한 키 하나만 제시됐는데 거절되면 사용자, authorized_keys, 인증서 주체, 서명 또는 서버 정책을 조사하세요.

3. 아무것도 삭제하지 않고 단일 키 테스트를 하세요

`ssh-keygen -lf /path/to/key.pub -E sha256`로 의도한 지문을 확인한 뒤`ssh -o IdentitiesOnly=yes -i /path/to/key user@your-host`를 실행하세요. 이 연결만 제한하고 에이전트와 다른 키는 그대로 둡니다.

성공하면 서버·계정·키는 함께 작동하며 더 넓은 클라이언트 환경의 선택 또는 순서가 원인입니다. 해당 별칭 전용 Host 블록에 HostName, User, IdentityFile,`IdentitiesOnly yes`를 저장하고`ssh -G`와`ssh -vvv`로 다시 확인하세요.

실패하면 자세한 추적을 보존하세요. 단일 의도 키 뒤의 Permission denied 또는 에이전트 서명 거절은 다른 분기입니다. MaxAuthTries 증가나 에이전트 비우기로 키 승인과 사용 가능성을 증명할 수 없습니다.

4. 가장 작은 지속적 수정만 적용하세요

한 호스트에는 호스트 전용 블록을 사용하세요. 모든 목적지를 감사하지 않았다면 IdentityFile을 넓은 범위에 두거나`IdentitiesOnly yes`를 전역으로 만들지 마세요. GitHub와 GitLab도 여러 키를 호스트별로 선택하도록 문서화합니다.

다른 시스템에 필요한 에이전트 키는 유지하세요. 별도로 폐기 결정한 키만 내리고, 진단을 위한 삭제는 하지 마세요. GUI 클라이언트가 OpenSSH 설정을 무시하면 자체 에이전트와 키 선택 제어를 확인하세요.

MaxAuthTries는 별도 서버 정책 검토에서만 바꾸세요. 이 사건의 완료 조건은 올바른 지문이 제시되고 인증되는 것입니다.

결정표

HostName 또는 User 오류 — 대상을 먼저 고치고 키 상태는 유지합니다.

연결 종료 전 예상 밖 지문 다수 — 단일 키 테스트 후 좁은 Host 블록을 사용합니다.

의도한 지문 하나도 거절 — 서버 권한 또는 서명 진단으로 이동합니다.

단일 키 테스트 성공 — 다른 키를 유지하고 실제 설정을 재검증합니다.

OpenSSH가 아니거나 ssh_config 무시 — 제품 자체의 에이전트와 선택 제어를 찾습니다.