.. .. ..
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).
[[["容易理解","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 (世界標準時間)。"],[[["\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 ```"]]
