אובדן גישה לשרת נראה גרוע יותר ממה שהוא באמת. כמעט תמיד אפשר לחזור לבד תוך כמה דקות, בלי לאבד כלום. קודם מצאו את המצב שלכם:
| מה קרה | מה עושים |
|---|---|
| שכחתם את סיסמת ה־root | מאפסים אותה (שלב 1) |
| איבדתם את מפתח ה־SSH | מאפסים סיסמה, נכנסים ומוסיפים מפתח חדש (שלבים 1 ו־3) |
| SSH נתקע או מסרב אחרי שינוי בחומת האש או בהגדרות | קונסולת רשת (שלבים 2 ו־3) |
| השרת לא מגיב בכלל | קונסולת רשת כדי לראות את מסך העלייה (שלבים 2 ו־4) |
1. אפסו את סיסמת ה־root
בלוח הבקרה פתחו את השרת, עברו ללשונית ניהול ולחצו על איפוס סיסמת root. הקלידו את ה־hostname של השרת לאישור, כי הסיסמה הישנה מפסיקה לעבוד מיד.
מה קורה אחר כך:
- נוצרת סיסמה חדשה בת 16 תווים (אותיות וספרות);
- היא נקבעת בתוך השרת הפועל, בלי אתחול, ועובדת תוך 10 עד 30 שניות;
- היא נשלחת במייל ומוצגת פעם אחת בחלונית גישה בעמוד השרת, מאחורי חשפו סיסמת root.
אין לסיסמה כפתור העתקה, לכן סמנו אותה ידנית ושמרו במקום בטוח. אל תלחצו על איפוס פעמיים ברצף: שני איפוסים בהפרש של שניות עלולים לעקוף זה את זה ולהשאיר את הסיסמה הישנה יותר פעילה.
בשרת Windows אותו כפתור מאפס את הסיסמה של Administrator.
גם דרך ה־API האישור הוא עם ה־hostname:
curl -X POST https://api.eqvps.com/api/v1/eqvps/services/SERVICE_ID/reset-password \
-H "Authorization: Bearer $EQVPS_API_KEY" -H "Content-Type: application/json" \
-d '{"confirm": "your-hostname"}'
אחר כך קבלו את הסיסמה פעם אחת עם הבקשה הזאת:
GET /services/SERVICE_ID?reveal=1
לסוכני AI שמחוברים דרך MCP יש את אותה יכולת בכלי reset_password.
לאיפוס השרת חייב להיות פועל ולאחר עלייה. אם הוא כבוי, הפעילו אותו קודם.
2. פתחו את קונסולת הרשת
הכפתור קונסולה בעמוד השרת פותח חלון דפדפן עם המסך של השרת עצמו. היא לא משתמשת ברשת ולא ב־SSH, ולכן עובדת כשהשניים שבורים.
- שרתי Linux מקבלים קונסולת טקסט עם בקשת התחברות. אם המסך ריק, הקישו Enter, ואז התחברו כ־
rootעם הסיסמה שלכם. הדבקה עובדת עם Ctrl+V או לחיצה ימנית. - שרתי Windows מקבלים קונסולה גרפית עם כפתור Ctrl+Alt+Del למסך הכניסה.
אם שום דבר לא נפתח, הדפדפן חסם את החלון הקופץ: אפשרו חלונות קופצים ל־eqvps.com ולחצו שוב על קונסולה. הקונסולה מתחילה בגודל 80×24; לתוכנות במסך מלא הריצו:
stty rows 50 cols 200
3. תקנו את הסיבה מהקונסולה
אחרי שנכנסתם, אלה ארבע הנעילות שאנחנו רואים הכי הרבה.
כלל בחומת האש חוסם את SSH. בשרת NAT, פורט ה־SSH שמופיע בלוח הבקרה מועבר לפורט 22 בתוך השרת, ולכן כלל לפורט החיצוני לא עוזר. אפשרו את SSH עצמו:
ufw allow OpenSSH
ufw status
הגדרות SSH שבורות. בדקו אותן ואתחלו:
sshd -t && systemctl restart ssh
אם אי אפשר לקרוא את ההגדרות, sshd -t מדפיס את השורה השגויה.
מפתח SSH שאבד. הוסיפו את המפתח הציבורי החדש שלכם:
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-new-key you@laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
דיסק מלא. התחברות עלולה להיכשל כשלא נשאר מקום בדיסק. בדקו ונקו יומנים ישנים:
df -h /
journalctl --vacuum-size=200M
4. אם השרת לא עולה
הקונסולה מציגה את הודעות העלייה, ובדרך כלל הן מציינות את הבעיה: בדיקת מערכת קבצים שמחכה לקלט, שורה שגויה ב־/etc/fstab, ליבה שלא מתחילה. נסו קודם אתחול רגיל מלוח הבקרה.
שתי אזהרות. תנו לשרת חדש לגמרי דקה־שתיים אחרי היצירה לפני שאתם מאתחלים אותו: הפסקת העלייה הראשונה ממש עלולה להשאיר אותו מוגדר למחצה. ואל תכבו שרת בכוח שוב ושוב; אתחול נקי בטוח יותר.
אם שום דבר לא עוזר, התקנה מחדש של מערכת ההפעלה בלשונית ניהול בונה את השרת מחדש עם אותה כתובת IP, אבל מוחקת את כל הנתונים. אם עוד אפשר, גבו קודם או פתחו פנייה לפני ההתקנה מחדש. גיבויים מוסברים בגיבויים.
קשור
- הגדירו התחברות עם מפתח SSH כדי לא להיות תלויים בסיסמה.
- רשת ופורטים: איך עובדת ההעברה ב־NAT ואילו פורטים פתוחים.
- מעדיפים להחליף כתובת? שינוי כתובת IP.
תגובות
אין עדיין תגובות. היו הראשונים.