액세스 문제 해결

이 페이지에서는 베어메탈 솔루션 액세스 문제의 문제 해결 팁을 제공합니다.

알려진 문제 및 제한사항 페이지에서 질문 또는 문제가 이미 해결되었는지 확인하세요.

SSH 클라이언트를 연결할 수 없음

SSH 클라이언트가 서버에 연결되지 않는 경우 다음 오류 중 하나가 표시될 수 있습니다.

  • connection timeout 또는 connection refused: SSH 클라이언트를 연결할 수 없습니다.

  • Permission denied (publickey): SSH 클라이언트가 인증에 실패합니다.

실패한 SSH 연결을 진단하려면 다음 단계를 수행합니다.

  1. 연결을 테스트합니다.

    호스트에 연결할 수 있고 ping, traceroute, nc 명령어를 사용하여 SSH 포트(22)가 열려 있는지 확인합니다.

    ping SERVER_NAME

    traceroute SERVER_NAME

    echo "" | nc SERVER_NAME 22

    그래도 문제가 해결되지 않으면 SSH가 아닌 네트워킹 레이어에 문제가 있을 수 있습니다.

  2. 클라이언트 측 디버그 출력을 검토합니다.

    1. SSH 프로토콜의 세부정보 수준을 설정합니다.

      ssh -v SERVER_NAME -i ~/.ssh/id_ecdsa

      이 명령어는 클라이언트 측 SSH 프로토콜의 주요 이벤트를 보여주는 디버그 출력을 출력합니다.

      다음 예시 출력은 클라이언트가 키를 전송했지만 서버가 키를 거부했음을 보여줍니다. 서버가 다른 공개 키를 계속 사용하도록 인증을 요청했지만 클라이언트에 제공할 추가 키가 없습니다.

      .. .. ..
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:V9cRYdqcAJv+RPfN+oofNTVdUxs6VlocP4uMWOxeGKI
debug1: Host 'bms-server' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering ECDSA public key: /root/.ssh/id_ecdsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

    2. SSH 세부정보 수준 출력에 오류 메시지의 원인이 명확하게 표시되지 않으면 strace 명령어를 실행합니다.

      strace ssh SERVER_NAME -i ~/.ssh/id_ecdsa > strace-ssh.txt 2>&1

    3. strace 출력에서 핵심 문제와 관련된 오류가 있는지 확인합니다.

      경우에 따라 클라이언트 측 디버그 출력으로 문제를 식별하기에 충분하지 않을 수 있습니다. 오류를 찾으려면 서버 측 추적을 실행해야 할 수도 있습니다. SSH로 서버에 연결할 수 없을 때까지 대화형 직렬 콘솔을 사용하여 다음 단계를 수행합니다.

  3. 서버 측 디버그 출력을 검토합니다.

    1. 현재 SSH 설정을 찾습니다.

      grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"

    2. SSH에 대한 자세한 정보를 보려면 /etc/ssh/sshd_config 파일에 다음 매개변수를 설정하여 자세한 정보를 가져옵니다.

      SyslogFacility AUTH
LogLevel DEBUG

    3. 변경사항을 적용하려면 서비스를 다시 시작합니다.

      service sshd restart

    4. 클라이언트 측에서 ssh 명령어를 실행하고 로그에서 sshd 메시지를 추출합니다.

      grep sshd /var/log/messages

      또는 다음 명령어를 사용하여 해당 기간 동안의 모든 관련 메시지를 내보낼 수 있습니다.

      journalctl -u sshd -S "START_TIME" -U "END_TIME" --utc

      다음을 바꿉니다.

      • START_TIME: yyyy-mm-dd hh:mm:ss 형식인 사용 기간의 시작 시간입니다.
      • END_TIME: yyyy-mm-dd hh:mm:ss 형식인 사용 기간의 종료 시간입니다.

      예:

      journalctl -u sshd -S "2023-04-25 18:38:00" -U "2023-04-25 18:40:00" --utc

이러한 문제를 해결하려면 다음 단계를 고려하세요.

  • 클라이언트 키 파일이 읽기 전용 권한(400 플래그)으로 설정되어 있는지 확인합니다. 그렇지 않으면 SSH 클라이언트가 허용하지 않습니다.

    사용 중인 비공개 키에 읽기 전용 플래그를 설정하려면 다음 명령어를 실행합니다.

    chmod 400 ~/.ssh/id_ed25519

  • 서버 측에서 클라이언트 공개 키가 해당 사용자의 로컬 구성 파일(~/.ssh/authorized_keys)에 지정되어 있는지 확인합니다.

  • 경우에 따라 문제가 SSH 프로토콜 버전 또는 SSH 알고리즘과 관련이 있을 수 있습니다. 서버 측과 클라이언트 측 디버그 출력은 이러한 문제를 나타낼 수 있습니다. 일반적으로 ssh 및 sshd_config의 man 페이지에서는 필요한 구성을 유지하기 위한 세부정보를 제공합니다. 예를 들어 지원되는 키 교환 알고리즘 또는 암호화를 찾으려면 다음 명령어를 사용합니다.

    # Find key exchange algorithms
ssh -Q kex
# Find the symmetric encryption ciphers
ssh -Q cipher