פתרון תקלות SSH בלי לאבד את הגישה לשרת

מתעדים ניסיון אחד ושומרים גישה קיימת

פקודות מקומיות מריצים במחשב Linux, macOS או WSL. בדיקות שרת מריצים בחיבור עובד או בקונסולה מהימנה. החליפו את כתובת הדוגמה 203.0.113.10, המשתמש ubuntu, פורט 22 ונתיב המפתח בערכים שלכם.

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

ssh -G מציג את הגדרות הלקוח הסופיות: hostname, user, port, identityfile ו-proxy אם קיים. הפקודה השנייה משתמשת ב--S none כדי לא למחזר חיבור משותף פתוח. רשמו שעה ושגיאה אחרונה. הסירו פרטים רגישים מהפלט לפני שיתוף; לעולם אל תשלחו מפתח פרטי.

בוחרים מסלול לפי ההודעה

במסך קטן ניתן לגלול את הטבלה הצידה כדי לראות את כל העמודות.

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

ב-timeout עוקבים אחר נתיב הרשת

השוו את היעד ב-ssh -v לכתובת הנוכחית בפאנל. DNS ישן או IPv6 שגויה עלולים להפנות למקום אחר. בררו אם נדרשת כתובת ציבורית, VPN או שרת קפיצה.

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

ב-Oracle Cloud יש לבדוק security lists, NSG, ניתוב וחומת אש פנימית. שמרו את כללי התמונה; התקנת UFW או ריקון iptables אינם אבחון. גם ping שלא נענה אינו מוכיח ש-SSH אינו נגיש.

בחיבור שנדחה בודקים שירות מאזין

הריצו בשרת דרך חיבור תקין או הקונסולה:

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

חפשו שירות שמאזין בכתובת ובפורט הצפויים, והתאימו את זמני היומן לניסיון. Ubuntu יכולה להשתמש בהפעלה דרך socket: ssh.service שאינו פעיל אינו בהכרח תקלה אם ssh.socket מאזין.

sshd -t בודק תצורה ומפתחות מארח בלי להפעיל את השירות. סיום שקט ותקין אינו בדיקת גישה מהרשת. מצאו את הקובץ או ההגדרה שהוזכרו בשגיאה; אל תפעילו מחדש באופן עיוור שירות שמספק את דרך הגישה היחידה.

ב-publickey בודקים חשבון ומפתח מוצע

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

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

IdentitiesOnly מצמצם מפתחות לא קשורים מסוכן המפתחות, אך הגדרות IdentityFile עדיין יכולות לחול. בדקו ssh -G. אם המפתח הפרטי אינו קריא או שהרשאותיו פתוחות מדי, פתרו קודם את הבעיה המקומית.

בשרת בדקו את החשבון והמפתחות הציבוריים. הדוגמה מניחה /home/ubuntu; השתמשו בתיקיית הבית ש-getent מציג:

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

השוו את טביעות האצבע המורשות למפתח שהוצע. בדקו בעלות, הרשאות, מדיניות משתמש ויומן. AuthorizedKeysFile, Include, Match או שירות מפתחות מנוהל יכולים לשנות את ברירת המחדל. שמרו מפתחות קיימים; אל תכבו StrictModes ואל תפעילו סיסמאות כקיצור דרך.

בשינוי מפתח מארח מאמתים זהות

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

למפתח מארח מסוג Ed25519, הריצו דרך הקונסולה המהימנה של האורח:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

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

מאמתים את התיקון בכניסה חדשה

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

חזרו על הניסיון ללא שיתוף חיבור, ודאו את המשתמש והרשאות sudo הנחוצות ורק אז סגרו את החיבור המקורי. תעדו את הסיבה והתיקון; לאחר מכן ניתן להמשיך להגדרת אתר ב-Ubuntu.

שאלות ותשובות