호스트에 연결할 수 있고 ping, traceroute, nc 명령어를 사용하여 SSH 포트(22)가 열려 있는지 확인합니다.
ping SERVER_NAME
traceroute SERVER_NAME
echo "" | nc SERVER_NAME 22
그래도 문제가 해결되지 않으면 SSH가 아닌 네트워킹 레이어에 문제가 있을 수 있습니다.
클라이언트 측 디버그 출력을 검토합니다.
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).
SSH 세부정보 수준 출력에 오류 메시지의 원인이 명확하게 표시되지 않으면 strace 명령어를 실행합니다.
클라이언트 키 파일이 읽기 전용 권한(400 플래그)으로 설정되어 있는지 확인합니다. 그렇지 않으면 SSH 클라이언트가 허용하지 않습니다.
사용 중인 비공개 키에 읽기 전용 플래그를 설정하려면 다음 명령어를 실행합니다.
chmod 400 ~/.ssh/id_ed25519
서버 측에서 클라이언트 공개 키가 해당 사용자의 로컬 구성 파일(~/.ssh/authorized_keys)에 지정되어 있는지 확인합니다.
경우에 따라 문제가 SSH 프로토콜 버전 또는 SSH 알고리즘과 관련이 있을 수 있습니다. 서버 측과 클라이언트 측 디버그 출력은 이러한 문제를 나타낼 수 있습니다. 일반적으로 ssh 및 sshd_config의 man 페이지에서는 필요한 구성을 유지하기 위한 세부정보를 제공합니다. 예를 들어 지원되는 키 교환 알고리즘 또는 암호화를 찾으려면 다음 명령어를 사용합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eThis guide helps troubleshoot SSH connection failures to Bare Metal Solution servers, specifically addressing issues like \u003ccode\u003econnection timeout\u003c/code\u003e, \u003ccode\u003econnection refused\u003c/code\u003e, and \u003ccode\u003ePermission denied (publickey)\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eTroubleshooting steps include testing host reachability and port 22 accessibility using \u003ccode\u003eping\u003c/code\u003e, \u003ccode\u003etraceroute\u003c/code\u003e, and \u003ccode\u003enc\u003c/code\u003e commands, and checking for networking layer issues.\u003c/p\u003e\n"],["\u003cp\u003eClient-side diagnosis involves enabling verbose SSH output with \u003ccode\u003essh -v\u003c/code\u003e and using \u003ccode\u003estrace\u003c/code\u003e for detailed error analysis if the verbose output is insufficient.\u003c/p\u003e\n"],["\u003cp\u003eServer-side diagnosis involves checking SSH settings, enabling detailed logging by modifying \u003ccode\u003e/etc/ssh/sshd_config\u003c/code\u003e, and examining logs using \u003ccode\u003egrep\u003c/code\u003e or \u003ccode\u003ejournalctl\u003c/code\u003e for relevant \u003ccode\u003esshd\u003c/code\u003e messages.\u003c/p\u003e\n"],["\u003cp\u003eResolutions include ensuring client key files have read-only permissions, verifying the client's public key is in the server's \u003ccode\u003eauthorized_keys\u003c/code\u003e file, and addressing potential SSH protocol or algorithm mismatches.\u003c/p\u003e\n"]]],[],null,["# Troubleshoot access issues\n==========================\n\nThis page provides troubleshooting tips for Bare Metal Solution access issues.\n\nCheck if your question or problem has already been addressed on the\n[Known issues and limitations](/bare-metal/docs/known-issues) page.\n\nSSH client unable to connect\n----------------------------\n\nIf your SSH client fails to connect to a server, you might see one of the\nfollowing errors:\n\n- `connection timeout` or `connection refused`: The SSH client can't connect.\n\n- `Permission denied (publickey)`: The SSH client fails to authenticate.\n\nTo diagnose failed SSH connections, follow these steps:\n\n1. Test connectivity.\n\n Ensure that the host is reachable and that the SSH port (22) is open\n using `ping`, `traceroute`, and `nc` commands. \n\n ```\n ping SERVER_NAME\n ``` \n\n ```\n traceroute SERVER_NAME\n ``` \n\n ```\n echo \"\" | nc SERVER_NAME 22\n ```\n\n If this does not work, then the issue might be in the networking layer and\n not with the SSH.\n2. Examine the client side debug output.\n\n 1. Turn on the verbosity of the SSH protocol.\n\n ```\n ssh -v SERVER_NAME -i ~/.ssh/id_ecdsa\n ```\n\n The command prints the debug output that shows the key events of the\n client side SSH protocol.\n\n The following example output shows that the\n client sent its key, but the server rejected it. The server asked the\n authentication to continue with another public key, but the client has no\n additional keys to offer. \n\n ```\n .. .. ..\n debug1: Server host key: ecdsa-sha2-nistp256 SHA256:V9cRYdqcAJv+RPfN+oofNTVdUxs6VlocP4uMWOxeGKI\n debug1: Host 'bms-server' is known and matches the ECDSA host key.\n debug1: Found key in /root/.ssh/known_hosts:1\n debug1: rekey after 134217728 blocks\n debug1: SSH2_MSG_NEWKEYS sent\n debug1: expecting SSH2_MSG_NEWKEYS\n debug1: SSH2_MSG_NEWKEYS received\n debug1: rekey after 134217728 blocks\n debug1: SSH2_MSG_EXT_INFO received\n debug1: kex_input_ext_info: server-sig-algs=\n debug1: SSH2_MSG_SERVICE_ACCEPT received\n debug1: Authentications that can continue: publickey\n debug1: Next authentication method: publickey\n debug1: Offering ECDSA public key: /root/.ssh/id_ecdsa\n debug1: Authentications that can continue: publickey\n debug1: No more authentication methods to try.\n Permission denied (publickey).\n ```\n 2. If the SSH verbose output does not clearly indicate the\n cause of the error message, run the `strace` command:\n\n ```\n strace ssh SERVER_NAME -i ~/.ssh/id_ecdsa \u003e strace-ssh.txt 2\u003e&1\n ```\n 3. Examine the `strace` output for errors related to the core\n problem.\n\n In some cases, the client side debug output is not enough to identify the\n problem. You might also need to run server side tracing to find the\n error. Until you can't SSH into your server, use the\n [interactive serial console](/bare-metal/docs/troubleshooting/configure-serial-console)\n to perform the next steps.\n3. Examine the server side debug output.\n\n 1. Find the current SSH settings.\n\n ```\n grep -v \"^#\" /etc/ssh/sshd_config | grep -v \"^$\"\n ```\n 2. To obtain detailed information about SSH, set the following parameters\n in `/etc/ssh/sshd_config` file to obtain detailed information.\n\n ```\n SyslogFacility AUTH\n LogLevel DEBUG\n ```\n 3. To apply the changes, restart the service.\n\n ```\n service sshd restart\n ```\n 4. At the client side, run the `ssh` command and extract the\n `sshd` messages from the logs:\n\n ```\n grep sshd /var/log/messages\n ```\n\n Or, you can export all relevant messages for the time period using the\n following command: \n\n ```\n journalctl -u sshd -S \"START_TIME\" -U \"END_TIME\" --utc\n ```\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003e\u003ccode translate=\"no\" dir=\"ltr\"\u003eSTART_TIME\u003c/code\u003e\u003c/var\u003e: The start time of the time period in format `yyyy-mm-dd hh:mm:ss`.\n - \u003cvar translate=\"no\"\u003e\u003ccode translate=\"no\" dir=\"ltr\"\u003eEND_TIME\u003c/code\u003e\u003c/var\u003e: The end time of the time period in format `yyyy-mm-dd hh:mm:ss`.\n\n Example: \n\n ```\n journalctl -u sshd -S \"2023-04-25 18:38:00\" -U \"2023-04-25 18:40:00\" --utc\n ```\n\nTo fix these issues, consider the following steps:\n\n- Verify if the client key file is set with read-only permissions (flag `400`).\n Otherwise, the SSH client does not accept it.\n\n To set the read-only flag for the private key that's in use, run the following\n command: \n\n ```\n chmod 400 ~/.ssh/id_ed25519\n ```\n- At the server side, check if the client public key is specified in the\n corresponding user's local configuration file (`~/.ssh/authorized_keys`).\n\n- In some cases, the problem might be related to the SSH protocol version or the\n SSH algorithm. The server side and the client side debug outputs might\n indicate such a problem. Typically, the `man` pages for `ssh` and\n `sshd_config` provide the details for maintaining the necessary\n configuration. For example, to find the key exchange algorithms or\n ciphers that are supported, use the following commands:\n\n ```\n # Find key exchange algorithms\n ssh -Q kex\n # Find the symmetric encryption ciphers\n ssh -Q cipher\n ```"]]
