SSH 접속 시 "Permission denied" 에러 완벽 해결 가이드 (원인 분석 & 단계별 조치)

SSH 접속 시 "Permission denied" 에러 완벽 해결 가이드 (원인 분석 & 단계별 조치)

SSH 접속 시 "Permission denied" 에러 완벽 해결 가이드

SSH(Secure Shell)는 원격 서버에 안전하게 접속하기 위한 필수적인 프로토콜입니다. 하지만 SSH 접속 시 "Permission denied" 에러가 발생하여 난감한 상황에 직면할 수 있습니다. 이 글에서는 SSH 접속 시 흔히 발생하는 "Permission denied" 에러의 원인을 분석하고, 단계별 해결 방법을 제시하여 문제 해결을 돕고자 합니다.

목차

• 에러 현상
• 원인 분석
  • 1. 잘못된 사용자 이름 또는 암호 입력
  • 2. SSH 서버 설정 오류
  • 3. 공개 키 인증 설정 문제
  • 4. PAM (Pluggable Authentication Modules) 설정 오류
• 해결 방법
  • 1. 정확한 사용자 이름과 암호 입력
  • 2. SSH 서버 설정 확인 및 수정
  • 3. 공개 키 인증 설정 점검
  • 4. PAM 설정 확인
  • 5. SSH 클라이언트 설정 확인
• 예방 조치
• FAQ

에러 현상

다음과 같은 에러 메시지가 표시되며 SSH 접속에 실패합니다.

ssh user@contoso.com
user@contoso.com: Permission denied (publickey,password,keyboard-interactive).

또는

ssh user@contoso.com
Permission denied, please try again.
Permission denied, please try again.
user@contoso.com: Permission denied (publickey,password,keyboard-interactive).

발생 환경:

• OS: Ubuntu 20.04, CentOS 7
• SSH 클라이언트: OpenSSH, PuTTY
• 상황: 서버에 처음 접속하거나, 기존에 잘 되던 접속이 갑자기 안 되는 경우

원인 분석

"Permission denied" 에러는 다양한 원인으로 발생할 수 있습니다. 주요 원인과 빈도 순으로 분석해 보겠습니다.

1. 잘못된 사용자 이름 또는 암호 입력

가장 흔한 원인은 SSH 접속 시 사용자 이름 또는 암호를 잘못 입력하는 경우입니다. Caps Lock 키가 켜져 있거나, 오타가 발생했을 가능성이 높습니다. 특히 암호가 복잡한 경우 실수가 발생하기 쉽습니다.

2. SSH 서버 설정 오류

sshd_config 파일의 설정이 잘못되어 인증 방식이 제한되었거나, 특정 사용자의 접속이 거부되었을 수 있습니다. 예를 들어, PermitRootLogin no 설정으로 인해 root 사용자의 직접 접속이 막혀 있을 수 있습니다. 또한, PasswordAuthentication no 설정으로 인해 암호 인증 방식이 비활성화되었을 수도 있습니다.

3. 공개 키 인증 설정 문제

공개 키 인증 방식을 사용하는 경우, 클라이언트의 공개 키가 서버의 ~/.ssh/authorized_keys 파일에 제대로 등록되어 있지 않거나, 키 파일의 권한 설정이 잘못되었을 수 있습니다. 또한, SSH 클라이언트가 올바른 개인 키를 사용하지 못하는 경우에도 에러가 발생할 수 있습니다.

4. PAM (Pluggable Authentication Modules) 설정 오류

PAM은 시스템 인증을 관리하는 모듈로, SSH 인증에도 관여합니다. PAM 설정 파일(/etc/pam.d/sshd)에 오류가 있거나, 특정 사용자에 대한 인증 규칙이 잘못 설정된 경우 "Permission denied" 에러가 발생할 수 있습니다.

해결 방법

1. 정확한 사용자 이름과 암호 입력

• 가장 먼저 사용자 이름과 암호를 다시 한번 확인합니다. Caps Lock 키가 켜져 있는지, 오타는 없는지 꼼꼼히 확인합니다.
• 만약 암호를 잊어버린 경우, 서버 관리자에게 문의하여 암호를 초기화하거나, SSH 키 기반 인증 방식으로 변경하는 것을 고려해 볼 수 있습니다.

2. SSH 서버 설정 확인 및 수정

• sshd_config 파일을 확인하여 인증 관련 설정을 점검합니다. 다음 명령어를 사용하여 파일을 엽니다.

  bash sudo vi /etc/ssh/sshd_config

• 다음 설정들을 확인하고 필요에 따라 수정합니다.

  • PermitRootLogin yes (root 사용자 접속 허용 여부)
  • PasswordAuthentication yes (암호 인증 허용 여부)
  • PubkeyAuthentication yes (공개 키 인증 허용 여부)
  • AuthorizedKeysFile .ssh/authorized_keys (공개 키 파일 경로)
  • MaxAuthTries 6 (최대 인증 시도 횟수, 필요에 따라 조정)

• 설정 변경 후 SSH 서비스를 재시작합니다.

  bash sudo systemctl restart sshd

• 실행 전 확인: sshd_config 파일 백업 (예: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak)

• 실행 후 확인: sudo systemctl status sshd 명령어로 SSH 서비스 상태 확인

3. 공개 키 인증 설정 점검

• 클라이언트의 공개 키가 서버의 ~/.ssh/authorized_keys 파일에 등록되어 있는지 확인합니다. 공개 키는 ssh-keygen 명령어를 사용하여 생성할 수 있습니다.

  bash ssh-keygen -t rsa -b 4096

• 생성된 공개 키(~/.ssh/id_rsa.pub)의 내용을 서버의 ~/.ssh/authorized_keys 파일에 복사합니다. ssh-copy-id 명령어를 사용하면 편리하게 복사할 수 있습니다.

  bash ssh-copy-id user@contoso.com

• ~/.ssh 디렉토리와 ~/.ssh/authorized_keys 파일의 권한 설정이 올바른지 확인합니다. 다음 명령어를 사용하여 권한을 설정합니다.

  bash chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys

• 실행 전 확인: ls -ld ~/.ssh 및 ls -l ~/.ssh/authorized_keys 명령어로 현재 권한 확인

• 실행 후 확인: 위 명령어를 다시 실행하여 변경된 권한 확인

4. PAM 설정 확인

• /etc/pam.d/sshd 파일을 확인하여 PAM 설정에 오류가 없는지 점검합니다. 특히 auth 및 account 섹션의 설정들을 주의 깊게 살펴봅니다.
• 특정 사용자에 대한 인증 규칙이 잘못 설정된 경우, 해당 규칙을 수정하거나 제거합니다.
• 실행 전 확인: /etc/pam.d/sshd 파일 백업 (예: sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.bak)
• 실행 후 확인: SSH 접속 재시도하여 인증 성공 여부 확인

5. SSH 클라이언트 설정 확인

• 만약 PuTTY를 사용하는 경우, Connection -> SSH -> Auth 메뉴에서 올바른 개인 키 파일(.ppk)이 선택되었는지 확인합니다.
• OpenSSH를 사용하는 경우, ~/.ssh/config 파일에서 호스트별 설정을 확인합니다. 특히 IdentityFile 옵션이 올바른 개인 키 파일을 가리키고 있는지 확인합니다.

예방 조치

• 모니터링 스크립트: SSH 접속 실패 횟수를 모니터링하는 스크립트를 작성하여 주기적으로 실행하고, 비정상적인 활동이 감지되면 관리자에게 알림을 보내도록 설정합니다.

  ```bash

  !/bin/bash

  LOG_FILE=/var/log/auth.log
  THRESHOLD=5
  FAILED_ATTEMPTS=$(grep "Failed password" $LOG_FILE | awk '{print $11}' | sort | uniq -c | sort -nr | awk '$1 > '$THRESHOLD'{print $2, $1}')
  if [ -n "$FAILED_ATTEMPTS" ]; then
  echo "Possible SSH brute-force attack detected: $FAILED_ATTEMPTS" | mail -s "SSH Attack Alert" admin@contoso.com
  fi
  ```

• 자동화 팁: Ansible 등의 자동화 도구를 사용하여 sshd_config 파일을 일관성 있게 관리하고, 새로운 서버에 SSH 설정을 자동으로 적용합니다.

• 알림 설정: Fail2ban과 같은 침입 방지 시스템을 사용하여 SSH 공격을 자동으로 차단하고, 관리자에게 알림을 보냅니다. Fail2ban은 SSH 로그를 분석하여 비정상적인 접속 시도를 감지하고, 해당 IP 주소를 방화벽에 추가하여 접속을 차단합니다.

FAQ

• Q: SSH 접속 시 "Received disconnect from xxx.xxx.xxx.xxx: 2: Too many authentication failures for user" 에러가 발생합니다. 어떻게 해결해야 하나요?
  • A: 이 에러는 SSH 서버가 설정된 최대 인증 시도 횟수를 초과했기 때문에 발생합니다. sshd_config 파일에서 MaxAuthTries 설정을 조정하거나, SSH 클라이언트 설정을 변경하여 시도 횟수를 늘릴 수 있습니다. 하지만 보안상의 이유로 무분별하게 횟수를 늘리는 것은 권장하지 않습니다.
• Q: SSH 키 파일을 안전하게 관리하는 방법은 무엇인가요?
  • A: SSH 키 파일은 매우 민감한 정보이므로, 안전하게 관리해야 합니다. 개인 키 파일은 절대로 다른 사람과 공유하지 말고, 권한 설정을 통해 본인만 읽고 쓸 수 있도록 제한해야 합니다. 또한, 암호화된 키 파일을 사용하여 보안을 강화할 수 있습니다.
• Q: SSH 접속 시 "Connection refused" 에러가 발생합니다. 어떻게 해결해야 하나요?
  • A: 이 에러는 SSH 서버가 실행되고 있지 않거나, 방화벽 설정으로 인해 SSH 접속이 차단되었을 때 발생합니다. SSH 서버가 실행 중인지 확인하고, 방화벽 설정을 점검하여 SSH 포트(기본적으로 22번)가 열려 있는지 확인해야 합니다. sudo systemctl status sshd 명령어를 사용하여 SSH 서비스 상태를 확인할 수 있습니다.

---

관련 글

• VPN 연결 오류 해결
• 쿠버네티스 Pod CrashLoopBackOff 해결
• SSL 인증서 오류 해결 방법
• IAM이란 무엇인가
• Azure AD vs Okta 비교