מי באמת רואה את סיסמת ה-SSH שלך ב-VPN לא מהימן?

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

נקבו בשם הנמען לפני שאתם מקלידים משהו

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

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

בדקו את זהות המארח, את הרשומה ואת המשא ומתן

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

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

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

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

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

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

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

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

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

התייחסו לאזהרת מפתח מארח כאל שלב באירוע

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

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

מה המדריך הזה אינו מכסה

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

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