SSH 인증 실패 진단 및 해결

Secure Shell(SSH)은 안전한 원격 관리를 위한 기반으로, 서버와 네트워크 장치에 암호화된 접근을 가능하게 합니다. 그러나 시스템 관리자와 개발자 모두에게 인증 실패는 흔하고 종종 좌절스러운 경험입니다. 이러한 문제는 단순한 오타부터 복잡한 권한 문제나 잘못된 설정에 이르기까지 다양한 원인에서 발생할 수 있습니다.

이 문서는 SSH 인증 실패를 효과적으로 진단하고 해결하기 위한 포괄적인 가이드를 제공합니다. 클라이언트 측 상세 출력과 서버 측 로그 분석의 중요한 역할을 강조하며 체계적인 문제 해결 방법을 다룹니다. 이러한 진단 단서를 해석하는 방법을 이해하면 대부분의 인증 문제의 근본 원인을 정확히 찾아내고 안전한 원격 접근을 복원할 수 있습니다.

SSH 인증 방법 이해

문제 해결에 들어가기 전에 SSH가 사용하는 주요 인증 방법을 이해하는 것이 필수적입니다.

• 비밀번호 인증: 사용자가 비밀번호를 제공하면 서버가 사용자 데이터베이스나 외부 인증 서비스(예: PAM)를 통해 확인합니다.
• 공개 키 인증: 이 더 안전한 방법은 클라이언트에 저장된 개인 키와 서버에 저장된 해당 공개 키라는 한 쌍의 암호화 키를 사용합니다. 인증 시 클라이언트는 개인 키를 사용하여 네트워크를 통해 개인 키를 전송하지 않고 신원을 증명합니다.

인증 실패는 두 방법 모두에서 발생할 수 있지만, 문제 해결 단계는 종종 다릅니다.

초기 확인 및 일반적인 함정

상세 로그를 살펴보기 전에 몇 가지 기본 확인을 수행하는 것이 현명합니다. 많은 문제가 종종 단순한 실수이기 때문입니다.

• 올바른 사용자 이름과 호스트 이름: 올바른 사용자 이름과 대상 서버의 정확한 호스트 이름 또는 IP 주소를 사용하고 있는지 다시 확인하세요.
• 네트워크 연결: 서버에 전혀 도달할 수 있습니까? nc -vz host 22 또는 ssh -vvv를 사용하여 SSH 연결 가능성을 테스트하세요. ping이 도움이 될 수 있지만 많은 서버가 SSH가 작동 중일 때도 ICMP를 차단합니다.

  ping example.com
  

• SSH 서비스 상태: 대상 머신에서 SSH 서버(sshd)가 실제로 실행 중입니까? 콘솔 접근 권한이 있다면 상태를 확인하세요.

  sudo systemctl status sshd # systemd 기반 시스템(대부분의 최신 Linux)
  sudo service sshd status    # 이전 init 시스템
  

• SSH 포트: SSH 데몬이 기본 포트(22)에서 수신 중입니까, 아니면 사용자 지정 포트에서 수신 중입니까? 사용자 지정 포트인 경우 -p로 지정해야 합니다.
• 방화벽 규칙: 포트 22(또는 사용자 지정 SSH 포트)를 차단하는 방화벽(클라이언트 측 또는 서버 측)이 있습니까? ufw, firewalld 또는 AWS 보안 그룹과 같은 서버 방화벽을 확인하세요.

  sudo ufw status
  sudo firewall-cmd --list-all
  

클라이언트 측 진단: 상세 모드 활용

SSH 클라이언트는 연결 프로세스 및 인증 시도에 대한 자세한 디버깅 출력을 제공하는 상세 모드(-v, -vv, -vvv)를 제공합니다. 이 출력은 클라이언트가 인증 실패라고 생각하는 이유를 이해하는 데 매우 중요합니다.

상세 플래그 사용

• -v: 상세 출력.
• -vv: 더 상세한 출력.
• -vvv: 훨씬 더 상세한 출력(종종 인증 문제에 가장 유용함).

예제 명령어:

ssh -vvv username@your_server_ip

상세 출력 해석

상세 모드로 ssh를 실행할 때 인증 프로세스가 실패하는 위치를 나타내는 주요 줄을 찾으세요.

• debug1: Authentications that can continue:: 이 줄은 서버가 수락할 의사가 있는 인증 방법을 알려줍니다. 원하는 방법(예: publickey)이 나열되지 않은 경우 서버 구성이 이를 방지하고 있는 것입니다.

  debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
  

• debug1: Offering public key:: 클라이언트가 인증을 위해 특정 공개 키를 사용하려고 시도하고 있음을 나타냅니다. 공개 키 인증을 예상했지만 이 내용이 보이지 않으면 클라이언트가 키를 찾거나 제공하지 못하고 있는 것입니다.

  debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
  

• debug3: send_pubkey_test: ... trying private key: /home/user/.ssh/id_rsa: 클라이언트가 특정 개인 키를 사용하려고 시도하고 있음을 확인합니다.
• debug1: Server accepts key: ...: 클라이언트 관점에서 공개 키 인증이 성공했음을 나타냅니다. 이 내용이 보이지 않으면 서버가 키를 거부한 것입니다.
• debug1: No more authentication methods to try.: Permission denied 오류 직전에 자주 나타나며, 클라이언트가 사용 가능한 모든 인증 방법을 성공 없이 소진했음을 의미합니다.
• debug1: Permission denied (publickey,password).: 모든 시도에 대한 서버의 거부를 요약한 최종 클라이언트 측 오류입니다.

팁: 제공되고 수락되는 인증 방법의 순서에 주의하세요. publickey가 제공된 후 즉시 비밀번호 프롬프트가 이어지면 서버가 공개 키를 거부했음을 의미하는 경우가 많습니다.

서버 측 진단: SSH 서버 로그 검사

클라이언트 측 상세 출력은 클라이언트가 시도하는 내용을 보여주는 반면, 서버 로그는 서버가 인증 시도를 거부한 이유에 대한 결정적인 정보를 제공합니다. 이는 종종 근본 원인 분석에서 가장 중요한 단계입니다.

SSH 서버 로그 찾기

SSH 서버 로그의 위치는 운영 체제에 따라 다릅니다.

• Debian/Ubuntu 및 파생 제품: /var/log/auth.log
• RHEL/CentOS/Fedora 및 파생 제품: /var/log/secure
• systemd 기반 시스템(대부분의 최신 Linux): journalctl을 사용할 수도 있습니다.

서버 로그 보기 및 필터링

tail 또는 journalctl과 같은 도구를 사용하여 로그를 실시간으로 모니터링하거나 SSH 관련 항목을 필터링하세요.

예제 명령어:

# Debian/Ubuntu의 경우
sudo tail -f /var/log/auth.log | grep sshd

# RHEL/CentOS의 경우
sudo tail -f /var/log/secure | grep sshd

# systemd 기반 시스템의 경우(현재 로그를 보는 가장 강력한 방법)
sudo journalctl -u sshd -f

# 처음부터 모든 sshd 로그를 보려면(실패가 이전에 발생한 경우 유용함)
sudo journalctl -u sshd

일반적인 서버 로그 항목과 그 의미

연결을 시도할 때 sshd 관련 메시지를 찾으세요. 다음은 인증 실패를 나타내는 일반적인 항목입니다.

• Failed password for user from IP port ssh2: 비밀번호 인증 시도가 실패했음을 나타냅니다. 잘못된 비밀번호 때문이거나 사용자가 비밀번호로 로그인할 수 없기 때문일 수 있습니다.
• Authentication refused: bad ownership or modes for directory /home/user/.ssh: 매우 일반적인 공개 키 인증 오류입니다. 서버의 .ssh 디렉토리 권한이 잘못되었습니다.
  • 해결책: chmod 700 /home/user/.ssh
• Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys: 또 다른 일반적인 공개 키 오류로, authorized_keys 파일의 권한이 잘못되었음을 나타냅니다.
  • 해결책: chmod 600 /home/user/.ssh/authorized_keys
• sshd[PID]: error: Permissions 0777 for '/home/user/.ssh/authorized_keys' are too open.: 지나치게 허용적인 파일 모드 문제를 명시적으로 나타냅니다. SSH는 보안상의 이유로 권한에 대해 매우 엄격합니다.
• User username from IP not allowed because not listed in AllowUsers: /etc/ssh/sshd_config의 AllowUsers 지시문에 따라 사용자가 SSH를 통해 로그인할 수 없습니다.
• User username from IP not allowed because listed in DenyUsers: 사용자가 DenyUsers에 의해 SSH 접근이 명시적으로 거부되었습니다.
• input_userauth_request: invalid user username: 제공된 사용자 이름이 서버에 존재하지 않습니다.
• Failed publickey for user 또는 반복된 제공 키 다음에 비밀번호: 클라이언트가 제시한 공개 키가 해당 사용자의 허용된 키와 일치하지 않거나 서버가 권한 또는 정책 때문에 키를 거부했습니다.
• Maximum authentication attempts exceeded for user from IP: 클라이언트가 너무 많은 인증 방법을 시도했거나 너무 많은 잘못된 자격 증명을 보냈습니다. sshd_config의 MaxAuthTries에 의해 제어됩니다.
• Connection closed by authenticating user IP port 22 [preauth]: 허용 가능한 인증 방법을 찾을 수 없거나 실패 후 클라이언트가 연결을 갑자기 종료한 경우 발생할 수 있습니다.

일반적인 인증 실패 시나리오 및 해결책

일반적인 실패와 특정 해결 방법을 분류해 보겠습니다.

1. 비밀번호 인증 실패

• 잘못된 비밀번호: 가장 간단한 문제입니다. 비밀번호를 다시 확인하세요. 키보드 레이아웃, Caps Lock 또는 Num Lock에 주의하세요.
• 사용자 허용 안 됨: sshd_config 파일(/etc/ssh/sshd_config)이 특정 사용자의 로그인을 제한할 수 있습니다.
  • PermitRootLogin no: 루트 로그인을 방지합니다(보안을 위해 적극 권장).
  • AllowUsers username1 username2: 지정된 사용자만 로그인할 수 있습니다.
  • DenyUsers username: 지정된 사용자는 로그인할 수 없습니다.
  • AllowGroups groupname: 지정된 그룹의 사용자만 로그인할 수 있습니다.
  • 해결책: sshd_config 지시문을 조정하고 sshd를 다시 시작하세요.
• PAM 문제: 서버가 PAM(Pluggable Authentication Modules)을 사용하는 경우 PAM 구성 문제로 인해 비밀번호 인증이 차단될 수 있습니다. PAM 관련 오류는 /var/log/auth.log를 확인하세요. 기본 SSH 설정에서는 덜 일반적입니다.

2. 공개 키 인증 실패

공개 키 인증은 종종 더 안전하지만 구성 관련 오류가 발생하기 쉽습니다.

• 잘못된 파일/디렉토리 권한(서버 측): 지금까지 가장 일반적인 원인입니다. SSH는 보안을 위해 ~/.ssh 및 ~/.ssh/authorized_keys에 엄격한 권한을 요구합니다.
  • ~: 사용자의 홈 디렉토리는 세계에서 쓰기 가능하지 않아야 합니다(chmod 755 ~는 일반적으로 안전함).
  • ~/.ssh: 700(소유자만 rwx)이어야 합니다.

    chmod 700 ~/.ssh
    

  • ~/.ssh/authorized_keys: 600(소유자만 rw)이어야 합니다.

    chmod 600 ~/.ssh/authorized_keys
    

  • 이러한 파일 및 디렉토리의 소유자는 로그인을 시도하는 사용자여야 합니다.

    sudo chown -R username:username ~/.ssh
    

• 잘못된 authorized_keys 내용: ~/.ssh/authorized_keys의 공개 키가 손상되었거나, 추가 문자가 있거나, 잘못된 형식일 수 있습니다. 각 키는 한 줄에 있어야 합니다. 올바른 형식을 보장하는 빠른 방법은 클라이언트에서 ssh-copy-id를 사용하는 것입니다.

  ssh-copy-id -i ~/.ssh/id_rsa.pub username@your_server_ip
  

  클라이언트 측에서 공개 키 지문을 확인하려면: ssh-keygen -l -f ~/.ssh/id_rsa.pub
• 클라이언트가 키를 제공하지 않음: 개인 키가 기본 위치(~/.ssh/id_rsa)에 없거나, ssh-agent에 로드되지 않았거나, -i로 지정하지 않았을 수 있습니다.
  • 해결책: 개인 키가 ~/.ssh에 id_rsa(또는 id_ed25519 등)로 있고 600 권한이 있는지 확인하세요. 그렇지 않은 경우 지정하세요:

    ssh -i /path/to/your/private_key username@your_server_ip
    

  • ssh-agent를 사용하는 경우 키가 추가되었는지 확인하세요:

    eval "$(ssh-agent -s)"
    ssh-add ~/.ssh/your_private_key
    

• sshd_config가 공개 키 인증을 허용하지 않음: 서버의 SSH 데몬이 공개 키 인증을 허용하지 않도록 구성되어 있을 수 있습니다.
  • /etc/ssh/sshd_config에서 PubkeyAuthentication yes를 확인하세요.
  • AuthorizedKeysFile .ssh/authorized_keys가 올바른 파일을 가리키는지 확인하세요. 기본값은 일반적으로 괜찮습니다.
  • 해결책: PubkeyAuthentication yes를 설정하고 sshd를 다시 시작하세요.
• SELinux/AppArmor 간섭: SELinux 또는 AppArmor가 있는 시스템에서 이러한 보안 모듈은 파일 권한이 올바른 경우에도 SSH가 사용자 홈 디렉토리나 .ssh 파일에 접근하는 것을 차단할 수 있습니다. 단서를 위해 감사 로그(/var/log/audit/audit.log 또는 sudo ausearch -m AVC -ts recent)를 확인하세요. 이는 고급 시나리오입니다.

3. 연결 거부 또는 시간 초과

엄밀히 말해 "인증" 실패는 아니지만, 이러한 문제는 종종 인증 시도보다 먼저 발생하여 인증 시도 자체를 시작하지 못하게 합니다.

• 방화벽 차단: 클라이언트(예: 로컬 OS 방화벽)와 서버(예: ufw, firewalld, 클라우드 보안 그룹, 네트워크 ACL) 모두에서 방화벽을 확인하세요. 포트 22(또는 사용자 지정 포트)가 열려 있는지 확인하세요.
• SSH 서버가 실행 중이 아님: sshd 서비스가 활성화되지 않았거나 중단되었을 수 있습니다.
• 잘못된 포트/IP: 잘못된 포트나 IP 주소에 연결을 시도하고 있습니다.

일반적인 디버깅 팁

• sshd_config 확인: 서버에서 /etc/ssh/sshd_config를 항상 검토하여 방해가 될 수 있는 기본이 아닌 설정이 있는지 확인하세요. 변경 후에는 항상 SSH 데몬을 다시 시작하세요: sudo systemctl restart sshd(또는 sudo service sshd restart).
• 새 사용자/키로 테스트: 가능하면 새 사용자와 새 공개/개인 키 쌍을 만드세요. 이 새로운 설정으로 인증을 시도해 보세요. 작동하면 문제는 원래 사용자의 구성에 국한된 것입니다.
• 문제 격리: 다른 클라이언트 머신에서 연결을 시도해 보세요. 작동하면 문제는 클라이언트 관련입니다. 여러 클라이언트에서 실패하면 문제는 서버 관련입니다.
• LogLevel 증가(서버 측): 심층 디버깅을 위해 /etc/ssh/sshd_config에서 일시적으로 LogLevel DEBUG를 설정하고 sshd를 다시 시작하세요. 디버그 로그는 매우 상세하고 디스크 공간을 소비할 수 있으므로 문제 해결 후 이 설정을 되돌리는 것을 잊지 마세요.

핵심 요점

ssh -vvv를 사용하여 클라이언트가 제공하는 내용을 확인한 다음 서버 로그를 확인하여 sshd가 이를 거부한 이유를 알아내세요. 대부분의 공개 키 실패는 잘못된 키, 누락된 authorized_keys 항목, 엄격한 파일 권한 또는 사용자나 방법을 차단하는 sshd_config 규칙으로 귀결됩니다.