Debugging QueryPie Web Terminal Server Access Issues

1. 문제 설명 및 에러 메시지

쿼리파이 웹 터미널에서 ID, Password로 서버에 접근할 수 없는 문제가 발생했습니다. 이때 발생하는 에러 메시지는 다음과 같습니다.

쿼리파이 서버 로그에서도 유사한 오류가 확인됩니다:

이 메시지는 SSH 연결 시 인증 단계에서 실패했음을 명확히 보여줍니다. 특히 Authentication failed. Please check the server or authentication information. 부분은 사용자 정보(ID/비밀번호) 또는 서버의 SSH 설정에 문제가 있음을 시사합니다.

2. SSH 인증 방식 이해

SSH(Secure Shell)는 원격 서버에 안전하게 접속하기 위한 프로토콜이며, 다양한 인증 방식을 지원합니다. 여기서는 비밀번호 인증에 초점을 맞추겠습니다.

• Password Authentication (비밀번호 인증): 가장 일반적인 인증 방식으로, 사용자가 입력한 사용자 이름과 비밀번호를 서버가 검증하여 접속을 허용하는 방식입니다. 설정이 간단하여 널리 사용되지만, 비밀번호가 노출되거나 무작위 대입 공격에 취약할 수 있다는 단점이 있습니다.

• keyboard-interactive (대화형 인증): 이 방식은 서버가 사용자에게 하나 이상의 질의(challenge)를 보내고, 사용자가 그에 대한 응답(response)을 입력하는 방식으로 진행됩니다. 일반적인 비밀번호 입력 외에도 OTP(일회성 비밀번호)나 추가 보안 질문 등 다양한 형태의 인증을 지원할 수 있어 유연하지만, 자동화된 도구(웹 터미널 등)가 처리하기 어려운 경우가 있습니다.

3. QueryPie 지원 인증 방식

쿼리파이는 다음과 같은 SSH 인증 방식을 지원합니다.

• ✅ Password Authentication: 일반적인 사용자명/비밀번호 방식

• ✅ Public Key Authentication: SSH 키 기반 인증

• ❌ keyboard-interactive: 대화형 인증 (현재 미지원)

4. 문제 재현 및 진단 (ssh -vvv 로그 분석)

• 대상 서버: al2023-ami-2023.6.20250115.0-kernel-6.1-x86_64

• 쿼리파이 서버: 10.3.2

문제 재현 시도 시 사용한 ssh -vvv 명령의 상세 로그를 통해 문제의 원인을 파악할 수 있습니다.

위 로그에서 중요한 부분은 Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic와 No more authentication methods to try. 입니다.

1. Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic: 이는 원격 SSH 서버(54.180.231.38)가 현재 publickey, gssapi-keyex, gssapi-with-mic 인증 방식만 허용하고 있음을 나타냅니다.

2. debug3: preferred publickey,keyboard-interactive,password: 클라이언트(사용자)가 선호하는 인증 방식의 순서입니다. password 인증을 시도하려고 하지만, 서버에서 허용하지 않고 있습니다.

3. debug1: Next authentication method: publickey: 클라이언트가 서버에서 허용하는 인증 방식 중 publickey를 다음으로 시도하려고 합니다.

4. 결과적으로 debug1: No more authentication methods to try. 메시지는 클라이언트가 시도할 수 있는 모든 인증 방식이 서버에 의해 거부되었음을 의미합니다.

이 로그를 통해 서버의 SSH 설정(sshd_config)에서 비밀번호 인증(PasswordAuthentication)이 no로 설정되어 있거나 비활성화되어 있음을 추정할 수 있습니다.

5. 문제 해결: SSH 설정 수정

비밀번호 인증을 활성화하기 위해 서버의 SSH 설정 파일을 수정해야 합니다.

1. SSH 설정 파일 수정:

   서버에 접속하여 SSH 설정 파일인 /etc/ssh/sshd_config를 편집기로 엽니다.

   sudo vi /etc/ssh/sshd_config

2. PasswordAuthentication 설정 확인 및 변경:

   파일 내에서 PasswordAuthentication 항목을 찾아 yes로 변경하고, PermitEmptyPasswords도 no로 설정합니다. 만약 해당 라인이 주석 처리(#)되어 있다면 주석을 해제합니다.

   # Explicitly disable PasswordAuthentication. By presetting it, we # avoid the cloud-init set_passwords module modifying sshd_config and # restarting sshd in the default instance launch configuration. PasswordAuthentication yes PermitEmptyPasswords no

   • PasswordAuthentication yes: 사용자 이름과 비밀번호를 이용한 인증을 허용합니다.

   • PermitEmptyPasswords no: 빈 비밀번호를 가진 계정의 접속을 허용하지 않습니다. (보안상 필수)

3. SSH 서비스 재시작:

   설정 파일 수정 후, 변경된 내용이 적용되도록 SSH 서비스를 재시작해야 합니다.

   sudo systemctl restart sshd

6. OS 별 SSH 로그 확인 방법

SSH 연결 문제 발생 시 서버의 SSH 로그를 확인하는 것은 매우 중요합니다. OS 배포판에 따라 로그 파일의 위치와 확인 방법이 다를 수 있습니다.

• Linux 배포판별 SSH 로그 파일 위치:

  • /var/log/secure (CentOS, RHEL 등): SSH 인증 관련 로그가 주로 기록됩니다.

  • /var/log/auth.log (Ubuntu, Debian 등): SSH 인증 관련 로그가 주로 기록됩니다.

  • /var/log/ssh.log (일부 배포판): SSH 관련 로그가 기록될 수 있습니다.

• 로그 확인 방법:

  • Amazon Linux 2023: journalctl 명령어를 사용하여 SSHD 서비스의 로그를 실시간으로 확인할 수 있습니다.

    journalctl -fu sshd

  • 다른 Linux 배포판: 일반적으로 cat, tail, grep 등의 명령어를 사용하여 로그 파일을 확인할 수 있습니다. 예를 들어:

    tail -f /var/log/auth.log # Ubuntu/Debian의 경우 tail -f /var/log/secure # CentOS/RHEL의 경우

7. ID, Password로 서버 접근 확인

sshd_config를 수정한 후 쿼리파이 웹 터미널을 통해 다시 ID와 비밀번호로 서버에 접속을 시도하고, 서버의 SSH 로그를 확인합니다.

위 로그에서 Accepted password for ec2-user 메시지가 확인되면 비밀번호 인증이 성공적으로 활성화되어 접속이 가능해진 것입니다.

이 가이드가 쿼리파이 웹 터미널 접속 문제 해결에 도움이 되기를 바랍니다. 추가적인 문제나 궁금한 점이 있으시면 언제든지 문의해주세요.