SSH: Received disconnect ... Too many authentication failures

안녕하세요, BlueByte입니다. ssh deploy@bastion을 실행했는데 비밀번호를 묻지도 않고 Too many authentication failures로 연결이 끊깁니다. 쓰려던 키는 디스크에 있고 서버에도 등록돼 있는데, 그게 소용이 없습니다. agent가 다른 키를 먼저 여러 개 내밀었고, 서버는 그 하나하나를 시도로 세었으며, 내 키 차례가 오기 전에 연결을 끊은 것입니다. 오늘은 양쪽이 각각 무엇을 남기는지, 내민 키마다 시도가 소모되는 이유, 어떤 키가 나가는지 눈으로 보는 법, 원인별 해결, 그리고 이 일이 반복되지 않도록 신원 목록을 짧게 유지하는 법까지 하나씩 짚어보겠습니다.

끊긴 연결이 클라이언트와 서버에 각각 남기는 것

클라이언트는 서버가 보낸 disconnect 메시지를 받은 그대로 찍습니다:

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

OpenSSH는 이 줄을 Received disconnect from %s port %d:%u: %.400s 형식으로 만듭니다 — 호스트, 포트, disconnect 사유 코드, 그리고 서버가 보낸 문구 순입니다. 가운데 2는 서버가 이 disconnect에 실어 보내는 프로토콜 오류 사유 코드라서, 여기서 추가로 읽어낼 의미는 없습니다.

더 쓸모 있는 쪽은 서버이고, 설정을 손대기 전에 먼저 꺼내 볼 값어치가 있습니다:

sudo journalctl -t sshd --since "10 min ago" | grep -i "maximum authentication"

sshd[4412]: error: maximum authentication attempts exceeded for deploy from 198.51.100.24 port 51922 ssh2 [preauth]

OpenSSH는 이 줄을 auth_maxtries_exceeded()에서 maximum authentication attempts exceeded for %s%.100s from %.200s port %d ssh2 형식으로 찍고, 계정이 존재하지 않으면 사용자 이름 앞에 invalid user 를 붙입니다. 이 접두사는 키 개수 문제인지 사용자 이름 오타인지 가르는 가장 빠른 단서이고, 확인 비용은 명령 한 줄입니다. 위 명령이 유닛 이름 대신 sshd syslog 식별자로 거르는 이유도 여기 있습니다. Debian 계열은 유닛을 ssh로, Red Hat 계열은 sshd로 부르므로 식별자로 맞추면 양쪽에서 그대로 동작합니다.

agent에 든 키 하나하나가 시도를 소모하는 이유

예산을 정하는 곳은 sshd_config입니다. 매뉴얼은 MaxAuthTries를 연결당 허용되는 최대 인증 시도 횟수로 설명하고, 실패 횟수가 이 값의 절반에 도달하면 이후 실패가 로그에 남는다고 적으며, 기본값을 6으로 제시합니다.

사람들이 놀라는 지점은 "무엇이 세어지는가"입니다. 공개키 인증은 협상입니다. 클라이언트가 공개키를 내밀면 서버가 authorized_keys와 대조해 예·아니오를 답하고, 그다음에야 클라이언트가 개인키 소유를 증명합니다. 서버가 거절한 제안 하나하나가 실패한 시도입니다. agent에 키가 여섯 개면 시도 여섯 번이고, 일곱 번째 — 성공했을 그 키 — 는 보내지지도 않습니다.

기본값 두 개가 이 목록을 예상보다 길게 만듭니다. IdentitiesOnly의 기본값은 no이고, ssh_config 매뉴얼은 이 상태에서 ssh-agent나 PKCS11Provider, SecurityKeyProvider가 설정된 것보다 많은 신원을 내밀 수 있다고 설명합니다. 그리고 IdentityFile은 누적됩니다. 매뉴얼은 IdentityFile 지시자를 여러 번 쓰면 시도할 신원 목록에 더해진다고 적으면서, 이것이 첫 값이 이기는 다른 설정 지시자들과 다른 동작이라고 따로 짚어 둡니다.

여분의 신원이 흘러드는 경로

• 키가 쌓인 agent. 셸 프로필의 AddKeysToAgent, ~/.ssh 안의 키를 전부 올리는 데스크톱 키링, 혹은 여러 직장의 키가 모인 노트북.
• 겹쳐 쓴 IdentityFile 줄. 키 세 개를 나열한 Host * 블록은 기본 파일에 더해 그 셋을 모든 연결에 얹습니다.
• 기본 파일 목록. 설정이 전혀 없으면 ssh는 ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk, ~/.ssh/id_mldsa44_ed25519를 시도합니다 — 정확한 구성은 버전에 따라 달라집니다.
• 낮춰 놓은 서버 예산. 하드닝 기준선은 MaxAuthTries 3을 흔히 설정하며, 내 쪽은 아무것도 바뀌지 않았는데 여유가 절반으로 줄어듭니다.
• 틀린 사용자 이름. 그 키들을 갖고 있지 않은 계정에서는 모든 키가 실패하므로, 아무리 적게 내밀어도 상한에 닿습니다. 서버 로그의 invalid user 접두사가 이 경우를 지목합니다.

키 개수를 세고, 실제로 나가는 제안을 보기

먼저 agent가 무엇을 들고 있는지 물어봅니다:

ssh-add -l

256 SHA256:9Xk2... alice@laptop (ED25519)
3072 SHA256:7Qp1... alice@old-job (RSA)
256 SHA256:2Fm8... alice@personal (ED25519)

그다음 실제 연결이 무엇을 보내는지 지켜봅니다. 질문에 곧장 답을 주는 명령이 이것입니다:

ssh -v deploy@bastion 2>&1 | grep -E "Offering|Will attempt|Authentications that can continue"

debug1: Will attempt key: alice@laptop ED25519 SHA256:9Xk2... agent
debug1: Offering public key: alice@laptop ED25519 SHA256:9Xk2... agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: alice@old-job RSA SHA256:7Qp1... agent
debug1: Offering public key: alice@personal ED25519 SHA256:2Fm8... agent

Offering 줄을 세어 보십시오. 제안 세 번이나 여섯 번에서 멈추고 연결이 끊긴다면 답이 나온 것이고, 내 키에는 아무 문제가 없습니다. 접속하지 않고 ssh가 훑을 목록 전체를 보려면 확정된 설정을 출력하게 하면 됩니다:

ssh -G deploy@bastion | grep -E "^identityfile|^identitiesonly|^user "

ssh -G는 그 대상에 대한 모든 Host·Match 블록을 해석하므로, 내가 썼다고 생각하는 것이 아니라 실제로 쓰일 값을 보여줍니다.

서버가 세는 상한 확인하기

그 호스트를 관리한다면 파일이 아니라 데몬이 실제로 확정한 값을 읽으십시오:

sudo sshd -T | grep -iE "maxauthtries|logingracetime|pubkeyauthentication"

maxauthtries 3
logingracetime 120
pubkeyauthentication yes

sshd -T는 include와 드롭인 파일까지 펼쳐 줍니다. 요즘 배포판 대부분이 /etc/ssh/sshd_config.d/ 조각을 쓰고 하드닝 롤이 거기에 값을 적어 넣기 때문에 이 차이가 실제로 중요합니다.

클라이언트에서, 키 하나와 Host 블록 하나로 고치기

즉시 푸는 방법은 플래그 한 쌍입니다 — agent의 여분 제안을 무시하고 신원 하나만 보내라는 뜻입니다:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_bastion deploy@bastion

전역이 아니라 호스트별로 굳혀 두십시오. agent는 다른 곳에서는 실제로 쓸모가 있기 때문입니다:

Host bastion
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519_bastion
  IdentitiesOnly yes

구체적인 Host 블록은 Host * 블록보다 위에 두십시오. ssh_config 매뉴얼의 순서 규칙은 분명합니다. 별도 언급이 없는 한 각 설정 지시자는 처음 지정된 값이 쓰입니다. 파일 맨 위의 Host * 블록은 그 아래에 쓴 블록을 이깁니다.

나머지는 작은 조치 둘이 덮습니다. ssh-add -d ~/.ssh/id_rsa_old는 낡은 키 하나를 빼고, ssh-add -D는 agent를 통째로 비운 뒤 필요한 것만 다시 올리게 합니다. 그리고 Host 블록의 IdentityAgent none은 다른 곳의 SSH_AUTH_SOCK을 건드리지 않은 채 그 대상에서만 agent를 무시합니다. 서버에서 MaxAuthTries를 올리는 것도 가능하지만 맞는 답인 경우는 드뭅니다. 나만 볼 수 있는 목록을 우회하려고, 무차별 대입 시도가 쓰는 바로 그 창을 함께 넓히는 셈이기 때문입니다.

실제 사례: bastion, 키 아홉 개, 그리고 MaxAuthTries 3

한 엔지니어가 백업으로 노트북을 복구했고 키링이 agent에 키 아홉 개를 올립니다. 다른 건 다 되는데 운영 bastion만 즉시 끊깁니다. ssh-add -l은 아홉 항목을 보여주고, ssh -v는 Offering public key 줄이 정확히 세 번 나온 뒤 끊기는 것을 보여줍니다. bastion의 sshd -T는 maxauthtries 3을 보고하는데, 이는 인터넷에 노출된 호스트에만 적용되는 하드닝 롤이 설정한 값입니다 — 다른 서버가 멀쩡한 이유가 이것입니다. 엔지니어는 IdentitiesOnly yes와 올바른 IdentityFile을 담은 네 줄짜리 Host bastion 블록을 추가합니다. 다음 ssh -v는 제안 한 번과 로그인 성공을 보여주고, 서버는 아무것도 바뀌지 않았습니다.

고쳐졌는지 확인하고, 목록을 짧게 유지하기

-v로 다시 실행해 세어 봅니다:

ssh -v deploy@bastion 2>&1 | grep -cE "Offering public key"
ssh -o BatchMode=yes deploy@bastion true && echo "auth ok"

제안 한 번과 auth ok — 신원이 고정된 상태의 모습입니다. 의지하는 Host 블록마다 IdentitiesOnly yes를 붙이고, 키 하나를 여기저기 돌려쓰는 대신 대상마다 키를 따로 두고, 가끔 ssh-add -l로 agent가 다시 차오르는지 살피면 그 상태가 유지됩니다. 이 호스트들을 스크립트로 다룬다면 BatchMode=yes가 멈춰 선 프롬프트를 즉시 실패로 바꿔 주므로, 신원이 깨졌을 때 멈춘 작업이 아니라 실패한 작업으로 드러납니다.

Permission denied (publickey)와 다른 점

Permission denied (publickey)는 서버가 끝까지 들어줬다는 뜻입니다. 내가 내밀 수 있는 키를 전부 보았고 authorized_keys에 맞는 것이 없었으며, 시도가 아니라 신원이 동난 것입니다. 그쪽 해결은 서버에 있습니다 — 올바른 공개키가 올바른 파일에, 올바른 소유권과 권한으로 들어가야 합니다. Too many authentication failures는 서버가 목록 중간에서 끊었다는 뜻이라, 정작 중요한 키는 보내지지도 않았을 수 있습니다. ssh -v의 Offering 개수가 둘을 명령 한 줄로 갈라 줍니다.

Host key verification failed는 아예 다른 단계입니다. 그 검사는 인증보다 먼저 돌고 서버가 known_hosts를 근거로 자기 신원을 나에게 증명하는 일이라, 그 오류가 날 때는 내 키가 아직 하나도 나가지 않은 상태입니다.

다음에 아무것도 묻지 않고 연결이 죽으면 이 순서를 거꾸로 따라가 보세요. 서버 로그 줄에서 invalid user 접두사를 확인하고, ssh -v의 Offering 줄을 세고, 그 수를 sshd -T 값과 견줘 본 다음, 신원을 고정하면 됩니다.