ההבדל בין Connection refused ל-Connection timed out ב-SSH

מה המשמעות של "Connection refused" ו-"Connection timed out" ב-SSH

שגיאות SSH מסוג Connection refused ו-Connection timed out הן כשלים הפוכים, לכן הפתרון לאחת לעולם לא יהיה הפתרון לשנייה. השגיאה Refused מציינת שהחבילה הגיעה לשרת וה-kernel של השרת השיב ש"שום דבר לא מאזין כאן". השגיאה Timed out מציינת שהחבילה לא הגיעה לאף גורם שישיב, ולכן הלקוח המתין ווויתר. השגיאה Refused היא בעיית שירות בשרת. השגיאה Timed out היא בעיית נתיב לפני השרת.

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

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

הזמן הוא הרמז השני. השגיאה Refused חוזרת מיד, בערך בזמן שלוקח ל-round trip אחד. השגיאה Timed out נשארת תלויה במשך שניות רבות לפני שהיא מודפסת, כיוון שהלקוח ממשיך לשלוח מחדש לפני שהוא מוותר. מערכת ההפעלה macOS מדפיסה Operation timed out עבור אותו מצב. אם הפרוטוקול עצמו חדש לכם, איך SSH עובד ומה עושה sshd הוא הרקע שעליו מניח מדריך זה.

מדוע "Connection refused" היא בשורה טובה

השגיאה Refused היא למעשה אות RST של פרוטוקול TCP. הלקוח שלכם שולח חבילת SYN לפורט 22. היא חוצה את האינטרנט, מגיעה למחסנית הרשת של השרת, והליבה (kernel) מגלה שאין socket שמאזין בפורט הזה, לכן היא משיבה בחבילת RST (איפוס). לקוח ה-SSH שלכם מתרגם את ה-RST הזה למילים Connection refused.

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

• sshd אינו רץ, כיוון שהוא נכשל בעלייה או שמעולם לא הופעל.
• sshd מאזין בפורט אחר, בדרך כלל לאחר שינוי לצורכי הקשחת אבטחה.
• sshd קשור לכתובת אחת בלבד, כמו ListenAddress 127.0.0.1, ולכן רק השרת עצמו יכול להגיע אליו.
• חומת אש מוגדרת לדחות (reject) במקום להשליך (drop), ולכן חומת האש שולחת את ה-RST בשם המארח. הפעולה reject ב-ufw וכלל ב-nftables שמסתיים ב-reject with tcp reset מבצעים שניהם פעולה זו.

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

כיצד לתקן שגיאת Connection refused

לא ניתן לתקן שגיאה זו באמצעות SSH, כיוון ששירות ה-SSH עצמו הוא זה שאינו תקין. פתחו את מסוף הניהול (web console) או את ה-serial console של ספק השרתים שלכם, התחברו למערכת, ולאחר מכן בצעו את הפקודות הבאות.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

systemctl status ssh משמש כשם היחידה ב-Ubuntu וב-Debian. ב-RHEL ובהפצות המבוססות עליה, כגון AlmaLinux, שם היחידה הוא sshd. הפקודה ss -tlnp מציגה את כל ה-TCP sockets במצב האזנה (listening) יחד עם התהליך שבבעלותו הם נמצאים, וזהו המקור המהימן ביותר: אם אף שורה אינה מציינת את sshd, הרי ששום תהליך אינו מאזין, ללא קשר למה שמופיע בקובץ התצורה. הפקודה sshd -T מדפיסה את התצורה האפקטיבית לאחר מיזוג כל קובצי ה-Include, וזהו המקום שבו פורט שנשכח ב-/etc/ssh/sshd_config.d/ יתגלה.

עיינו היטב בעמודת הכתובת. 0.0.0.0:22 מציין את כל כתובות ה-IPv4 בשרת. [::]:22 מציין את כל כתובות ה-IPv6. 127.0.0.1:22 מציין האזנה ל-loopback בלבד, ולכן כל חיבור מרחוק אליו יידחה, בעוד שחיבור מקומי באמצעות ssh localhost יעבוד בצורה מושלמת.

אם שום תהליך אינו מאזין, הפעילו את השירות וקראו את הודעת השגיאה במקרה שהוא אינו עולה.

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

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

מלכודת ה-socket activation ב-Ubuntu

גרסה 24.04 של Ubuntu מגיעה עם יחידת systemd socket עבור OpenSSH. כאשר יחידה זו פעילה, systemd מחזיק בפורט ההאזנה ומפעיל את sshd עבור כל חיבור בנפרד. לכן, שינוי Port 2222 בתוך sshd_config אינו משנה דבר, והשרת ימשיך להשיב בפורט הישן. בדקו באיזה מצב נמצא השרת שלכם לפני שתבצעו עריכה כלשהי.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

אם ה-socket פעיל, הגדירו את הפורט בקובץ ה-socket unit במקום ב-sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

השורה הריקה ListenStream= נדרשת, כיוון שהגדרות רשימה ב-systemd מתווספות למה שכבר הוגדר. אם תשמיטו אותה, השרת יאזין בשני הפורטים. החילו את השינוי באמצעות sudo systemctl daemon-reload ו-sudo systemctl restart ssh.socket, ולאחר מכן ודאו בעזרת sudo ss -tlnp שהפורט החדש הוא זה שנמצא בשימוש. שינוי הפורט הוא צעד סטנדרטי בתהליך הקשחת SSH ב-VPS, וזהו הצעד שגורם למשתמשים להינעל מחוץ לשרת בתדירות הגבוהה ביותר.

מדוע "Connection timed out" משמעו שלא התקבלה תשובה

פסק זמן (timeout) הוא שתיקה. הלקוח שלכם שלח חבילת SYN, ביצע שידור חוזר שלה מספר פעמים במשך דקה או שתיים, ומעולם לא קיבל חבילה אחת בתמורה. שום דבר לגבי השרת לא הוכח כאן, כיוון שלא התקבל שום אות מהשרת.

שתיקה היא בדיוק מה שחוק DROP מייצר, וביצוע drop הוא מכוון. דחייה (rejection) מודיעה לכל מי שמבצע סריקה שהמארח קיים, לכן ufw וחומת האש של כל ספק ענן משליכים חבילות לא רצויות ולא שולחים דבר בחזרה. פסק הזמן שלכם הוא בדרך כלל חומת אש שמבצעת את עבודתה על פורט שרציתם שיהיה פתוח.

• הכתובת שגויה: רשומת DNS שעדיין מצביעה על שרת שהקמתם מחדש, או טעות הקלדה שמובילה לכתובת שאף אחד לא משתמש בה.
• המארח אינו פעיל: כבוי, או באמצע תהליך reboot. השעיה מצד ספק השירות עקב בעיות חיוב נראית זהה מבחוץ.
• חומת האש של המארח מבצעת drop לפורט 22, לרוב בגלל ש-ufw enable הורץ לפני שהוגדר חוק allow כלשהו.
• חומת אש של ספק השירות שנמצאת לפני ה-instance מבצעת drop, ומערכת ההפעלה כלל לא רואה את החבילה.
• הרשת שלכם חוסמת תעבורה יוצאת בפורט 22, דבר נפוץ בחיבורי משרדים ובתי מלון.

הרצת הבדיקה מהצד הנכון של החיבור

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

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

הפקודה getent hosts מציגה את הכתובת שבה המחשב שלכם ישתמש בפועל; היא מאפשרת לזהות רשומת DNS מיושנת תוך שניות. הפקודה ssh -G מדפיסה את ההגדרות שהלקוח שלכם מחיל לאחר קריאת ~/.ssh/config, כך שהיא חושפת בלוק Host ישן שמשכתב בשקט את שם המארח, הפורט או המשתמש. הפקודה ssh -vvv מראה עד לאן הגיע הניסיון: שורה אחרונה המציינת התחברות לכתובת ולאחריה השהיה ארוכה מעידה על timeout, בעוד שורה המדווחת על גרסת ה-OpenSSH המרוחקת פירושה שחיבור ה-TCP הצליח, והבעיה האמיתית שלכם היא אימות (authentication). ב-Windows, הפקודה Test-NetConnection 203.0.113.10 -Port 22 ב-PowerShell מחליפה את nc.

בדקו את הפורט, לא את המארח. פקודת ping שנכשלה אינה מוכיחה דבר, כיוון שספקי אינטרנט רבים מסננים ICMP (פרוטוקול הודעות בקרה לאינטרנט) בקצה הרשת. גם ping מוצלח אינו מוכיח דבר, כיוון שהוא אינו מעיד על מצב פורט 22.

לאחר מכן, שנו את המשתנה היחיד שאף פקודה לא יכולה לשנות עבורכם: הרשת שלכם. נסו שוב מנקודה חמה (hotspot) בטלפון. אם החיבור דרך הנקודה החמה מצליח והחיבור מהשולחן לא, החסימה נמצאת בצד שלכם של האינטרנט, או שכתובת ה-IP של המשרד שלכם נחסמה בשרת.

חומת האש של ספק הענן שאינה נראית מהשרת

רוב לוחות הבקרה של שרתי VPS מציעים חומת אש רשתית, המכונה לעיתים קבוצת אבטחה (security group) או חומת אש עננית, הפועלת במעלה הזרם של השרת ומחזיקה רשימת חוקים משלה. ufw status בתוך השרת אינו יכול לראות אותה, וזו הסיבה שהמשפט "אבל כבר פתחתי את פורט 22" הוא כה נפוץ. פתחו את לוח הבקרה ועיינו ברשימה זו לפני שאתם משכתבים חוק כלשהו בתוך השרת.

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

sudo tcpdump -ni any tcp port 22

אם דבר אינו מופיע בזמן שהלקוח שלכם מנסה להתחבר, החבילות נזרקות לפני שהן מגיעות למערכת ההפעלה; לכן, התקלה היא בחומת האש של הספק או בניתוב למארח. אם חבילות SYN מגיעות אך אין מענה שיוצא, החסימה היא מקומית ושייכת ל-ufw או ל-nftables. בדיקה בודדת זו מחלקת את ענף ה-timeout לשניים, וזו הסיבה שהיא מצדיקה את המאמץ בגישה למסוף.

סדר הפעולות ב-ufw, פרוטוקול IPv6 וחסימה עצמית

טעות בסדר הפעולות ב-ufw היא הגורם השכיח ביותר לנעילת משתמשים מחוץ לשרת. sudo ufw enable מחיל מדיניות ברירת מחדל של חסימת תעבורה נכנסת באופן מיידי; לכן, אם לא הגדרתם חוק עבור SSH, הסשן הנוכחי שלכם ימשיך לעבוד בזכות מצב חיבור קיים (established state), אך כל חיבור חדש יסתיים ב-timeout. יש לאפשר גישה תחילה, ורק לאחר מכן להפעיל את ה-firewall.

sudo ufw allow OpenSSH
sudo ufw status verbose

פרופיל היישום OpenSSH מכסה את פורט 22 בלבד. אם בכוונתכם להעביר את SSH לפורט 2222, החוק הנדרש הוא sudo ufw allow 2222/tcp, ויש להוסיף אותו לפני שינוי הפורט ולא אחריו. מערך החוקים המלא מוסבר ב-יסודות ה-firewall ב-ufw עבור VPS, וסדר הפעולות הבטוח הוא חלק מ-מה לעשות בעשר הדקות הראשונות ב-VPS חדש.

פרוטוקול IPv6 גורם לעיתים ל-timeout שנראה בלתי מוסבר. אם ל-hostname של השרת יש רשומת AAAA, הלקוח שלכם ינסה להתחבר תחילה דרך IPv6. לכן, שרת שחסרים בו חוקי IPv6 יגרום לחיבור להיתקע, בעוד ניסיון חיבור דרך IPv4 יעבוד כראוי. יש להגדיר את שני הפרוטוקולים בנפרד.

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

אם -4 מצליח להתחבר ו--6 נכשל, הפתרון נמצא בהגדרת חוקי ה-IPv6 בשרת, והמדריך פתיחת פורט זהה עבור IPv6 ב-ufw מפרט כיצד לעשות זאת.

ייתכן גם שחסמתם את עצמכם. השירות fail2ban מנטר את לוג האימות ומכניס חוק firewall נגד כתובות IP שנכשלו בכניסה שוב ושוב. לכן, מפתח שגוי או סקריפט שרץ ברקע עלולים לחסום כתובת IP של משרד שלם. חסימה שגורמת להשלכת חבילות (drop) נראית כמו timeout. חסימה שמחזירה הודעת דחייה (reject) תחזיר No route to host. מהקונסולה:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

הוספת הכתובת שלכם ל-ignoreip היא חלק מ-הגדרה תקינה של fail2ban ב-Ubuntu 24.04.

שגיאות שאינן מסוג סירוב או פקיעת זמן

No route to host מציין שהתקבלה הודעת ICMP unreachable. או שלמכונה שלכם אין נתיב (route) לאותה רשת, או שרכיב כלשהו בדרך השיב בדחייה מנהלתית, שזה בדיוק מה שחוק REJECT ב-iptables מבצע.

Network is unreachable מגיע מהמכונה שלכם. אין לה נתיב כלל למשפחת הכתובות הזו, וזו התשובה הנפוצה כאשר שם מתחם מתרגם לכתובת IPv6 בלבד בחיבור שתומך ב-IPv4 בלבד.

kex_exchange_identification: Connection closed by remote host מציין שחיבור ה-TCP הצליח אך השרת ניתק אותו לפני סיום החלפת המפתחות. הפורט פתוח והתהליך sshd פעיל, לכן בדקו את עומס השרת, את MaxStartups, או חסימה שהופעלה בזמן שניסיתם להתחבר.

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

כיצד לשחזר גישה וכיצד להימנע מנעילה חוזרת

כל ספק VPS רציני מספק מסוף (console) שאינו תלוי ברשת של המכונה האורחת: מסוף טורי (serial console) או מסך VNC מבוסס דפדפן. מסוף זה הוא נתיב השחזור עבור שני התרחישים במדריך זה, כיוון שהוא ממשיך לפעול גם כאשר sshd נעצר וגם כאשר חוק firewall משליך את כל התעבורה. מצאו את המסוף בלוח הבקרה, התחברו כ-root או כמשתמש הרגיל שלכם, ולאחר מכן בצעו את הבדיקות שצוינו לעיל. אם מעולם לא הגדרתם סיסמה ל-root, רוב לוחות הבקרה מאפשרים לאפס אותה עבורכם.

במקרים שבהם לא קיים מסוף, מוצא אחרון הוא מצב ה-rescue של ספק השירות. מצב זה מאתחל מערכת שחזור קטנה ומבצע mount לכונן שלכם, כך שתוכלו לערוך את /etc/ssh/sshd_config או למחוק חוק firewall במצב offline ולאחר מכן לבצע reboot.

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

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

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

סדר הפעולות לפתרון תקלות

1. קראו את טקסט השגיאה ושימו לב כמה זמן לקח לה להופיע.
2. שגיאת Refused: עברו למסוף ובדקו באמצעות sudo ss -tlnp אם קיים socket מאזין, מהו הפורט שלו ולאיזו כתובת הוא קשור.
3. שגיאת Timed out: ודאו מהמחשב שלכם שהכתובת תקינה, לאחר מכן בדקו את ה-firewall של ספק התשתית בלוח הבקרה, ולבסוף את ה-firewall המקומי בשרת.
4. אם לא הופיעה אף אחת מהמחרוזות הללו: כבר קיים חיבור TCP פעיל, לכן יש להתייחס לבעיה כאל שאלת אימות או עומס על השרת, ולא כאל בעיית רשת.

FAQ

מדוע SSH מציג "Connection refused" למרות ש-sshd רץ?

מכיוון שסירוב מגיע מה-socket ולא מהשירות עצמו, וגם sshd פעיל יכול לסרב לחיבור. פתחו את מסוף הניהול של ספק השרתים והריצו את sudo ss -tlnp. socket ב-127.0.0.1:22 יסרב לכל לקוח מרוחק אם הוא מאזין ל-loopback בלבד. socket בפורט אחר יסרב לכל מי שמנסה להתחבר בפורט 22. אם נעשה שימוש ב-systemd socket activation, הפורט מוגדר ב-ssh.socket ולא ב-sshd_config, לכן בדקו גם את systemctl is-enabled ssh.socket. חוק ufw מסוג reject מחזיר גם הוא סירוב בשם המארח, לכן קראו את sudo ufw status verbose לפני שתסיקו מסקנות.

מדוע SSH נכשל ב-timeout למרות ש-ufw מאפשר את פורט 22?

מכיוון ש-timeout מעיד על כך שלא התקבלה תשובה, ו-ufw אינו ה-firewall היחיד בנתיב. רוב לוחות הניהול של VPS מפעילים firewall רשתי לפני ה-instance, ומערכת ההפעלה לעולם לא רואה את מה שה-firewall הזה חוסם. מהמסוף, הריצו את sudo tcpdump -ni any tcp port 22 ונסו להתחבר מהמחשב הנייד שלכם בזמן שהפקודה רצה. אם לא מגיעות חבילות מידע, החסימה מתבצעת במעלה הזרם, בלוח הניהול. אם חבילות מגיעות אך לא יוצאת תשובה, החסימה מקומית, ב-ufw או ב-nftables.

האם ping שנכשל אומר שה-VPS שלי למטה?

לא. ספקים רבים מסננים ICMP בקצה הרשת, כך ששרת שמשרת תעבורה כרגיל יכול להתעלם מכל ping שתשלחו. ping מוצלח הוא מדד חלש באותה מידה, כיוון שהוא לא מעיד דבר על מצב פורט 22. בדקו את הפורט עצמו באמצעות nc -vz -w 5 203.0.113.10 22 מהמחשב שלכם, או באמצעות Test-NetConnection 203.0.113.10 -Port 22 ב-PowerShell ב-Windows.

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

שני סדרים של פעולות גורמים לכך. אם ה-firewall לא קיבל חוק עבור הפורט החדש, ניסיונות התחברות לפורט החדש יסתיימו ב-timeout בעוד פורט 22 יסרב לחיבור, לכן sudo ufw allow 2222/tcp חייב להתבצע לפני שינוי הפורט ולא אחריו. אם השרת משתמש ב-systemd socket activation עבור SSH, ההגדרה Port 2222 בתוך sshd_config מתעלמת מהשינוי ו-systemd ממשיך להחזיק בפורט הישן, דבר שניתן לאמת בעזרת systemctl is-enabled ssh.socket. בצעו שחזור דרך מסוף הניהול של הספק, תקנו את ההגדרה הרלוונטית, ולאחר מכן התחברו עם ssh -p 2222 user@203.0.113.10 ברגע ש-sudo ss -tlnp יציג את ה-socket החדש.