Amazon Linux 2 EOS 대응 마이그레이션 후 Rundeck 인증 실패 트러블슈팅

1. 배경

운영 중인 배치 서버를 Amazon Linux 2 EOS(End of Support) 대응을 위해 Amazon Linux 2023으로 마이그레이션했습니다.

기존과 동일한 SSH 키페어를 그대로 사용해 재구축했음에도, Rundeck을 통한 노드 접속이 아래 에러로 실패했습니다.

Authentication failure connecting to node: "batch-server".
Make sure your resource definitions and credentials are up to date.

반면 동일한 키로 수동 SSH 접속(시스템 OpenSSH 클라이언트)은 정상 동작했습니다. 즉, 키 자체는 문제가 없다는 게 먼저 확인된 상태였습니다.

 

 

2. 근본 원인: OpenSSH 알고리즘 정책 차이 (Amazon Linux 2 vs 2023)

구분 Rundeck 서버 (Amazon Linux 2) 배치 서버 (Amazon Linux 2023)

OpenSSH 버전	구버전	최신
ssh-rsa (SHA-1 기반 서명) 지원	기본 지원	기본 비활성화
기본 허용 알고리즘	ssh-rsa 포함	rsa-sha2-256, rsa-sha2-512 등 SHA-2 계열만

Amazon Linux 2023은 보안 강화를 위해 SHA-1 기반의 ssh-rsa 알고리즘을 기본값에서 제외하는 정책을 채택하고 있습니다.

반면 Rundeck이 내부적으로 사용하는 **jsch(Java SSH 라이브러리)**는 구버전이라 신형 rsa-sha2-256/rsa-sha2-512 서명 방식을 지원하지 못하고, 구식 ssh-rsa만 요청합니다.

배치 서버(AL2023)는 ssh-rsa 요청 자체를 거부합니다. jsch 입장에서는 알고리즘 협상 단계에서 실패하는 것이지만, Rundeck은 이를 뭉뚱그려 "Authentication failure"로만 표시합니다.

핵심: 시스템 OpenSSH 클라이언트는 최신 알고리즘(rsa-sha2-*)으로 자동 협상하여 접속에 성공하지만, jsch는 구식 알고리즘만 지원하기 때문에 동일한 키·동일한 서버여도 클라이언트 종류에 따라 결과가 달라집니다.

 

 

3. 확인 방법

배치 서버에서 sshd가 실제로 허용하는 public key 알고리즘 목록을 확인합니다.

sudo sshd -T | grep -i pubkeyaccepted

이 목록에 ssh-rsa가 없으면 해당 이슈로 확정할 수 있습니다.

 

 

4. 해결

배치 서버(AL2023)의 /etc/ssh/sshd_config에 아래 라인을 추가합니다.

PubkeyAcceptedAlgorithms +ssh-rsa

+를 앞에 붙여 기존 허용 목록에 추가하는 방식으로 설정해야 합니다. 앞에 + 없이 쓰면 기존 목록이 전부 사라지고 ssh-rsa만 남으므로 주의가 필요합니다.

적용은 다음 순서로 진행합니다.

sudo sshd -t                              # 문법 검사
sudo systemctl restart sshd                # 재시작 (reload 아닌 restart)
sudo sshd -T | grep -i pubkeyaccepted      # 반영 확인 (ssh-rsa 포함 여부)

 

 

주의: Amazon Linux 2023은 /etc/ssh/sshd_config 최상단에 Include /etc/ssh/sshd_config.d/*.conf가 위치합니다. sshd_config는 먼저 읽힌 값이 우선 적용되므로, 만약 sshd_config.d/ 내 다른 파일이 PubkeyAcceptedAlgorithms를 이미 지정하고 있다면 메인 파일 하단에 추가한 설정이 무시될 수 있습니다. 아래 명령으로 사전 확인을 권장합니다.

grep -r -i "PubkeyAccepted" /etc/ssh/sshd_config.d/

 

5. 결과

sshd -T 출력에 ssh-rsa가 정상 포함됨을 확인했고, Rundeck을 통한 배치 서버 인증이 성공했습니다.

 

 

6. 정리

이번 이슈의 핵심은 "같은 키, 같은 서버인데 왜 클라이언트에 따라 결과가 다른가"였습니다. 원인은 SSH 서명 알고리즘 협상 방식의 차이였고, OS 버전이 바뀌면서 보안 기본값이 강화된 게 발단이었습니다.

EOS 대응으로 OS를 업그레이드하는 작업을 진행하신다면, SSH로 접속하는 외부 도구(Rundeck, Ansible, Jenkins 등)가 내부적으로 어떤 SSH 라이브러리를 쓰는지, 그리고 그 라이브러리가 최신 서명 알고리즘을 지원하는지 미리 점검해보시길 권장드립니다.