פתרון בעיות של שגיאות ב-SSH

במסמך הזה מתוארות שגיאות נפוצות שעשויות להתרחש בזמן ההתחברות למכונות וירטואליות (VM) באמצעות SSH, דרכים לפתרון שגיאות ושיטות לאבחון חיבורי SSH שנכשלו.

הכלי לפתרון בעיות ב-SSH

הכלי לפתרון בעיות ב-SSH יכול לעזור לכם לקבוע למה נכשל חיבור SSH. הכלי מריץ את הבדיקות הבאות כדי לבדוק את הסיבה לחיבורי SSH שנכשלו:

  • בדיקות של הרשאות משתמשים: בודקות אם יש לכם את הרשאות ה-IAM הדרושות כדי להתחבר ל-VM באמצעות SSH.
  • בדיקות קישוריות לרשת: בודקות אם המכונה הווירטואלית מחוברת לרשת.
  • בדיקות הסטטוס של מכונה וירטואלית: בודקות את הסטטוס של המעבד (CPU) כדי לראות אם המכונה הווירטואלית פועלת.
  • בדיקות של הגדרות VPC: בודקות את יציאת ה-SSH שמוגדרת כברירת מחדל.

הפעלת הכלי לפתרון בעיות

אתם יכולים להשתמש במסוף Google Cloud או ב-Google Cloud CLI כדי לבדוק אם יש בעיות ברשת או שגיאות בהרשאות המשתמש שעלולות לגרום לחיבורי SSH להיכשל.

במסוף

כשחיבור SSH נכשל, אתם יכולים לבחור באפשרות Retry כדי לנסות להתחבר מחדש, או באפשרות Troubleshoot כדי לפתור את בעיית החיבור באמצעות הכלי לפתרון בעיות SSH בדפדפן.

כדי להפעיל את הכלי, לוחצים על Troubleshoot.

הפעלת הכלי לפתרון בעיות ב-SSH.

ב-gcloud

מריצים את הכלי לפתרון בעיות באמצעות הפקודה gcloud compute ssh:

gcloud compute ssh VM_NAME --troubleshoot [--tunnel-through-iap]

מחליפים את VM_NAME בשם המכונה הווירטואלית שאתם לא מצליחים להתחבר אליה.

משתמשים בדגל --tunnel-through-iap אם מנסים לפתור בעיות בקישוריות דרך שרת proxy לאימות זהויות לצורך העברת TCP.

תתבקשו לספק הרשאה כדי לבצע את הבדיקות לפתרון הבעיות.

עיון בתוצאות

אחרי שמריצים את הכלי לפתרון בעיות:

  1. מעיינים בתוצאות הבדיקה כדי להבין למה חיבור ה-SSH של ה-VM לא עובד.
  2. מבצעים את צעדי התיקון שהכלי סיפק כדי לפתור את הבעיות בחיבורי ה-SSH.

  3. מנסים להתחבר מחדש ל-VM.

    אם החיבור לא מצליח, אפשר לנסות לפתור את הבעיה באופן ידני על ידי ביצוע הפעולות הבאות:

שגיאות נפוצות ב-SSH

בהמשך מפורטות דוגמאות לשגיאות נפוצות שעשויות להתרחש כשמשתמשים ב-SSH כדי להתחבר למכונות הוירטואליות של Compute Engine.

שגיאות ב-SSH בדפדפן

שגיאה – אין הרשאה (401)

יכול להיות שתקבלו את השגיאה הבאה כשאתם מתחברים ל-VM באמצעות SSH בדפדפן ממסוף Google Cloud :

Unauthorized
Error 401

השגיאה הזו מתרחשת אם המשתמש שייך לארגון שמנוהל מתוך Google Workspace, ויש הגבלה פעילה במדיניות Workspace שמונעת ממשתמשים לגשת ל-SSH בדפדפן ולמסוף הטורי ב- Google Cloud.

כדי לפתור את הבעיה, אדמין ב-Google Workspace צריך לבצע את הפעולות הבאות:

  1. מוודאים ש Google Cloud מופעל בארגון.

    אם Google Cloud מושבת, מפעילים אותו ומנסים שוב להתחבר.

  2. מוודאים שהשירותים שאין להם מתג נפרד מופעלים.

    אם השירותים האלה מושבתים, צריך להפעיל אותם ולנסות להתחבר שוב.

אם הבעיה נמשכת אחרי הפעלת Google Cloud ההגדרות ב-Google Workspace, אפשר לנסות את הפעולות הבאות:

  1. תיעוד תעבורת הרשת בקובץ בפורמט HTTP Archive (HAR) החל מהרגע שבו מתחילים את חיבור ה-SSH ב-SSH-in-Browser.

  2. יוצרים בקשת תמיכה ב-Cloud Customer Care ומצרפים את קובץ ה-HAR.

לא ניתן להתחבר, מתבצע ניסיון נוסף...

יכול להיות שתקבלו את השגיאה הבאה כשאתם מפעילים סשן SSH: 

Could not connect, retrying ...

לא הייתה אפשרות להתחבר, מתבצע ניסיון חוזר

כדי לפתור את הבעיה:

  1. אחרי שהפעלת ה-VM תסתיים, נסו להתחבר שוב. אם החיבור לא מצליח, מריצים את הפקודה הבאה כדי לוודא שהמכונה הווירטואלית לא הופעלה במצב חירום:

    gcloud compute instances get-serial-port-output VM_NAME \
| grep "emergency mode"

    אם המכונה הווירטואלית מופעלת במצב חירום, צריך לפתור את הבעיות בתהליך ההפעלה של המכונה הווירטואלית כדי לזהות איפה תהליך האתחול נכשל.

  2. מריצים את הפקודה הבאה במסוף הטורי כדי לוודא ששירותgoogle-guest-agent.service פועל.

    systemctl status google-guest-agent.service

    אם השירות מושבת, מפעילים אותו ומריצים את הפקודות הבאות:

    systemctl enable google-guest-agent.service
systemctl start google-guest-agent.service

  3. מוודאים שהסקריפטים של Linux Google Agent מותקנים ופועלים. מידע נוסף זמין במאמר בנושא קביעת הסטטוס של סוכן Google. אם סוכן Google ל-Linux לא מותקן, צריך להתקין אותו מחדש.

  4. מוודאים שיש לכם את התפקידים הנדרשים כדי להתחבר למכונה הווירטואלית. אם במכונה הווירטואלית שלכם מופעל OS Login, כדאי לעיין במאמר הקצאת תפקיד IAM ל-OS Login. אם במכונה הווירטואלית לא מוגדר OS Login, צריך את תפקיד האדמין של מופע Compute או את תפקיד המשתמש בחשבון שירות (אם המכונה הווירטואלית מוגדרת לפעול כחשבון שירות). התפקידים נדרשים כדי לעדכן את המטא-נתונים של מפתחות ה-SSH של המכונה או הפרויקט.

  5. מריצים את הפקודה הבאה כדי לוודא שיש כלל חומת אש שמאפשר גישת SSH:

    gcloud compute firewall-rules list | grep "tcp:22"

  6. מוודאים שיש נתיב ברירת מחדל לאינטרנט (או למארח bastion). מידע נוסף זמין במאמר בנושא בדיקת מסלולים.

  7. מוודאים שנפח האחסון הבסיסי אינו חורג ממקום בכונן. מידע נוסף זמין במאמר פתרון בעיות שקשורות לדיסקים מלאים ולשינוי גודל הדיסק.

  8. מריצים את הפקודה הבאה כדי לוודא שלא נגמר הזיכרון של מכונת ה-VM:

    gcloud compute instances get-serial-port-output instance-name \
| grep "Out of memory: Kill process" - e "Kill process" -e "Memory cgroup out of memory" -e "oom"

    אם ה-VM לא מצליח להקצות זיכרון, מתחברים למסוף הטורי כדי לפתור את הבעיה.

שגיאות ב-Linux

Permission denied (publickey)‎

ייתכן שתקבלו את השגיאה הבאה כשאתם מתחברים ל-VM:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

לשגיאה יכולות להיות כמה סיבות. פירטנו כאן כמה מהסיבות הנפוצות ביותר:

  • השתמשתם במפתח SSH ששמור במטא-נתונים כדי להתחבר למכונה וירטואלית שמופעל בה השירות OS Login. אם השירות OS Login מופעל בפרויקט, לא תוכלו להתחבר למכונה הווירטואלית באמצעות מפתחות SSH ששמורים במטא-נתונים. לא בטוחים אם OS Login מופעל? איך בודקים שהשירות OS Login מופעל

    כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:

  • השתמשתם במפתח SSH ששמור בפרופיל ב-OS Login כדי להתחבר ל-VM שלא מופעל בה השירות OS Login. אם משביתים את OS Login, אי אפשר להתחבר למכונה הווירטואלית באמצעות מפתחות SSH שנשמרו בפרופיל ב-OS Login. לא בטוחים אם OS Login מופעל? איך בודקים שהשירות OS Login מופעל

    כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:

  • השירות OS Login מופעל במכונה הווירטואלית, אבל אין לכם הרשאות IAM מספיקות כדי להתחבר באמצעות OS Login. כדי להתחבר למכונה וירטואלית שפועל בה השירות OS Login, אתם צריכים את ההרשאות שנדרשות להתחברות באמצעות OS Login. לא בטוחים אם OS Login מופעל? איך בודקים שהשירות OS Login מופעל

    כדי לפתור את הבעיה, צריך להקצות את תפקידי IAM הנדרשים כדי להשתמש ב-OS Login.

  • תוקף המפתח שלכם פג והקובץ ~/.ssh/authorized_keys נמחק ב-Compute Engine. אם הוספתם מפתחות SSH ל-VM באופן ידני, ואז התחברתם ל-VM באמצעות מסוף Google Cloud , מערכת Compute Engine יוצרת לחיבור זוג מפתחות חדש. כשפג התוקף של זוג המפתחות החדש, מערכת Compute Engine מוחקת ב-VM את הקובץ ~/.ssh/authorized_keys, שכולל את מפתח ה-SSH שהוספתם באופן ידני.

    כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:

  • התחברתם באמצעות כלי של צד שלישי ופקודת ה-SSH מוגדרת באופן שגוי. אם התחברתם באמצעות הפקודה ssh אבל לא ציינתם נתיב לקובץ המפתח הפרטי או שציינתם לו נתיב שגוי, בקשת ההתחברות למכונה הווירטואלית תידחה.

    כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:

    • מריצים את הפקודה הבאה:
      ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP

      מחליפים את מה שכתוב בשדות הבאים:
      • PATH_TO_PRIVATE_KEY: זהו הנתיב לקובץ של מפתח ה-SSH הפרטי.
      • USERNAME: זהו שם המשתמש של המשתמש שמתחבר למכונה. אם אתם מנהלים את מפתחות ה-SSH במטא-נתונים, שם המשתמש הוא מה שציינתם כשיצרתם את מפתח ה-SSH. אם אתם משתמשים בחשבונות של OS Login, שם המשתמש מוגדר בפרופיל שלכם ב-Google.
      • EXTERNAL_IP: זוהי כתובת ה-IP החיצונית של ה-VM שלכם.
    • מתחברים ל-VM באמצעות מסוף Google Cloud או Google Cloud CLI. כשמשתמשים בכלים האלה כדי להתחבר, מערכת Compute Engine מנהלת את יצירת המפתחות בשבילכם. מידע נוסף זמין במאמר איך מתחברים למכונות וירטואליות.

  • סביבת האורח ב-VM לא פועלת. אם זו הפעם הראשונה שאתם מתחברים ל-VM, וסביבת האורח לא פועלת, יכול להיות שבקשת ההתחברות למכונה הווירטואלית באמצעות SSH תידחה.

    כדי לפתור את הבעיה:

    1. מפעילים מחדש את ה-VM.
    2. במסוף Google Cloud , בודקים את יומני ההפעלה של המערכת בפלט של היציאה הטורית כדי לקבוע אם סביבת האורח פועלת. מידע נוסף זמין במאמר אימות של סביבת האורח.
    3. אם סביבת האורח לא פועלת, צריך להתקין באופן ידני את סביבת האורח על ידי שכפול דיסק האתחול של ה-VM ושימוש בסקריפט לטעינה בזמן ההפעלה.

  • הדימון (daemon) של OpenSSH‏ (sshd) לא פועל או שהוגדר באופן שגוי. הכלי sshd מספק גישה מאובטחת מרחוק למערכת באמצעות פרוטוקול SSH. אם הוא הוגדר בצורה שגויה או שהוא לא פועל, לא תוכלו להתחבר ל-VM באמצעות SSH.

    כדי לפתור את הבעיה, אפשר לנסות אחד או יותר מהפתרונות הבאים:

    • בודקים במדריך למשתמש את ההגדרות של מערכת ההפעלה שלכם כדי לוודא ש-sshd_config מוגדר בצורה נכונה.

    • מוודאים שיש לכם את הגדרות הבעלות וההרשאות הנדרשות עבור:

      • $HOME וספריות $HOME/.ssh
      • קובץ $HOME/.ssh/authorized_keys

      בעלות

      מפתחות ציבוריים מורשים של SSH מאוחסנים בקובץ $HOME/.ssh/authorized_keys בסביבת האורח. הספריות $HOME ו-$HOME/.ssh והקובץ $HOME/.ssh/authorized_keys צריכים להיות בבעלות של המשתמש שמתחבר ל-VM.

      הרשאות

      צריך לתת לסביבת האורח את הרשאות ה-Linux הבאות:

      נתיב הרשאות
      /home 0755
      $HOME 0700 או 0750 או 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * כדי לברר איזו מהאפשרויות היא הרשאת ברירת המחדל הנכונה לספריית $HOME, כדאי לעיין במסמכים הרשמיים של הפצת Linux הספציפית שלכם.

      אפשרות אחרת היא ליצור מכונה וירטואלית חדשה על סמך אותה תמונה ולבדוק את הרשאות ברירת המחדל שלה עבור $HOME.

      כדי ללמוד איך משנים הרשאות ובעלות, אפשר לקרוא על chmod ועל chown.

    • מפעילים מחדש את sshd באמצעות הפקודה הבאה:

      systemctl restart sshd.service

      מריצים את הפקודה הבאה כדי לבדוק אם יש שגיאות בסטטוס:

      systemctl status sshd.service

      פלט הסטטוס עשוי להכיל מידע כמו קוד היציאה, הסיבה לכישלון וכו'. אפשר להשתמש בפרטים האלה כדי לפתור בעיות נוספות.

  • דיסק האתחול של ה-VM מלא. כשנוצר חיבור SSH, המערכת מוסיפה לקובץ ~/.ssh/authorized_keys את מפתח ה-SSH הציבורי של הסשן בסביבת האורח. אם דיסק האתחול מלא, החיבור נכשל.

    כדי לפתור את הבעיה תוכלו לנסות אחד או יותר מהפתרונות הבאים:

  • ההרשאות או הגדרות הבעלות של הספריות או הקבצים $HOME, ‏$HOME/.ssh ו-$HOME/.ssh/authorized_keys שגויות.

    בעלות

    מפתחות ציבוריים מורשים של SSH מאוחסנים בקובץ $HOME/.ssh/authorized_keys בסביבת האורח. הספריות $HOME ו-$HOME/.ssh והקובץ $HOME/.ssh/authorized_keys צריכים להיות בבעלות של המשתמש שמתחבר ל-VM.

    הרשאות

    צריך לתת לסביבת האורח את הרשאות ה-Linux הבאות:

    נתיב הרשאות
    /home 0755
    $HOME 0700 או 0750 או 0755 *
    $HOME/.ssh 0700
    $HOME/.ssh/authorized_keys 0600

    * כדי לברר איזו מהאפשרויות היא הרשאת ברירת המחדל הנכונה לספריית $HOME, כדאי לעיין במסמכים הרשמיים של הפצת Linux הספציפית שלכם.

    אפשרות אחרת היא ליצור מכונה וירטואלית חדשה על סמך אותה תמונה ולבדוק את הרשאות ברירת המחדל שלה עבור $HOME.

    כדי ללמוד איך משנים הרשאות ובעלות, אפשר לקרוא על chmod ועל chown.

החיבור נכשל

יכול להיות שתקבלו את השגיאות הבאות כשאתם מתחברים ל-VM באמצעות מסוףGoogle Cloud , ה-CLI של gcloud, יעד מבוצר (bastion host) או לקוח מקומי:

  • המסוף: Google Cloud 

    Connection Failed

We are unable to connect to the VM on port 22.

  • ב-CLI של gcloud:

    ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].

  • יעד מבוצר (bastion host) או לקוח מקומי:

    port 22: Connection timed out.

    port 22: Connection refused

לשגיאות האלה יכולות להיות כמה סיבות. פירטנו כאן כמה מהסיבות הנפוצות ביותר:

  • המכונה הווירטואלית מופעלת אבל התהליך sshd עדיין לא פועל. אי אפשר להתחבר למכונה וירטואלית אם היא לא פועלת.

    כדי לפתור את הבעיה, צריך לחכות שהפעלת ה-VM תסתיים ולנסות להתחבר שוב.

  • התהליך sshd פועל ביציאה מותאמת אישית. אם sshd מוגדר לפעול ביציאה שאינה יציאה 22, לא תוכלו להתחבר ל-VM.

    כדי לפתור את הבעיה צריך ליצור כלל בהתאמה אישית של חומת אש, שיאפשר תעבורת tcp ביציאה שבה פועל התהליך sshd, באמצעות הפקודה הבאה:

    gcloud compute firewall-rules create FIREWALL_NAME \
  --allow tcp:PORT_NUMBER

    למידע נוסף על יצירת כללים בהתאמה אישית של חומת האש: יצירת כללים של חומת אש.

  • כלל חומת האש של SSH חסר או שלא מאפשר תעבורת נתונים מ-IAP או מהאינטרנט הציבורי. חיבורי SSH יידחו אם כללי חומת האש לא מאפשרים חיבורים מ-IAP או תעבורת נתונים נכנסת של TCP לטווח כתובות ה-IP‏ 0.0.0.0/0.

    כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:

    • אם אתם משתמשים בשרת proxy לאימות זהויות (IAP) לצורך העברת TCP, עליכם לעדכן את הכלל בהתאמה אישית של חומת האש כך שיאשר תעבורת נתונים מ-IAP. לאחר מכן עליכם לבדוק את הרשאות ה-IAM.

      1. מעדכנים את הכלל המותאם אישית של חומת האש כדי לאפשר תעבורת נתונים מטווח הכתובות 35.235.240.0/20. זהו טווח כתובות ה-IP שמשמש את IAP להעברת TCP. למידע נוסף: יצירת כלל של חומת האש.
      2. נותנים הרשאות לשימוש בהעברת TCP של IAP, אם עדיין לא עשיתם זאת.

    • אם אתם לא משתמשים ב-IAP, עליכם לעדכן את כלל חומת האש בהתאמה אישית כדי שיאפשר תעבורת נתונים נכנסת של SSH.

      1. מעדכנים את כלל חומת האש בהתאמה אישית כך שיאפשר חיבורי SSH נכנסים למכונות וירטואליות.

  • חיבור ה-SSH נכשל לאחר שדרוג הליבה של ה-VM. לאחר עדכון ליבה, המכונה הווירטואלית עלולה להיכנס למצב של תגובה לשגיאת ליבה קריטית. כתוצאה מכך, המכונה הווירטואלית לא תהיה נגישה.

    כדי לפתור את הבעיה:

    1. מחברים את הדיסק למכונה וירטואלית אחרת.
    2. מעדכנים את הקובץ grub.cfg כך שישתמש בגרסה הקודמת של הליבה.
    3. מחברים את הדיסק למכונה הווירטואלית שלא מגיבה.
    4. באמצעות הפקודה gcloud compute instances describe, מוודאים שהסטטוס של ה-VM הואRUNNING.
    5. מתקינים מחדש את הליבה.
    6. מפעילים מחדש את ה-VM.

    לחלופין, אם יצרתם קובץ snapshot של דיסק האתחול לפני השדרוג של ה-VM, אתם יכולים להשתמש ב-snapshot כדי ליצור VM.

  • הדימון (daemon) של OpenSSH‏ (sshd) לא פועל או שהוגדר באופן שגוי. הכלי sshd מספק גישה מאובטחת מרחוק למערכת באמצעות פרוטוקול SSH. אם הוא הוגדר בצורה שגויה או שהוא לא פועל, לא תוכלו להתחבר ל-VM באמצעות SSH.

    כדי לפתור את הבעיה, אפשר לנסות אחד או יותר מהפתרונות הבאים:

    • בודקים במדריך למשתמש את ההגדרות של מערכת ההפעלה שלכם כדי לוודא ש-sshd_config מוגדר בצורה נכונה.

    • מוודאים שיש לכם את הגדרות הבעלות וההרשאות הנדרשות עבור:

      • $HOME וספריות $HOME/.ssh
      • קובץ $HOME/.ssh/authorized_keys

      בעלות

      מפתחות ציבוריים מורשים של SSH מאוחסנים בקובץ $HOME/.ssh/authorized_keys בסביבת האורח. הספריות $HOME ו-$HOME/.ssh והקובץ $HOME/.ssh/authorized_keys צריכים להיות בבעלות של המשתמש שמתחבר ל-VM.

      הרשאות

      צריך לתת לסביבת האורח את הרשאות ה-Linux הבאות:

      נתיב הרשאות
      /home 0755
      $HOME 0700 או 0750 או 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * כדי לברר איזו מהאפשרויות היא הרשאת ברירת המחדל הנכונה לספריית $HOME, כדאי לעיין במסמכים הרשמיים של הפצת Linux הספציפית שלכם.

      אפשרות אחרת היא ליצור מכונה וירטואלית חדשה על סמך אותה תמונה ולבדוק את הרשאות ברירת המחדל שלה עבור $HOME.

      כדי ללמוד איך משנים הרשאות ובעלות, אפשר לקרוא על chmod ועל chown.

    • מפעילים מחדש את sshd באמצעות הפקודה הבאה:

      systemctl restart sshd.service

      מריצים את הפקודה הבאה כדי לבדוק אם יש שגיאות בסטטוס:

      systemctl status sshd.service

      פלט הסטטוס עשוי להכיל מידע כמו קוד היציאה, הסיבה לכישלון וכו'. אפשר להשתמש בפרטים האלה כדי לפתור בעיות נוספות.

  • המכונה הווירטואלית לא פועלת, ואי אפשר להתחבר אליה באמצעות SSH או באמצעות המסוף הטורי. אם המכונה הווירטואלית לא נגישה, יכול להיות שמערכת ההפעלה פגומה. אם דיסק האתחול לא מופעל, אתם יכולים לאבחן את הבעיה. אם אתם רוצים לשחזר מכונה וירטואלית פגומה ולאחזר נתונים, ראו שחזור של מכונה וירטואלית פגומה או שדיסק האתחול מלא.

  • המכונה הווירטואלית מופעלת במצב תחזוקה. כשהמכונה הווירטואלית מופעלת במצב תחזוקה, היא לא מקבלת חיבורי SSH אבל אתם יכולים להתחבר למסוף הטורי של ה-VM ולהתחבר בתור משתמש Root.

    כדי לפתור את הבעיה:

    1. אם לא הגדרתם סיסמת root ל-VM, אתם יכולים להשתמש בסקריפט המטא-נתונים לטעינה בזמן ההפעלה כדי להריץ את הפקודה הבאה במהלך ההפעלה:

      echo 'root:NEW_PASSWORD' | chpasswd

      מחליפים את NEW_PASSWORD בסיסמה שבחרתם.

    2. מפעילים מחדש את ה-VM.

    3. מתחברים למסוף הטורי של ה-VM ומתחברים בתור משתמש Root.

שגיאה בלתי צפויה

יכול להיות שתקבלו את השגיאה הבאה כשאתם מנסים להתחבר למכונת Linux וירטואלית:

Connection Failed
You cannot connect to the VM instance because of an unexpected error. Wait a few moments and then try again.

הבעיה הזו יכולה לקרות מכמה סיבות. פירטנו כאן כמה מהסיבות הנפוצות ביותר לשגיאה הזו:

  • הדימון (daemon) של OpenSSH‏ (sshd) לא פועל או שהוגדר באופן שגוי. הכלי sshd מספק גישה מאובטחת מרחוק למערכת באמצעות פרוטוקול SSH. אם הוא הוגדר בצורה שגויה או שהוא לא פועל, לא תוכלו להתחבר ל-VM באמצעות SSH.

    כדי לפתור את הבעיה, אפשר לנסות אחד או יותר מהפתרונות הבאים:

    • בודקים במדריך למשתמש את ההגדרות של מערכת ההפעלה שלכם כדי לוודא ש-sshd_config מוגדר בצורה נכונה.

    • מוודאים שיש לכם את הגדרות הבעלות וההרשאות הנדרשות עבור:

      • $HOME וספריות $HOME/.ssh
      • קובץ $HOME/.ssh/authorized_keys

      בעלות

      מפתחות ציבוריים מורשים של SSH מאוחסנים בקובץ $HOME/.ssh/authorized_keys בסביבת האורח. הספריות $HOME ו-$HOME/.ssh והקובץ $HOME/.ssh/authorized_keys צריכים להיות בבעלות של המשתמש שמתחבר ל-VM.

      הרשאות

      צריך לתת לסביבת האורח את הרשאות ה-Linux הבאות:

      נתיב הרשאות
      /home 0755
      $HOME 0700 או 0750 או 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * כדי לברר איזו מהאפשרויות היא הרשאת ברירת המחדל הנכונה לספריית $HOME, כדאי לעיין במסמכים הרשמיים של הפצת Linux הספציפית שלכם.

      אפשרות אחרת היא ליצור מכונה וירטואלית חדשה על סמך אותה תמונה ולבדוק את הרשאות ברירת המחדל שלה עבור $HOME.

      כדי ללמוד איך משנים הרשאות ובעלות, אפשר לקרוא על chmod ועל chown.

    • מפעילים מחדש את sshd באמצעות הפקודה הבאה:

      systemctl restart sshd.service

      מריצים את הפקודה הבאה כדי לבדוק אם יש שגיאות בסטטוס:

      systemctl status sshd.service

      פלט הסטטוס עשוי להכיל מידע כמו קוד היציאה, הסיבה לכישלון וכו'. אפשר להשתמש בפרטים האלה כדי לפתור בעיות נוספות.

  • בעיה לא ידועה בדימון SSH. כדי לאבחן בעיה לא ידועה ב-SSH daemon, בודקים את היומנים של המסוף הסדרתי כדי לראות אם יש שגיאות.

    בהתאם לפלט של יומני המסוף הטורי, מנסים לשחזר את המכונה הווירטואלית ולתקן את הבעיות שקשורות לדימון SSH באמצעות הפעולות הבאות:

    1. מחברים את הדיסק למכונת Linux VM אחרת.
    2. מתחברים ל-VM שבו הדיסק מותקן.
    3. מחברים את הדיסק במערכת ההפעלה לספרייה MOUNT_DIR במכונה הווירטואלית.
    4. כדי לראות אם יש בעיות או שגיאות, אפשר לעיין ביומנים שקשורים ל-SSH, /var/log/secure או /var/log/auth.log. אם אתם רואים בעיות שאתם יכולים לתקן, נסו לתקן אותן. אחרת, יוצרים בקשת תמיכה ומצרפים את היומנים.

    5. מנתקים את הדיסק ממערכת ההפעלה באמצעות הפקודה umount:

      cd ~/
umount /mnt

    6. מנתקים את הדיסק מה-VM.

    7. מחברים את הדיסק למכונה הווירטואלית המקורית.

    8. מפעילים את ה-VM.

Failed to connect to backend

יכול להיות שתקבלו את השגיאות הבאות כשאתם מתחברים ל-VM באמצעות מסוףGoogle Cloud או ה-CLI של gcloud:

  • המסוף: Google Cloud 

    -- Connection via Cloud Identity-Aware Proxy Failed

-- Code: 4003

-- Reason: failed to connect to backend

  • ב-CLI של gcloud:

    ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: 'failed to connect to backend'].

השגיאות האלה מתקבלות כשמנסים להשתמש ב-SSH כדי להתחבר למכונה וירטואלית שאין לה כתובת IP ציבורית, ושלא הגדרתם לה שרת proxy לאימות זהויות (IAP) ביציאה 22.

כדי לפתור את הבעיה הזו צריך ליצור כלל של חומת האש ביציאה 22, שמאפשר תעבורת נתונים נכנסת של שרת proxy לאימות זהויות (IAP).

מַפְתח המארח לא תואם

ייתכן שתקבלו את השגיאה הבאה כשאתם מתחברים ל-VM:

Host key for server IP_ADDRESS does not match

השגיאה הזו מתקבלת כשמפתח המארח בקובץ ~/.ssh/known_hosts לא תואם למפתח המארח של ה-VM.

כדי לפתור את הבעיה צריך למחוק את מפתח המארח מהקובץ ~/.ssh/known_hosts, ואז לנסות שוב להתחבר.

הערך למטא-נתונים גדול מדי

השגיאה הבאה עשויה להתקבל כשאתם מנסים להוסיף מפתח SSH חדש למטא-נתונים:

ERROR:"Value for field 'metadata.items[X].value' is too large: maximum size 262144 character(s); actual size NUMBER_OF_CHARACTERS."

לערכי המטא-נתונים יש מגבלה מקסימלית של 256KB‎. כדי לתקן את ההגבלה, נסו אחד מהפתרונות הבאים:

אין שיטות אימות נתמכות זמינות

יכול להיות שתקבלו את השגיאה הבאה כשאתם מתחברים ל-VM:

No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)

השגיאה הזו מתרחשת בדרך כלל בגלל לקוח SSH לא עדכני. יכול להיות שלקוחות SSH ישנים יותר חסרה תמיכה בסוגי מפתחות ECDSA ובאלגוריתמים לגיבוב SHA-2 שנדרשים במכונות וירטואליות חדשות יותר.

לדוגמה, השגיאה הזו מתרחשת אם מנסים להתחבר למכונה וירטואלית של Red Hat Enterprise Linux ‏ (RHEL) באמצעות גרסה של PuTTY שקודמת לגרסה 0.75.

כדי לפתור את השגיאה הזו, צריך לעדכן את לקוח ה-SSH לגרסה היציבה העדכנית ביותר. אחרי שמעדכנים את לקוח ה-SSH, מנסים שוב להתחבר באמצעות SSH.

שגיאות ב-Windows

Permission denied, please try again

ייתכן שתקבלו את השגיאה הבאה כשאתם מתחברים ל-VM:

USERNAME@compute.INSTANCE_ID's password:
Permission denied, please try again.

השגיאה הזו מציינת שהמשתמש שמנסה להתחבר ל-VM לא קיים ב-VM. פירטנו כאן כמה מהסיבות הנפוצות ביותר לשגיאה הזו:

  • גרסת ה-CLI של gcloud לא עדכנית

    אם גרסת ה-CLI של gcloud לא עדכנית, יכול להיות שאתם מנסים להתחבר באמצעות שם משתמש שאינו מוגדר. כדי לפתור את הבעיה, צריך לעדכן את גרסת ה-CLI של gcloud.

  • ניסיתם להתחבר למכונה וירטואלית של Windows שה-SSH לא מופעל בה.

    כדי לפתור את השגיאה, צריך להגדיר את המפתח enable-windows-ssh עם הערך TRUE במטא-נתונים של הפרויקט או של המכונה. למידע נוסף: הגדרת מטא-נתונים בהתאמה אישית.

Permission denied (publickey,keyboard-interactive)‎

ייתכן שתקבלו את השגיאה הבאה כשאתם מתחברים למכונה וירטואלית שלא מופעל בה SSH:

Permission denied (publickey,keyboard-interactive).

כדי לפתור את השגיאה, צריך להגדיר את המפתח enable-windows-ssh עם הערך TRUE במטא-נתונים של הפרויקט או של המכונה. למידע נוסף: הגדרת מטא-נתונים בהתאמה אישית.

Could not SSH into the instance

ייתכן שתקבלו את השגיאה הבאה כשאתם מתחברים ל-VM באמצעות ה-CLI של gcloud:

ERROR: (gcloud.compute.ssh) Could not SSH into the instance.
It is possible that your SSH key has not propagated to the instance yet.
Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.

לשגיאה יכולות להיות כמה סיבות. פירטנו כאן כמה מהסיבות הנפוצות ביותר:

  • אתם מנסים להתחבר למכונה וירטואלית של Windows שלא מותקן בה SSH.

    כדי לפתור את הבעיה, צריך לפעול לפי ההוראות במאמר איך מפעילים SSH ל-Windows במכונת VM פועלת.

  • השרת OpenSSH ‏ (sshd) לא פועל או שהוגדר באופן שגוי. הכלי sshd מספק גישה מאובטחת מרחוק למערכת באמצעות פרוטוקול SSH. אם הוא הוגדר בצורה שגויה או שהוא לא פועל, לא תוכלו להתחבר ל-VM באמצעות SSH.

    כדי לפתור את הבעיה, כדאי לעיין במאמר OpenSSH Server configuration for Windows Server and Windows כדי לוודא שהתהליך sshd מוגדר בצורה נכונה.

תם הזמן הקצוב לתפוגה של החיבור

ייתכן שיתרחשו בעיות של חיבורי SSH שתם הזמן הקצוב שלהם לתפוגה באחד מהמקרים הבאים:

  • הפעלת ה-VM לא הסתיימה. עליכם להמתין זמן קצר עד שתסתיים הפעלת ה-VM.

    כדי לפתור את הבעיה, צריך לחכות שהפעלת ה-VM תסתיים ולנסות להתחבר שוב.

  • חבילת ה-SSH לא מותקנת. במכונות הווירטואליות של Windows חייבים להתקין את החבילה google-compute-engine-ssh כדי להתחבר באמצעות SSH.

    כדי לפתור את הבעיה צריך להתקין את חבילת ה-SSH.

אבחון של חיבורי SSH שנכשלו

בקטעים הבאים מתוארות הפעולות שאפשר לבצע כדי לאבחן את הסיבה לחיבורי SSH שנכשלו, ומה הפעולות שאפשר לעשות כדי לתקן את החיבורים.

לפני שמנסים לאבחן חיבורי SSH שנכשלו, צריך לבצע את השלבים הבאים:

שיטות אבחון למכונות וירטואליות של Windows ו-Linux

בדיקת קישוריות

בעיות בקישוריות שקשורות לחומות האש, לחיבור לרשת או לחשבון המשתמש עלולות למנוע התחברות למכונה הווירטואלית דרך SSH. כדי לזהות בעיות בקישוריות, בצעו את הפעולות המפורטות בסעיף הזה.

בדיקת הכללים של חומת האש

לכל פרויקט ב-Compute Engine מוקצית כברירת מחדל קבוצה של כללים של חומת אש, שמאפשרים תעבורת נתונים דרך SSH. אם אתם לא מצליחים לגשת למכונה, תוכלו להשתמש בכלי שורת הפקודה gcloud compute כדי לבדוק את רשימת חומות האש ולוודא שהכלל default-allow-ssh קיים.

בתחנת העבודה המקומית, מריצים את הפקודה הבאה:

gcloud compute firewall-rules list

אם כלל חומת האש חסר, מוסיפים אותו מחדש:

gcloud compute firewall-rules create default-allow-ssh \
    --allow tcp:22

כדי להציג את כל הנתונים שמשויכים לכלל חומת האש default-allow-ssh בפרויקט, משתמשים בפקודה gcloud compute firewall-rules describe:

gcloud compute firewall-rules describe default-allow-ssh \
    --project=project-id

למידע נוסף על הכללים של חומת האש ב- Google Cloud

בדיקת החיבור לרשת

כדי לבדוק אם החיבור לרשת פועל, בודקים את לחיצת היד של TCP:

  1. משיגים את כתובת ה-natIP החיצונית של ה-VM:

    gcloud compute instances describe VM_NAME \
    --format='get(networkInterfaces[0].accessConfigs[0].natIP)'

    מחליפים את VM_NAME בשם של המכונה הווירטואלית שלא מצליחים להתחבר אליה.

  2. בודקים את חיבור הרשת ל-VM מתחנת העבודה:

    Linux,‏ Windows 2019/2022 ו-macOS 

    curl -vso /dev/null --connect-timeout 5 EXTERNAL_IP:PORT_NUMBER

    מחליפים את מה שכתוב בשדות הבאים:

    • EXTERNAL_IP: זוהי כתובת ה-IP החיצונית שקיבלתם בשלב הקודם
    • PORT_NUMBER: זהו מספר היציאה

    כשלחיצת היד של TCP מסתיימת ללא תקלות, הפלט דומה לפלט הבא:

    Expire in 0 ms for 6 (transfer 0x558b3289ffb0)
Expire in 5000 ms for 2 (transfer 0x558b3289ffb0)
Trying 192.168.0.4...
TCP_NODELAY set
Expire in 200 ms for 4 (transfer 0x558b3289ffb0)
Connected to 192.168.0.4 (192.168.0.4) port 443 (#0)
> GET / HTTP/1.1
> Host: 192.168.0.4:443
> User-Agent: curl/7.64.0
> Accept: */*
>
Empty reply from server
Connection #0 to host 192.168.0.4 left intact

    השורה Connected to מציינת שלחיצת היד של TCP הסתיימה ללא בעיות.

    Windows 2012 ו-2016 

    PS C:> New-Object System.Net.Sockets.TcpClient('EXTERNAL_IP',PORT_NUMBER)

    מחליפים את מה שכתוב בשדות הבאים:

    • EXTERNAL_IP: זוהי כתובת ה-IP החיצונית שקיבלתם בשלב הקודם
    • PORT_NUMBER: זהו מספר היציאה

    כשלחיצת היד של TCP מסתיימת ללא תקלות, הפלט דומה לפלט הבא:

    Available           : 0
Client              : System.Net.Sockets.Socket
Connected           : True
ExclusiveAddressUse : False
ReceiveBufferSize   : 131072
SendBufferSize      : 131072
ReceiveTimeout      : 0
SendTimeout         : 0
LingerState         : System.Net.Sockets.LingerOption
NoDelay             : False

    השורה Connected: True מציינת שלחיצת היד של TCP הסתיימה ללא בעיות.

כשלחיצת היד של TCP מסתיימת ללא בעיות, המשמעות היא שהכלל של תוכנת חומת האש לא חוסם את החיבור, מערכת ההפעלה מעבירה את החבילות בצורה נכונה ויש שרת שמאזין ביציאת היעד. כשלחיצת היד של TCP מסתיימת ללא בעיות, אבל המכונה הווירטואלית לא מקבלת חיבורי SSH, יכול להיות שהבעיה היא שהדימון (daemon) של sshd לא הוגדר בצורה נכונה או לא פועל באופן תקין. כדאי לעיין במדריך למשתמש של מערכת ההפעלה כדי לוודא שהקובץ sshd_config מוגדר בצורה נכונה.

במאמר איך מאתרים כללים של חומת האש שהוגדרו באופן שגוי ב-Google Cloud מוסבר איך להריץ בדיקות קישוריות ולנתח את הגדרות הנתיב של רשת ה-VPC בין שתי מכונות וירטואליות, ואיך לבדוק אם ההגדרות תוכנתו באופן שמאפשר את תעבורת הנתונים.

התחברות בתור משתמש אחר

יכול להיות שהבעיה שמונעת מכם להתחבר מוגבלת לחשבון המשתמש שלכם בלבד. לדוגמה, יכול להיות שההרשאות שמוגדרות בקובץ ~/.ssh/authorized_keys במכונה לא הוגדרו בצורה נכונה עבור המשתמש.

עליכם לנסות להתחבר בתור משתמש אחר באמצעות ה-CLI של gcloud. לשם כך, צריך לציין את השדה ANOTHER_USERNAME בבקשת ה-SSH. פעולה זו תגרום לכלי ה-CLI של gcloud להוסיף את המשתמש החדש למטא-נתונים של הפרויקט ולאפשר את הגישה ל-SSH.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

מחליפים את מה שכתוב בשדות הבאים:

  • ANOTHER_USERNAME זהו שם משתמש שאינו שם המשתמש שלכם
  • VM_NAME זהו שם המכונה הווירטואלית שאליה רוצים להתחבר

ניפוי באגים באמצעות המסוף הטורי

מומלץ לבדוק את היומנים של המסוף הטורי כדי לראות אם יש שגיאות בהתחברות. אתם יכולים לגשת למסוף הטורי בתור משתמש Root מתחנת העבודה המקומית באמצעות הדפדפן. זהו אמצעי גישה שימושי כשאתם לא מצליחים להתחבר באמצעות SSH, או כשלמכונה אין חיבור לרשת. בשני המצבים האלה, עדיין תהיה לכם גישה למסוף הטורי.

כדי להתחבר למסוף הטורי של המכונה הווירטואלית ולפתור את הבעיות ב-VM:

  1. מפעילים את הגישה האינטראקטיבית למסוף הטורי של ה-VM.

  2. במכונות וירטואליות של Linux, מוסיפים ל-VM את הסקריפט לטעינה בזמן ההפעלה הבא כדי לשנות את הסיסמה של משתמש ה-Root. 

    echo root:PASSWORD | chpasswd

    מחליפים את PASSWORD בסיסמה לבחירתכם.

  3. משתמשים במסוף הטורי כדי להתחבר ל-VM.

  4. במכונות וירטואליות של Linux, אחרי שמסיימים לנפות את כל השגיאות צריך להשבית את ההתחברות באמצעות החשבון של משתמש ה-Root: 

    sudo passwd -l root

שיטות אבחון למכונות וירטואליות של Linux

בדיקה של המכונה הווירטואלית מבלי לכבות אותה

לפעמים אי אפשר להתחבר למכונה, אבל היא ממשיכה למלא בצורה נכונה בקשות של תעבורת הנתונים בסביבת הייצור. במקרה כזה, מומלץ לבדוק את הדיסק מבלי להפריע למכונה.

כדי לבדוק את הדיסק ולפתור בעיות:

  1. יוצרים קובץ snapshot של הדיסק כדי לגבות את דיסק האתחול.
  2. יוצרים דיסק אחסון מתמיד (persistent disk) רגיל מתוך קובץ ה-snapshot.
  3. יוצרים מכונה זמנית.
  4. מחברים ומתקינים את דיסק האחסון המתמיד (persistent disk) הרגיל למכונה הזמנית החדשה.

בעזרת התהליך הזה אתם יוצרים רשת מבודדת שמאפשרת רק חיבורי SSH. ההגדרות האלה מונעות השלכות לא מכוונות של המכונה המשוכפלת, כך שלא תפריע לשירותים בסביבות הייצור.

  1. יוצרים רשת VPC חדשה שתארח את המכונה המשוכפלת:

    gcloud compute networks create debug-network

    מחליפים את NETWORK_NAME בשם שרוצים לתת לרשת החדשה.

  2. מוסיפים כלל של חומת האש שמאפשר חיבורי SSH לרשת:

    gcloud compute firewall-rules create debug-network-allow-ssh \
   --network debug-network \
   --allow tcp:22

  3. יוצרים קובץ snapshot של דיסק האתחול.

    gcloud compute disks snapshot BOOT_DISK_NAME \
   --snapshot-names debug-disk-snapshot

    מחליפים את BOOT_DISK_NAME בשם של דיסק האתחול.

  4. יוצרים דיסק חדש באמצעות קובץ ה-snapshot שיצרתם:

    gcloud compute disks create example-disk-debugging \
   --source-snapshot debug-disk-snapshot

  5. יוצרים מכונה חדשה לניפוי באגים ללא כתובת IP חיצונית:

    gcloud compute instances create debugger \
   --network debug-network \
   --no-address

  6. מחברים למכונה את הדיסק שיצרתם לצורך ניפוי הבאגים:

    gcloud compute instances attach-disk debugger \
   --disk example-disk-debugging

  7. פועלים לפי ההוראות במאמר איך מתחברים ל-VM באמצעות יעד מבוצר (bastion host).

  8. אחרי שהתחברתם למכונה לניפוי הבאגים, אתם יכולים לנסות לפתור את הבעיות בה. לדוגמה, אתם יכולים לעיין ביומני של המכונה:

    sudo su -

    mkdir /mnt/VM_NAME

    mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/VM_NAME

    cd /mnt/VM_NAME/var/log

    # Identify the issue preventing ssh from working
ls

    מחליפים את VM_NAME בשם של המכונה הווירטואלית שלא מצליחים להתחבר אליה.

שימוש בסקריפט לטעינה בזמן ההפעלה

אם הפעולות שלמעלה לא עזרו, אתם יכולים ליצור סקריפט לטעינה בזמן ההפעלה כדי לאסוף מידע מיד לאחר שהמכונה מתחילה לפעול. פועלים לפי ההוראות במאמר הפעלת סקריפט לטעינה בזמן ההפעלה.

לאחר מכן, כדי שהשינויים במטא-נתונים ייכנסו לתוקף, צריך לאפס את המכונה באמצעות הפקודה gcloud compute instances reset.

לחלופין, אפשר ליצור מחדש את המכונה על ידי הרצת הסקריפט לטעינה בזמן ההפעלה במצב אבחון:

  1. מריצים את הפקודה gcloud compute instances delete עם הסימון --keep-disks.

    gcloud compute instances delete VM_NAME \
   --keep-disks boot

    מחליפים את VM_NAME בשם של המכונה הווירטואלית שלא מצליחים להתחבר אליה.

  2. מוסיפים מכונה חדשה עם אותו דיסק ומציינים את הסקריפט לטעינה בזמן ההפעלה.

    gcloud compute instances create NEW_VM_NAME \
   --disk name=BOOT_DISK_NAME,boot=yes \
   --metadata startup-script-url URL

    מחליפים את מה שכתוב בשדות הבאים:

    • NEW_VM_NAME זהו השם של המכונה הווירטואלית החדשה שאתם יוצרים
    • BOOT_DISK_NAME זהו השם של דיסק האתחול מה-VM שלא ניתן להתחבר אליה
    • URL זוהי כתובת ה-URL של Cloud Storage של הסקריפט, בפורמט gs://BUCKET/FILE או https://storage.googleapis.com/BUCKET/FILE

שימוש בדיסק במכונה חדשה

אם אתם עדיין צריכים לשחזר נתונים מדיסק האתחול המתמיד, אתם יכולים לנתק את דיסק האתחול ואז לחבר אותו כדיסק משני במכונה חדשה.

  1. מוחקים את המכונה הווירטואלית שלא ניתן להתחבר אליה ושומרים את דיסק האתחול שלה:

    gcloud compute instances delete VM_NAME \
   --keep-disks=boot

    מחליפים את VM_NAME בשם של המכונה הווירטואלית שלא מצליחים להתחבר אליה.

  2. יוצרים מכונה וירטואלית חדשה באמצעות דיסק האתחול של המכונה הווירטואלית הישנה. מציינים את השם של דיסק האתחול של המכונה הווירטואלית שמחקתם הרגע.

  3. מתחברים למכונה הווירטואלית החדשה באמצעות SSH:

    gcloud compute ssh NEW_VM_NAME

    מחליפים את NEW_VM_NAME בשם של המכונה הווירטואלית החדשה.

בדיקה אם דיסק האתחול של ה-VM מלא

אם דיסק האתחול של המכונה הווירטואלית מלא, יכול להיות שלא תצליחו לגשת אליה. התרחיש הזה יכול להיות קשה לפתרון, כי לא תמיד ברור מתי בעיות הקישוריות קשורות לדיסק אתחול מלא. למידע נוסף על התרחיש הזה קראו את המאמר פתרון בעיות במכונה וירטואלית שלא ניתן לגשת אליה עקב דיסק אתחול מלא.

שיטות אבחון למכונות וירטואליות של Windows

איפוס המטא-נתונים של SSH

אם אתם לא מצליחים להתחבר ל-VM של Windows באמצעות SSH, תוכלו לנסות לבטל את ההגדרה של מפתח המטא-נתונים enable-windows-ssh ולהפעיל מחדש את SSH ל-Windows.

  1. מגדירים את מפתח המטא-נתונים enable-windows-ssh לערך FALSE. במאמר הגדרת מטא-נתונים מותאמים אישית מוסבר איך מגדירים מטא-נתונים.

    ממתינים כמה שניות עד שהשינוי ייכנס לתוקף.

  2. מפעילים מחדש את SSH ל-Windows.

  3. מתחברים מחדש ל-VM.

התחברות למכונה הווירטואלית באמצעות RDP

אם אתם לא מצליחים לאבחן ולפתור את הבעיה של חיבורי SSH שנכשלו ב-VM של Windows, אתם יכולים להתחבר באמצעות RDP.

אחרי שאתם יוצרים את החיבור ל-VM, צריך לבדוק את היומנים של OpenSSH.

המאמר הבא