‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

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

ההרשאות שנדרשות למשימה הזו

כדי לבצע את המשימה הזו נדרשות ההרשאות הבאות:

ההרשאה networkmanagement.connectivitytests.create ב-VM
ההרשאה networkmanagement.connectivitytests.delete ב-VM
ההרשאה networkmanagement.connectivitytests.get ב-VM

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

במסוף

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

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

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

ב-gcloud

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

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

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

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

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

עיון בתוצאות

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

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

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

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

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

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

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

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

Unauthorized
Error 401

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

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

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

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

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

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

מתעדים את התנועה ברשת בקובץ בפורמט HTTP Archive ‏ (HAR), החל מהרגע שבו מתחילים את חיבור ה-SSH ב-SSH-in-Browser.
יוצרים בקשת תמיכה ב-Cloud Customer Care ומצרפים את קובץ ה-HAR.

החיבור נכשל, מתבצע ניסיון נוסף…

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

Could not connect, retrying ...

החיבור נכשל, המערכת מנסה שוב

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

אחרי שהפעלת ה-VM תסתיים, נסו להתחבר שוב. אם החיבור לא מצליח, מריצים את הפקודה הבאה כדי לוודא שהמכונה הווירטואלית לא הופעלה במצב חירום:
```
gcloud compute instances get-serial-port-output VM_NAME \
| grep "emergency mode"
```
אם המכונה הווירטואלית מופעלת במצב חירום, פותרים את הבעיות בתהליך ההפעלה של המכונה הווירטואלית כדי לזהות איפה תהליך ההפעלה נכשל.
כדי לוודא שהשירות google-guest-agent.service פועל, מריצים את הפקודה הבאה בקונסולה הטורית.
```
systemctl status google-guest-agent.service
```
אם השירות מושבת, מפעילים אותו ומריצים את הפקודות הבאות:
```
systemctl enable google-guest-agent.service
systemctl start google-guest-agent.service
```
מוודאים שהסקריפטים של Google Agent ל-Linux מותקנים ופועלים. מידע נוסף זמין במאמר קביעת הסטטוס של נציג Google. אם סוכן Google ל-Linux לא מותקן, מתקינים אותו מחדש.
מוודאים שיש לכם את התפקידים הנדרשים כדי להתחבר למכונה הווירטואלית. אם אתם משתמשים ב-OS Login במכונה הווירטואלית, קראו את המאמר הקצאת תפקיד IAM ל-OS Login. אם המכונה הווירטואלית לא משתמשת ב-OS Login, אתם צריכים את התפקיד "אדמין של מכונות Compute" או את התפקיד "משתמש בחשבון שירות" (אם המכונה הווירטואלית מוגדרת לפעול כחשבון שירות). התפקידים האלה נדרשים כדי לעדכן את המטא-נתונים של מפתחות ה-SSH של המכונה או הפרויקט.
כדי לוודא שיש כלל של חומת אש שמאפשר גישת SSH, מריצים את הפקודה הבאה:
```
gcloud compute firewall-rules list | grep "tcp:22"
```
מוודאים שיש נתיב ברירת מחדל לאינטרנט (או ליעד המבוצר). מידע נוסף זמין במאמר בדיקת מסלולים.
מוודאים שיש מקום בכונן הבסיסי (root). למידע נוסף, קראו את המאמר פתרון בעיות בדיסקים מלאים ושינוי גודל הדיסק.
כדי לוודא שלא נגמר הזיכרון הפנוי (OOM) ב-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 מופעל

כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:
- מתחברים ל-VM באמצעות מסוף Google Cloud או Google Cloud CLI. מידע נוסף זמין במאמר איך מתחברים למכונות וירטואליות.
- מוסיפים את מפתחות ה-SSH ל-OS Login. מידע נוסף זמין במאמר איך מוסיפים מפתחות למכונות וירטואליות שמשתמשות ב-OS Login.
- משביתים את OS Login. מידע נוסף זמין במאמר איך משביתים את OS Login.
השתמשתם במפתח SSH ששמור בפרופיל ב-OS Login כדי להתחבר ל-VM שלא מופעל בה השירות OS Login. אם משביתים את OS Login, אי אפשר להתחבר למכונה הווירטואלית באמצעות מפתחות SSH שנשמרו בפרופיל ב-OS Login. לא בטוחים אם OS Login מופעל? איך בודקים שהשירות OS Login מופעל

כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:
- מתחברים ל-VM באמצעות מסוף Google Cloud או Google Cloud CLI. מידע נוסף זמין במאמר איך מתחברים למכונות וירטואליות.
- מפעילים את OS Login. מידע נוסף זמין במאמר איך מפעילים את OS Login.
- מוסיפים את מפתחות ה-SSH למטא-נתונים. מידע נוסף זמין במאמר איך מוסיפים מפתחות SSH למכונות וירטואליות שמשתמשות במפתחות SSH שמבוססים על מטא-נתונים.
השירות OS Login מופעל במכונה הווירטואלית, אבל אין לכם הרשאות IAM מספיקות כדי להתחבר באמצעות OS Login. כדי להתחבר למכונה וירטואלית שפועל בה השירות OS Login, אתם צריכים את ההרשאות שנדרשות להתחברות באמצעות OS Login. לא בטוחים אם OS Login מופעל? איך בודקים שהשירות OS Login מופעל

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

כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:
- מתחברים למכונה הווירטואלית באמצעות משתמש IAM עם תפקידי ה-IAM הנדרשים ל-OS Login.
- מגדירים את המשתמש המקומי עם מפתח SSH באמצעות סקריפט המטא-נתונים לטעינה בזמן ההפעלה:
  1. נכנסים לדף VM instances במסוף Google Cloud .
  2. לוחצים על השם של המכונה הווירטואלית שבה רוצים להגדיר את המשתמש המקומי.
  3. לוחצים על Edit.
  4. בקטע מטא-נתונים, לוחצים על הוספת פריט.
  5. בשדה Key, מזינים startup-script.
  6. בשדה Value, מזינים סקריפט שדומה לסקריפט הבא כדי ליצור את המשתמש ולהוסיף את מפתח ה-SSH הציבורי:
```
#!/bin/bash
# Create the local user if it doesn't exist
if ! id -u <var>USERNAME</var> >/dev/null 2>&1; then
  useradd -m -s /bin/bash <var>USERNAME</var>
fi

# Create the SSH directory and authorized_keys file
mkdir -p /home/<var>USERNAME</var>/.ssh
echo "<var>SSH_KEY</var>" >> /home/>varUSERNAME/var&>lt;/.ssh/authorized_keys

# Set permissions and ownership
chmod 700 /home/varU<SER>NAME/var</.ss>h
chmod 600 /home/varU<SER>NAME/var</.ss>h/authorized_keys
chown -R varU<SER>NAME/var<:var>U<SER>NAME/var< /home/varU<SER>NAME/var</.ss>h
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫USERNAME: שם המשתמש המקומי שרוצים ליצור או להגדיר.
  - ‫SSH_KEY: מפתח ה-SSH הציבורי שלכם.
  1. לוחצים על Save ומפעילים מחדש את ה-VM.
- משביתים את OS Login. מידע נוסף זמין במאמר איך משביתים את OS Login.
תוקף המפתח שלכם פג והקובץ ~/.ssh/authorized_keys נמחק ב-Compute Engine. אם הוספתם מפתחות SSH ל-VM באופן ידני, ואז התחברתם ל-VM באמצעות מסוף Google Cloud , מערכת Compute Engine יוצרת לחיבור זוג מפתחות חדש. כשפג התוקף של זוג המפתחות החדש, מערכת Compute Engine מוחקת ב-VM את הקובץ ~/.ssh/authorized_keys, שכולל את מפתח ה-SSH שהוספתם באופן ידני.

כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:
- מתחברים ל-VM באמצעות מסוף Google Cloud או Google Cloud CLI. מידע נוסף זמין במאמר איך מתחברים למכונות וירטואליות.
- מוסיפים מחדש את מפתח ה-SSH למטא-נתונים. מידע נוסף זמין במאמר איך מוסיפים מפתחות SSH למכונות וירטואליות שמשתמשות במפתחות 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, צריך להתחבר לקונסולה הטורית של ה-VM בתור משתמש Root.

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:
- בודקים במדריך למשתמש את ההגדרות של מערכת ההפעלה שלכם כדי לוודא ש-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 הציבורי של הסשן בסביבת האורח. אם דיסק האתחול מלא, החיבור נכשל.

כדי לפתור את הבעיה תוכלו לנסות אחד או יותר מהפתרונות הבאים:
- מוודאים שדיסק האתחול מלא על ידי ניפוי באגים באמצעות הקונסולה הטורית וזיהוי שגיאות מסוג no space left errors.
- משנים את הגודל של הדיסק.
- אם ידוע לכם אילו קבצים צורכים מקום בדיסק, כדאי ליצור סקריפט לטעינה בזמן ההפעלה שמוחק קבצים מיותרים ומפנה מקום. אחרי שהמכונה הווירטואלית מופעלת ואתם מצליחים להתחבר אליה, צריך למחוק את המטא-נתונים של startup-script.
ההרשאות או הגדרות הבעלות של הספריות או הקבצים $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 מסבירים איך משנים את ההרשאות והבעלות.

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

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

החיבור נכשל

יכול להיות שתקבלו את השגיאות הבאות כשאתם מתחברים ל-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

כדי לראות את השגיאה הבסיסית ב-ssh, כמו זמן קצוב לתפוגה של החיבור, חיבור שנדחה או Permission denied (publickey), מריצים את הפקודה gcloud compute ssh עם פלט ssh מפורט:

gcloud compute ssh VM_NAME --ssh-flag="-vvv"

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

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

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

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

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

כדי לפתור את הבעיה צריך ליצור כלל בהתאמה אישית של חומת אש, שיאפשר תעבורת tcp ביציאה שבה פועל התהליך sshd, באמצעות הפקודה הבאה:
```
gcloud compute firewall-rules create FIREWALL_NAME \
  --allow tcp:PORT_NUMBER
```
למידע נוסף על יצירת כללים בהתאמה אישית של חומת האש: יצירת כללים של חומת אש.
כלל ה-SSH של חומת האש חסר או לא מאפשר תעבורת נתונים מ-IAP או מהאינטרנט הציבורי. חיבורי SSH יידחו אם כללי חומת האש לא מאפשרים חיבורים מ-IAP או תעבורת נתונים נכנסת (ingress) של 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, צריך להתחבר לקונסולה הטורית של ה-VM בתור משתמש Root.

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:
- בודקים במדריך למשתמש את ההגדרות של מערכת ההפעלה שלכם כדי לוודא ש-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.
סשן SSH קופא או מתנתק אחרי כ-30 שניות. הבעיה הזו בדרך כלל נגרמת בגלל כללים של חומת אש ברמת מערכת ההפעלה, שמובילים לניתוק של חיבורים קיימים, או בגלל חוסר התאמה של יחידת שידור מקסימלית (MTU) שגורם לאובדן מנות בזמן העברת נתונים.

כדי לפתור את הבעיה, בצעו אחד או יותר משלבי פתרון הבעיות הבאים:
- בדיקת חומות האש של מערכת ההפעלה של האורח: בודקים את הכללים של חומת האש של מערכת ההפעלה של האורח כדי לוודא שהם לא מגבילים את הקצב, מבטלים חיבורים עם שמירת מצב או חוסמים תנועת SSH.
  - מתחברים ל-VM באמצעות הקונסולה הטורית ומריצים את הפקודה sudo iptables -S (או sudo ufw status) כדי לבדוק את הכללים הפעילים.
  - כדי לבדוק אם הכללים הפעילים חוסמים את התנועה, משביתים או מוחקים אותם באופן זמני באמצעות הפקודה sudo iptables -F או sudo ufw disable.
- אימות הגדרות ה-MTU: חוסר התאמה של ה-MTU בין רשת ה-VPC לבין מערכת ההפעלה של האורח עלול לגרום לרשת להשמיט חבילות גדולות בלי להודיע על כך (לדוגמה, כשמריצים פקודות שמפיקות פלט גדול כמו cat או top).
  - כדי לאמת את הגדרת ה-MTU של רשת ה-VPC (ברירת המחדל היא 1460), עיינו במאמר שינוי ה-MTU של רשת VPC.
  - מריצים את ip link show במכונה כדי לזהות את שם הממשק הפעיל (למשל ens4 או eth0) ולאמת את הערך של mtu.
  - מריצים בדיקת פינג עם הגדרת הביט Don't Fragment‏ (DF): ping -M do -s 1432 TARGET_IP (כאשר גודל מטען ייעודי של 1,432 בייטים בתוספת 28 בייטים של כותרת ICMP/IP שווה ל-MTU סטנדרטי של 1,460). פלט כמו Message too long, mtu = ... מציין חוסר התאמה של MTU.
  - משנים באופן זמני את ה-MTU של ממשק מערכת ההפעלה כך שיתאים לרשת ה-VPC: ‏sudo ip link set dev INTERFACE_NAME mtu VPC_MTU.
  - אם אתם משתמשים ב-Cloud Interconnect או ברשתות VPN, ודאו שהגדרות ה-MTU תואמות בכל הנתבים המקומיים, בשערי המעבר וברשת ה-VPC.
אי אפשר להתחבר ב-SSH למכונה וירטואלית מ-snapshot או משיבוט. כשיוצרים VM מ-snapshot או מדיסק משוכפל, הגדרות הרשת הסטטיות שנשמרו במטמון בדיסק עלולות להתנגש עם כתובת ה-MAC של ה-VM החדש, מה שמונע אתחול של ממשק הרשת וחוסם את הגישה ל-SSH.

כדי לפתור את הבעיה, מתחברים ל-VM באמצעות הקונסולה הטורית ומעדכנים את הגדרות הרשת כך שיתאימו לכתובת ה-MAC החדשה:
- כדי לאשר את ההתנגשות, בודקים את הפלט של היציאה הטורית של המכונה הווירטואלית. חפשו שגיאות כמו "Device eth0 has different MAC address than expected, ignoring", שגיאות של זמן קצוב לתפוגה של DHCP או יומנים שבהם מוצגים ממשקים ששמם שונה באופן בלתי צפוי (לדוגמה, renamed network interface eth0 to eth1).
- מתחברים למסוף הטורי האינטראקטיבי ונכנסים למכונה.
- מזהים את כתובת ה-MAC החדשה ואת שם הממשק הפעיל באמצעות הפקודה: ip link show
- מעדכנים את הגדרות הרשת בהתאם לכלי לניהול הרשת שבו משתמשים בהפצה:
  - מערכות שמשתמשות ב-Netplan (‏Ubuntu,‏ Debian 10+‎ וחלק מהגרסאות החדשות יותר של Linux):
    1. בודקים את ההגדרות של Netplan ב-/etc/netplan/ (לדוגמה, /etc/netplan/50-cloud-init.yaml).
    2. אם שדה macaddress: מקודד באופן קשיח לממשק (למשל, eth0), מעדכנים אותו בכתובת ה-MAC החדשה או מסירים את השורה macaddress: לגמרי.
    3. מחילים את ההגדרה המעודכנת: sudo netplan apply
    4. הפעלה מחדש של שירותי הרשת: sudo systemctl restart systemd-networkd
  - מערכות מודרניות שמשתמשות ב-NetworkManager‏ (RHEL 9+‎, ‏ Rocky Linux):
    1. מאתרים את פרופילי החיבור הפעילים ב-/etc/NetworkManager/system-connections/ (מחפשים קובצי .nmconnection).
    2. פותחים את הקובץ שמתאים לממשק הראשי ומחפשים את השורה mac-address= מתחת לבלוק ההגדרות [ethernet].
    3. מעדכנים את הערך כך שיתאים לכתובת ה-MAC החדשה או מוחקים את השורה כדי לאפשר התאמה דינמית של החומרה.
    4. מפעילים מחדש את NetworkManager: ‏sudo systemctl restart NetworkManager
  - מערכות מדור קודם שמשתמשות בסקריפטים של ifcfg ‏ (RHEL 7/8, ‏ CentOS):
    1. פותחים את הסקריפט של הממשק שנמצא ב-/etc/sysconfig/network-scripts/ifcfg-eth0: sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
    2. מאתרים את השורה HWADDR= ומעדכנים אותה עם כתובת ה-MAC החדשה, או מוחקים את השורה לגמרי כדי לאפשר קישור דינמי. שומרים ויוצאים.
    3. מפעילים מחדש את שירות הרשת: sudo systemctl restart network.service או sudo service network restart
אחרי שמתקנים את הגדרות הרשת ומפעילים מחדש את מקבץ הרשת, מוודאים שמופיעה ב-ip addr show כתובת IP פנימית תקינה שמוקצית לממשק. עכשיו הגישה ל-SSH אמורה לפעול כרגיל.
ה-CLI של gcloud מאומת באמצעות חשבון שאין לו הרשאה להתחבר למכונה הווירטואלית. אם החשבון הפעיל ב-CLI של gcloud הוא לא החשבון שאתם מצפים לו, או אם לחשבון אין את תפקידי ה-IAM הנדרשים, ה-CLI של gcloud לא יכול להוסיף את מפתח ה-SSH למכונה הווירטואלית והחיבור נכשל.

כדי לפתור את הבעיה:
1. בודקים איזה חשבון פעיל ב-CLI של gcloud:
```
gcloud auth list
```
2. אם החשבון הפעיל הוא לא החשבון שבו אתם רוצים להשתמש, היכנסו לחשבון הנכון:
```
gcloud auth login ACCOUNT
```
  מחליפים את ACCOUNT בכתובת האימייל של חשבון משתמש שיש לו הרשאה להתחבר למכונה הווירטואלית.
3. מוודאים שלחשבון יש את התפקידים הנדרשים. במכונות וירטואליות שמשתמשות במפתחות SSH שמבוססים על מטא-נתונים, צריך את התפקיד "אדמין של מכונות Compute (גרסה 1)" (roles/compute.instanceAdmin.v1). אם המכונה הווירטואלית פועלת כחשבון שירות, צריך גם את התפקיד "משתמש בחשבון שירות" (roles/iam.serviceAccountUser). במכונות וירטואליות שמשתמשות ב-OS Login, צריך לעיין במאמר הקצאת תפקידי IAM ל-OS Login.
4. מנסים להתחבר שוב.
זוג מפתחות ה-SSH שמשמש את ה-CLI של gcloud חסר, פגום או לא תואם למפתח הציבורי במכונה הווירטואלית. ה-CLI של gcloud מאחסן את זוג מפתחות ה-SSH בקבצים ~/.ssh/google_compute_engine ו-~/.ssh/google_compute_engine.pub בתחנת העבודה. אם מאבדים את המפתח הפרטי, או אם זוג המפתחות לא תואם למפתח הציבורי ששמור במטא-נתונים או בפרופיל ב-OS Login, המכונה הווירטואלית דוחה את החיבור.

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

כדי לפתור את הבעיה, יוצרים זוג מפתחות חדש:
1. משנים את השמות של קובצי המפתחות הקיימים כדי שה-CLI של gcloud לא ישתמש בהם:
```
mv ~/.ssh/google_compute_engine ~/.ssh/google_compute_engine.old
mv ~/.ssh/google_compute_engine.pub ~/.ssh/google_compute_engine.pub.old
```
  ב-Windows, צריך לשנות גם את השם של הקובץ google_compute_engine.ppk באותה ספרייה.
2. מתחברים למכונה הווירטואלית באמצעות ה-CLI של gcloud:
```
gcloud compute ssh VM_NAME
```
  מחליפים את VM_NAME בשם של המכונה הווירטואלית.
  
  ה-CLI של gcloud יוצר זוג מפתחות חדש ומוסיף את המפתח הציבורי למטא-נתונים של המכונה הווירטואלית או לפרופיל OS Login.
ב-VM נגמר המקום בכונן או בזיכרון, או שסביבת האורח לא פועלת. כל אחד מהתנאים האלה יכול למנוע מהמכונה הווירטואלית להוסיף את מפתח ה-SSH או לקבל חיבורים חדשים.

כדי לפתור את הבעיה:
- בודקים אם דיסק האתחול מלא. למידע נוסף, קראו את המאמר פתרון בעיות בדיסקים מלאים ושינוי גודל הדיסק.
- כדי לבדוק אם נגמר הזיכרון ב-VM, מחפשים בפלט של היציאה הטורית שגיאות שקשורות לזיכרון. ב-Cloud Shell או במסוף שבו מותקן ה-CLI של gcloud, מריצים את הפקודה הבאה:
```
gcloud compute instances get-serial-port-output VM_NAME \
    | grep -i -e "out of memory" -e "oom"
```
- מוודאים שסביבת האורח מותקנת ופועלת. מידע נוסף זמין במאמר אימות של סביבת האורח.

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

אם השגיאה נמשכת, בודקים את יומני האימות של SSH ב-VM. היומנים האלה נמצאים בקובץ /var/log/auth.log ב-Debian וב-Ubuntu, ובקובץ /var/log/secure ב-RHEL, ב-CentOS וב-Rocky Linux. אם אתם לא מצליחים להתחבר ל-VM באמצעות SSH, אתם יכולים לבדוק את היומנים בלי לעצור את ה-VM באחת מהדרכים הבאות:

נכנסים ל-VM באמצעות המסוף הטורי האינטראקטיבי.
בדיקת עותק של דיסק האתחול שנוצר מקובץ snapshot.

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

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

יכול להיות שתקבלו את השגיאה הבאה כשאתם מנסים להתחבר ל-VM של 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, צריך להתחבר לקונסולה הטורית של ה-VM בתור משתמש Root.

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:
- בודקים במדריך למשתמש את ההגדרות של מערכת ההפעלה שלכם כדי לוודא ש-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
```
  פלט הסטטוס יכול להכיל מידע כמו קוד היציאה, הסיבה לכישלון וכו'. אתם יכולים להשתמש בפרטים האלה כדי להמשיך בפתרון הבעיות.
בעיה לא ידועה בדימון (daemon) של SSH. כדי לאבחן בעיה לא ידועה ב-SSH daemon, בודקים אם יש שגיאות ביומני הקונסולה הטורית.

בהתאם לפלט של יומני הקונסולה הטורית, נסו לחלץ את ה-VM ולתקן את הבעיות שקשורות לדימון (daemon) של SSH:
1. מחברים את הדיסק למכונה וירטואלית אחרת של Linux.
2. מתחברים למכונה הווירטואלית עם הדיסק שנטען.
3. טוענים את הדיסק בתוך מערכת ההפעלה לספרייה MOUNT_DIR בתוך ה-VM.
4. בודקים אם יש בעיות או שגיאות ביומנים שקשורים ל-SSH, ‏ /var/log/secure או /var/log/auth.log. אם אתם רואים בעיות שאתם יכולים לתקן, נסו לתקן אותן. אחרת, יוצרים בקשת תמיכה ומצרפים את היומנים.
5. מנתקים את הדיסק ממערכת ההפעלה באמצעות הפקודה umount:
```
cd ~/
umount /mnt
```
6. מנתקים את הדיסק מה-VM.
7. מחברים את הדיסק למכונה הווירטואלית המקורית.
8. מפעילים את המכונה הווירטואלית.

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

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‎. כדי לתקן את ההגבלה, נסו אחד מהפתרונות הבאים:

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

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

ייתכן שתקבלו את השגיאה הבאה כשאתם מתחברים ל-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.

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

הגדרות בהתאמה אישית יכולות לשנות בטעות את פעולות ברירת המחדל הצפויות של gcloud compute ssh או של לקוחות SSH רגילים כשמתחברים למכונות של Compute Engine. ב-Linux וב-macOS, הקובץ הזה נמצא בדרך כלל ב-~/.ssh/config.

אלה התסמינים של הבעיה:

אתם לא מצליחים להתחבר למכונה הווירטואלית באמצעות SSH בגלל שגיאות כמו Permission denied (publickey), למרות שהמכונה פועלת והרשאות ה-IAM שלכם נכונות.
משתמשים אחרים יכולים להתחבר למכונה הווירטואלית.
אתם יכולים להתחבר ממכונת לקוח אחרת שאין בה את אותה הגדרת SSH בהתאמה אישית.

כדי לאבחן את הבעיה:

כדי לבדוק את קובץ התצורה המקומי של SSH, בודקים את התוכן של הקובץ ~/.ssh/config. חפשו קטעי Host שתואמים לשם המארח או לכתובת ה-IP של המכונה הווירטואלית, או הגדרות גלובליות (בלי שורת Host) שעשויות להיות רלוונטיות. כדאי לבדוק את הדברים הבאים:
- ‫PubkeyAcceptedKeyTypes: אם ההוראה הזו קיימת, יכול להיות שהיא מגבילה את סוגי המפתחות הציבוריים שמותרים, ואולי לא כוללת את אלה שמשמשים את Compute Engine.
- ‫IdentityFile: ההוראה הזו עלולה לאלץ שימוש במפתח פרטי שגוי או לא קיים.
- ‫ProxyCommand: יכול להיות ששרת proxy מפריע לחיבור.
- אפשרויות אחרות שהן לא סטנדרטיות, כמו KexAlgorithms,‏ Ciphers או HostKeyAlgorithms.
כדי לבדוק את החיבור עם פלט מפורט ומידע מפורט על תוצאות ניפוי הבאגים, משתמשים בפקודה gcloud compute ssh עם האפשרויות --verbosity=debug ו---ssh-flag="-vv":
```
gcloud compute ssh INSTANCE_NAME --zone=ZONE --project=PROJECT_ID --verbosity=debug --ssh-flag="-vv"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫INSTANCE_NAME: השם של המכונה שאליה רוצים להתחבר.
- ‫ZONE: האזור שבו נמצאת המכונה.
- ‫PROJECT_ID: מזהה הפרויקט שמכיל את המכונה.
בודקים את הפלט כדי לראות אם יש הודעות שמצביעות על בעיות בהחלפת מפתחות, כשלים באימות או סוגי מפתחות לא צפויים שהלקוח מציע.

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

כדי לבדוק אם הבעיה היא ב-~/.ssh/config, אפשר להתעלם מקובץ התצורה המקומי באמצעות הדגל -F none. הבדיקה הזו היא הדרך הכי אמינה לבודד את הבעיה.
- ב-CLI של gcloud:
```
gcloud compute ssh INSTANCE_NAME --zone=ZONE --project=PROJECT_ID --ssh-flag="-F none"
```
- ב-ssh רגיל:
```
ssh -F none USERNAME@EXTERNAL_IP
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫USERNAME: שם המשתמש שלכם ב-SSH.
- ‫EXTERNAL_IP: כתובת ה-IP החיצונית של המכונה הווירטואלית.
אם הצלחתם להתחבר, הבעיה היא בקובץ ~/.ssh/config.

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

לפני שמבצעים שינויים, צריך ליצור גיבוי של קובץ התצורה.
```
cp ~/.ssh/config ~/.ssh/config.bak
```
כדי לזהות את השורה שגורמת להתנגשות. עורכים את ‎~/.ssh/config ומסמנים כהערה (באמצעות הסמל #) את כל ההגדרות בהתאמה אישית שחושדים שגורמות לבעיה. בודקים את החיבור אחרי כל שינוי כדי לזהות את השורה הספציפית.
כדי לשנות או להסיר הגדרות, צריך לסמן את השורות כהערה כדי לחזור לסוגי המפתחות שנתמכים כברירת מחדל בלקוח. לדוגמה, אם PubkeyAcceptedKeyTypes גורם לכשל, צריך להפוך אותו להערה.

שיטות מומלצות להגדרה בצד הלקוח:

הימנעו מהגדרות גלובליות מגבילות: החילו הגדרות ספציפיות רק על המארחים שדורשים את השינויים, במקום להשתמש בקטעים רחבים של Host *.
תיעוד השינויים: הוסיפו הערות בקובץ התצורה כדי להסביר למה הוספתם הגדרות ספציפיות בהתאמה אישית.
שימוש ב--F none לבדיקה: כשפותרים בעיות, אפשר להשתמש ב--F none כדי לשלול את כל ההתנגשויות בהגדרות בצד הלקוח.

שגיאות ב-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 שנכשלו, צריך לבצע את השלבים הבאים:

מתקינים או מעדכנים את הגרסה העדכנית של Google Cloud CLI.
מריצים בדיקות קישוריות.
אם אתם משתמשים באימג' מותאם אישית של Linux, וסביבת האורח לא מופעלת בו, אתם צריכים להתקין את סביבת האורח של Linux.
אם אתם משתמשים ב-OS Login, קראו את המאמר פתרון בעיות ב-OS Login.

שיטות אבחון למכונות וירטואליות של 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:

משיגים את כתובת ה-natIP החיצונית של ה-VM:
```
gcloud compute instances describe VM_NAME \
    --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
```
מחליפים את VM_NAME בשם של המכונה הווירטואלית שלא מצליחים להתחבר אליה.

הערה: כתובת ה-IP עשויה להשתנות אם אתם משתמשים ב-IAP כדי לגשת למכונה דרך כתובת ה-IP הפנימית. בנוסף, אם כתובת ה-IP היא פנימית, תוכלו לגשת למכונה רק מתוך רשת ה-VPC.
בודקים את חיבור הרשת ל-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:

מפעילים את הגישה האינטראקטיבית למסוף הטורי של ה-VM.
במכונות וירטואליות של Linux, מוסיפים ל-VM את הסקריפט לטעינה בזמן ההפעלה הבא כדי לשנות את הסיסמה של משתמש ה-Root.
```
echo root:PASSWORD | chpasswd
```
מחליפים את PASSWORD בסיסמה לבחירתכם.
משתמשים בקונסולה הטורית כדי להתחבר ל-VM.
במכונות וירטואליות של Linux, אחרי שמסיימים לנפות את כל השגיאות צריך להשבית את ההתחברות באמצעות החשבון של משתמש ה-Root:
```
sudo passwd -l root
```

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

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

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

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

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

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

יוצרים רשת VPC חדשה שתארח את המכונה המשוכפלת:
```
gcloud compute networks create debug-network
```
מחליפים את NETWORK_NAME בשם שרוצים לתת לרשת החדשה.

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

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

יוצרים קובץ snapshot של דיסק האתחול.
```
gcloud compute disks snapshot BOOT_DISK_NAME \
   --snapshot-names debug-disk-snapshot
```
מחליפים את BOOT_DISK_NAME בשם של דיסק האתחול.

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

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

יוצרים מכונה חדשה לניפוי באגים ללא כתובת IP חיצונית:
```
gcloud compute instances create debugger \
   --network debug-network \
   --no-address
```
מחברים למכונה את הדיסק שיצרתם לצורך ניפוי הבאגים:
```
gcloud compute instances attach-disk debugger \
   --disk example-disk-debugging
```
פועלים לפי ההוראות במאמר איך מתחברים למכונה וירטואלית באמצעות יעד מבוצר (bastion host).
אחרי שהתחברתם למכונה לניפוי הבאגים, אתם יכולים לנסות לפתור את הבעיות בה. לדוגמה, אתם יכולים לעיין ביומני של המכונה:
```
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.

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

מריצים את הפקודה gcloud compute instances delete עם הסימון --keep-disks.
```
gcloud compute instances delete VM_NAME \
   --keep-disks boot
```
מחליפים את VM_NAME בשם של המכונה הווירטואלית שלא מצליחים להתחבר אליה.
מוסיפים מכונה חדשה עם אותו דיסק ומציינים את הסקריפט לטעינה בזמן ההפעלה.
```
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

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

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

מוחקים את המכונה הווירטואלית שלא ניתן להתחבר אליה ושומרים את דיסק האתחול שלה:
```
gcloud compute instances delete VM_NAME \
   --keep-disks=boot 
```
מחליפים את VM_NAME בשם של המכונה הווירטואלית שלא מצליחים להתחבר אליה.
יוצרים מכונה וירטואלית חדשה באמצעות דיסק האתחול של המכונה הווירטואלית הישנה. מציינים את השם של דיסק האתחול של המכונה הווירטואלית שמחקתם הרגע.
מתחברים למכונה הווירטואלית החדשה באמצעות SSH:
```
gcloud compute ssh NEW_VM_NAME
```
מחליפים את NEW_VM_NAME בשם של המכונה הווירטואלית החדשה.

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

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

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

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

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

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

ממתינים כמה שניות עד שהשינוי ייכנס לתוקף.
מפעילים מחדש את SSH ל-Windows.
מתחברים מחדש ל-VM.

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

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

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

המאמר הבא

הסבר על חיבורי SSH למכונות וירטואליות של Linux ב-Compute Engine.

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

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

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

ההרשאות שנדרשות למשימה הזו

במסוף

ב-gcloud

עיון בתוצאות

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

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

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

החיבור נכשל, מתבצע ניסיון נוסף…

שגיאות ב-Linux

Permission denied (publickey)‎

בעלות

הרשאות

בעלות

הרשאות

החיבור נכשל

בעלות

הרשאות

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

בעלות

הרשאות

Failed to connect to backend

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

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

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

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

שגיאות ב-Windows

Permission denied, please try again

Permission denied (publickey,keyboard-interactive)‎

Could not SSH into the instance

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

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

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

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

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

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

Linux,‏ Windows 2019/2022 ו-macOS

Windows 2012 ו-2016

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

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

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

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

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

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

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

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

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

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

המאמר הבא

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

ההרשאות שנדרשות למשימה הזו