SSH 인증 실패 진단 및 해결

SSH(Secure Shell)는 서버 및 네트워크 장치에 암호화된 액세스를 허용하여 안전한 원격 관리를 위한 기반입니다. 그러나 인증 실패를 겪는 것은 시스템 관리자와 개발자 모두에게 흔하고 종종 좌절스러운 경험일 수 있습니다. 이러한 문제는 간단한 오타부터 복잡한 권한 문제 또는 잘못된 구성에 이르기까지 수많은 원인에서 비롯될 수 있습니다.

이 문서는 SSH 인증 실패를 효과적으로 진단하고 해결하기 위한 포괄적인 가이드 역할을 합니다. 클라이언트 측의 자세한 출력과 서버 측 로그 분석의 중요한 역할을 강조하면서 체계적인 문제 해결 방법을 자세히 살펴보겠습니다. 이러한 진단 단서를 해석하는 방법을 이해하면 대부분의 인증 문제의 근본 원인을 정확히 찾아내고 안전한 원격 액세스를 복원할 수 있는 장비를 갖추게 될 것입니다.

SSH 인증 방법 이해하기

문제 해결에 착수하기 전에 SSH가 사용하는 주요 인증 방법을 이해하는 것이 중요합니다.

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

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

초기 확인 및 일반적인 함정

자세한 로그를 살펴보기 전에 많은 문제가 단순한 간과인 경우가 많으므로 몇 가지 기본 확인을 수행하는 것이 좋습니다.

• 올바른 사용자 이름 및 호스트 이름: 올바른 사용자 이름과 대상 서버의 정확한 호스트 이름 또는 IP 주소를 사용하고 있는지 다시 확인하십시오.
• 네트워크 연결: 서버에 전혀 액세스할 수 있습니까? 기본 네트워크 도달 가능 여부를 확인하려면 ping을 사용하십시오.
  bash ping example.com
• SSH 서비스 상태: 대상 머신에서 SSH 서버(sshd)가 실제로 실행되고 있습니까? 콘솔 액세스가 있는 경우 상태를 확인하십시오.
  bash sudo systemctl status sshd # systemd 기반 시스템(대부분의 최신 Linux) sudo service sshd status # 이전 init 시스템용
• SSH 포트: SSH 데몬이 기본 포트(22) 또는 사용자 지정 포트에서 수신 대기하고 있습니까? 사용자 지정 포트인 경우 -p를 사용하여 지정해야 합니다.
• 방화벽 규칙: 클라이언트 측 또는 서버 측 방화벽이 포트 22(또는 사용자 지정 SSH 포트)를 차단하고 있습니까? ufw, firewalld 또는 AWS 보안 그룹과 같은 서버 방화벽을 확인하십시오.
  bash 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는 파일 모드에 대해 매우 엄격하므로 권한이 너무 개방된 문제(authorized_keys에 대한 권한 0777)를 명시적으로 나타냅니다.
• 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: 제공된 사용자 이름이 서버에 존재하지 않습니다.
• Publickey authentication refused: authenticate using identity file.: 이는 일반적으로 클라이언트가 제시한 공개 키가 해당 사용자에 대한 서버의 authorized_keys 파일에 있는 키와 일치하지 않거나 키 형식이 잘못되었음을 의미합니다.
• 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(소유자만 읽기/쓰기/실행)이어야 합니다.
    bash chmod 700 ~/.ssh
  • ~/.ssh/authorized_keys: 600(소유자만 읽기/쓰기)이어야 합니다.
    bash chmod 600 ~/.ssh/authorized_keys
  • 이러한 파일 및 디렉터리의 소유자는 로그인하려는 사용자가 되어야 합니다.
    bash sudo chown -R username:username ~/.ssh
• 잘못된 authorized_keys 내용: ~/.ssh/authorized_keys의 공개 키가 손상되었거나, 추가 문자가 있거나, 형식이 잘못되었을 수 있습니다. 각 키는 한 줄에 있어야 합니다. 올바른 형식을 보장하는 빠른 방법은 클라이언트에서 ssh-copy-id를 사용하는 것입니다.
  bash ssh-copy-id -i ~/.ssh/id_rsa.pub username@your_server_ip
  클라이언트 측에서 공개 키 지문(fingerprint)을 확인하려면 다음을 사용하십시오: ssh-keygen -l -f ~/.ssh/id_rsa.pub
• 클라이언트가 키를 제공하지 않음: 개인 키가 기본 위치(~/.ssh/id_rsa)에 없거나, ssh-agent에 로드되지 않았거나, -i로 지정하지 않았을 수 있습니다.
  • 해결 방법: 개인 키가 ~/.ssh에 id_rsa(또는 id_ed25519 등)인지 확인하고 600 권한이 있는지 확인하십시오. 그렇지 않은 경우 다음을 사용하여 지정하십시오.
    bash ssh -i /path/to/your/private_key username@your_server_ip
  • ssh-agent를 사용하는 경우 키가 추가되었는지 확인하십시오.
    bash 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).
• 새 사용자/키로 테스트: 가능한 경우 새 사용자 및 새 공개/개인 키 쌍을 만드십시오. 이 새로운 설정으로 인증을 시도해 보십시오. 작동하면 문제가 원래 사용자의 구성에 고유한 것입니다.
• 문제 격리: 다른 클라이언트 머신에서 연결해 보십시오. 작동하면 문제가 클라이언트별 문제입니다. 여러 클라이언트에서 실패하면 문제가 서버별 문제입니다.
• 로그 레벨 증가(서버 측): 심층 디버깅의 경우 /etc/ssh/sshd_config에서 LogLevel DEBUG를 일시적으로 설정하고 sshd를 다시 시작할 수 있습니다. 디버그 로그는 매우 상세하고 디스크 공간을 차지할 수 있으므로 문제 해결 후 설정을 되돌리는 것을 잊지 마십시오.

결론

SSH 인증 실패를 진단하려면 클라이언트 측 자세한 출력과 서버 측 로그 분석을 결합하는 체계적인 접근 방식이 필요합니다. ssh -vvv 및 SSH 데몬의 로그(auth.log 또는 secure)에서 제공하는 단서를 세심하게 검토하면 잘못된 암호, 잘못 구성된 공개 키, 엄격한 파일 권한 또는 서버 측 설정 등 정확한 실패 지점을 효과적으로 찾을 수 있습니다.

간단한 확인부터 시작하여 클라이언트 측 자세한 출력으로 이동한 다음 최종적으로 서버 로그에서 결정적인 통찰력을 활용하는 것을 기억하십시오. 이러한 기술을 통해 가장 복잡한 SSH 인증 문제까지도 효과적으로 해결하고 원격 시스템에 대한 안전한 액세스를 유지할 수 있습니다.