לפתור בעיות שקשורות לגישה
בדף הזה מפורטים טיפים לפתרון בעיות גישה ל-Bare Metal Solution.
בודקים אם השאלה או הבעיה שלכם כבר קיבלו מענה בדף בעיות והגבלות מוכרות.
לקוח SSH לא מצליח להתחבר
אם לקוח ה-SSH שלכם לא מצליח להתחבר לשרת, יכול להיות שתופיע אחת מהשגיאות הבאות:
connection timeoutאוconnection refused: לקוח ה-SSH לא יכול להתחבר.
Permission denied (publickey): לקוח ה-SSH נכשל באימות.
כדי לאבחן חיבורי SSH שנכשלו, פועלים לפי השלבים הבאים:
בודקים את הקישוריות.
מוודאים שאפשר להגיע למארח ושיציאת ה-SSH (מספר 22) פתוחה באמצעות הפקודות
ping,tracerouteו-nc.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:strace ssh SERVER_NAME -i ~/.ssh/id_ecdsa > strace-ssh.txt 2>&1
בודקים את הפלט של
straceכדי לראות אם יש שגיאות שקשורות לבעיה המרכזית.במקרים מסוימים, הפלט של ניפוי הבאגים בצד הלקוח לא מספיק כדי לזהות את הבעיה. יכול להיות שתצטרכו גם להריץ מעקב בצד השרת כדי למצוא את השגיאה. עד שלא תהיה לכם אפשרות להתחבר לשרת באמצעות SSH, תוכלו להשתמש במסוף הטורי האינטראקטיבי כדי לבצע את השלבים הבאים.
בודקים את פלט הניפוי באגים בצד השרת.
מחפשים את הגדרות ה-SSH הנוכחיות.
grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"
כדי לקבל מידע מפורט על SSH, צריך להגדיר את הפרמטרים הבאים בקובץ
/etc/ssh/sshd_config.SyslogFacility AUTH LogLevel DEBUG
כדי להחיל את השינויים, מפעילים מחדש את השירות.
service sshd restart
בצד הלקוח, מריצים את הפקודה
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. יכול להיות שפלט הניפוי באגים בצד השרת ובצד הלקוח יצביע על בעיה כזו. בדרך כלל, הדפים
manו-sshd_configמספקים את הפרטים הדרושים לשמירה על ההגדרה הנדרשת.sshלדוגמה, כדי למצוא את אלגוריתמי החלפת המפתחות או את הצפנים הנתמכים, משתמשים בפקודות הבאות:# Find key exchange algorithms ssh -Q kex # Find the symmetric encryption ciphers ssh -Q cipher