Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Memecahkan masalah akses
Halaman ini memberikan tips pemecahan masalah untuk masalah akses Solusi Bare Metal.
Periksa apakah pertanyaan atau masalah Anda telah ditangani di
halaman Masalah umum dan batasan.
Klien SSH tidak dapat terhubung
Jika klien SSH gagal terhubung ke server, Anda mungkin melihat salah satu error berikut:
connection timeout atau connection refused: Klien SSH tidak dapat terhubung.
Permission denied (publickey): Klien SSH gagal melakukan autentikasi.
Untuk mendiagnosis koneksi SSH yang gagal, ikuti langkah-langkah berikut:
Menguji konektivitas.
Pastikan host dapat dijangkau dan port SSH (22) terbuka menggunakan perintah ping, traceroute, dan nc.
ping SERVER_NAME
traceroute SERVER_NAME
echo "" | nc SERVER_NAME 22
Jika tidak berhasil, masalahnya mungkin ada di lapisan jaringan, bukan
pada SSH.
Periksa output debug sisi klien.
Aktifkan panjang protokol SSH.
ssh -v SERVER_NAME -i ~/.ssh/id_ecdsa
Perintah ini mencetak output debug yang menampilkan peristiwa utama
protokol SSH sisi klien.
Contoh output berikut menunjukkan bahwa
klien mengirim kuncinya, tetapi server menolaknya. Server meminta
autentikasi untuk melanjutkan dengan kunci publik lain, tetapi klien tidak memiliki
kunci tambahan untuk ditawarkan.
.. .. ..
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).
Jika output panjang SSH tidak menunjukkan dengan jelas
penyebab pesan error, jalankan perintah strace:
Periksa output strace untuk menemukan error yang terkait dengan masalah
inti.
Dalam beberapa kasus, output debug sisi klien tidak cukup untuk mengidentifikasi
masalah. Anda mungkin juga perlu menjalankan pelacakan sisi server untuk menemukan error. Sampai Anda dapat menggunakan SSH ke server, gunakan
konsol serial interaktif
untuk melakukan langkah berikutnya.
Periksa output debug sisi server.
Temukan setelan SSH saat ini.
grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"
Untuk mendapatkan informasi mendetail tentang SSH, tetapkan parameter berikut
dalam file /etc/ssh/sshd_config untuk mendapatkan informasi mendetail.
SyslogFacility AUTH
LogLevel DEBUG
Untuk menerapkan perubahan, mulai ulang layanan.
service sshd restart
Di sisi klien, jalankan perintah ssh dan ekstrak pesan sshd dari log:
grep sshd /var/log/messages
Atau, Anda dapat mengekspor semua pesan yang relevan untuk jangka waktu tersebut menggunakan
perintah berikut:
Untuk memperbaiki masalah ini, pertimbangkan langkah-langkah berikut:
Verifikasi apakah file kunci klien ditetapkan dengan izin hanya baca (flag 400).
Jika tidak, klien SSH tidak akan menerimanya.
Untuk menetapkan tanda hanya baca untuk kunci pribadi yang sedang digunakan, jalankan perintah
berikut:
chmod 400 ~/.ssh/id_ed25519
Di sisi server, periksa apakah kunci publik klien ditentukan dalam file konfigurasi lokal pengguna yang sesuai (~/.ssh/authorized_keys).
Dalam beberapa kasus, masalah mungkin terkait dengan versi protokol SSH atau
algoritma SSH. Output debug sisi server dan sisi klien mungkin
menunjukkan masalah tersebut. Biasanya, halaman man untuk ssh dan
sshd_config memberikan detail untuk mempertahankan konfigurasi
yang diperlukan. Misalnya, untuk menemukan algoritma pertukaran kunci atau
cipher yang didukung, gunakan perintah berikut:
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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 ```"]]
