גילינו את מעלותיו של SSH מספר רב של פעמים, הן לביטחון והן לגישה מרחוק. בואו נסתכל על השרת עצמו, כמה היבטים חשובים של "תחזוקה", וכמה מוזרויות שיכולות להוסיף מערבולת לנסיעה חלקה אחרת.
למרות שכתבנו מדריך זה מתוך מחשבה על לינוקס, זה יכול לחול גם על OpenSSH ב- Mac OS X ו- חלונות 7 באמצעות Cygwin .
למה זה מאובטח
הזכרנו פעמים רבות כיצד SSH היא דרך נהדרת להתחבר בצורה מאובטחת ולנתח נתונים מנקודה אחת לאחרת. בואו נסתכל בקצרה מאוד על איך הדברים עובדים כדי שתקבלו מושג טוב יותר מדוע לפעמים הדברים יכולים להיות מוזרים.
כאשר אנו מחליטים ליזום חיבור למחשב אחר, אנו משתמשים לעיתים קרובות בפרוטוקולים שקל לעבוד איתם. Telnet ו- FTP שניהם עולים בראש. אנו שולחים מידע לשרת מרוחק ואז אנו מקבלים בחזרה אישור על החיבור שלנו. על מנת ליצור סוג מסוים של בטיחות, פרוטוקולים אלה משתמשים לעיתים קרובות בשילוב שם משתמש וסיסמא. זה אומר שהם בטוחים לחלוטין, נכון? שגוי!
אם אנו חושבים על תהליך החיבור שלנו כדואר, אז השימוש ב- FTP וב- Telnet וכדומה אינו דומה לשימוש במעטפות דיוור רגילות. זה יותר כמו שימוש בגלויות. אם במקרה מישהו נכנס באמצע, הוא יכול לראות את כל המידע, כולל הכתובות של שני הכתבים ואת שם המשתמש והסיסמה שנשלחו. לאחר מכן הם יכולים לשנות את ההודעה, לשמור על המידע זהה ולהתחזות לכתב זה או אחר. זו ידועה כמתקפת "איש באמצע", ולא רק שהיא פוגעת בחשבונך, אלא שהיא מעמידה בסימן שאלה בכל הודעה שנשלחה וקובץ שהתקבל. אתה לא יכול להיות בטוח אם אתה מדבר עם השולח או לא, וגם אם אתה כן, אתה לא יכול להיות בטוח שאף אחד לא מסתכל על כל מה שביניהם.
עכשיו, בואו נסתכל על הצפנת SSL, מה שהופך את HTTP לבטוח יותר. הנה, יש לנו סניף דואר שמטפל בתכתובות, שבודק אם הנמען שלך הוא מי שהוא טוען שהוא, ויש לו חוקים המגנים על הדואר שלך מפני התבוננות. זה יותר מאובטח באופן כללי, והרשות המרכזית - Verisign היא אחת, לדוגמא HTTPS שלנו - מוודאת שהאדם שאליו אתה שולח דואר יבדוק. הם עושים זאת בכך שהם לא מאפשרים גלויות (אישורים לא מוצפנים); במקום זאת הם מחייבים מעטפות אמיתיות.
לבסוף, בואו נסתכל על SSH. כאן, ההתקנה שונה במקצת. אין לנו מאמת מרכזי כאן, אך הדברים עדיין מאובטחים. הסיבה לכך היא שאתה שולח מכתבים למישהו שאת הכתובת שלו אתה כבר מכיר - נניח, על ידי צ'אט איתו בטלפון - ואתה משתמש במתמטיקה מהודרת באמת כדי לחתום על המעטפה שלך. אתה מוסר את זה לאחיך, לחברה שלך, לאבא או לבת שלך לקחת את זה לכתובת, ורק אם ההתאמות המתמטיות של הנמען אתה מניח שהכתובת היא מה שהיא צריכה להיות. ואז תקבל מכתב בחזרה, המוגן גם מפני עיניים סקרניות על ידי המתמטיקה המדהימה הזו. לבסוף, אתה שולח את האישורים שלך במעטפה סודית-קסומה אלגוריתמית ליעד. אם המתמטיקה אינה תואמת, אנו יכולים להניח כי הנמען המקורי עבר ועלינו לאשר שוב את כתובתו.
עם ההסבר כל עוד הוא, אנחנו חושבים שנחתוך אותו שם. אם יש לך עוד קצת תובנה, אל תהסס לשוחח בתגובות, כמובן. בינתיים, בואו נסתכל על התכונה הרלוונטית ביותר של SSH, אימות מארח.
מפתחות מארח
אימות מארח הוא למעשה החלק בו מישהו שאתה סומך עליו לוקח את המעטפה (אטומה במתמטיקה קסומה) ומאשר את כתובת הנמען שלך. זהו תיאור די מפורט של הכתובת, והיא מבוססת על מתמטיקה מסובכת שעליה פשוט נדלג מיד. יש לקחת כמה דברים חשובים מכך, אם כי:
- מכיוון שאין סמכות מרכזית, הביטחון האמיתי טמון במפתח המארח, במפתחות הציבוריים ובמפתחות הפרטיים. (שני המפתחות האחרונים מוגדרים כאשר ניתנת לך גישה למערכת.)
- בדרך כלל, כאשר אתה מתחבר למחשב אחר באמצעות SSH, מפתח המארח מאוחסן. זה הופך את הפעולות העתידיות למהירות יותר (או פחות מילוליות).
- אם מפתח המארח ישתנה, קרוב לוודאי שתתריעו עליכם ועליכם להיזהר!
מכיוון שמפתח המארח משמש לפני אימות כדי לקבוע את זהות שרת SSH, עליך להיות בטוח לבדוק את המפתח לפני התחברות. תראה שיח אישור כמו למטה.
אתה לא צריך לדאוג, עם זאת! לעתים קרובות כאשר אבטחה מהווה דאגה, יהיה מקום מיוחד שניתן לאשר את מפתח המארח (טביעת האצבע של ECDSA לעיל). במיזמים מקוונים לחלוטין, לעתים קרובות זה יהיה באתר מאובטח בלבד. ייתכן שיהיה עליך (או לבחור!) להתקשר למחלקת ה- IT שלך כדי לאשר את המפתח בטלפון. אפילו שמעתי על כמה מקומות שהמפתח נמצא בתג העבודה שלך או ברשימה המיוחדת של "מספרי חירום". ואם יש לך גישה פיזית למכונת היעד, אתה יכול גם לבדוק בעצמך!
בודק את מפתח המארח של המערכת שלך
ישנם 4 סוגים של אלגוריתמי הצפנה המשמשים לייצור מפתחות, אך ברירת המחדל עבור OpenSSH נכון לשנה שעברה היא ECDSA ( עם כמה סיבות טובות ). נתמקד בזה היום. הנה הפקודה שאתה יכול להריץ בשרת SSH שאליו יש לך גישה:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
הפלט שלך אמור להחזיר משהו כזה:
256 צ 'א: 62: א': צ ': א': יי: 2 א ': א': 20: 11: ד 'ב: א': 78: 'צ': צ'צ / אץ / אס / אסш_шост_ецдса_кей.пуб
המספר הראשון הוא אורך הסיביות של המפתח, ואז המפתח עצמו, ולבסוף יש לך את הקובץ שהוא מאוחסן בו. השווה את החלק האמצעי הזה למה שאתה רואה כשאתה מתבקש להיכנס מרחוק. זה אמור להתאים, ואתם מסודרים. אם זה לא קורה, יכול להיות שקורה משהו אחר.
אתה יכול להציג את כל המארחים שאליהם התחברת באמצעות SSH על ידי עיון בקובץ הידוע שלך. זה ממוקם בדרך כלל ב:
~ / .ssh / ידוע_מארחים
אתה יכול לפתוח את זה בכל עורך טקסטים. אם אתה מסתכל, נסה לשים לב לאופן שמירת המפתחות. הם מאוחסנים עם שם המחשב המארח (או כתובת האינטרנט) וכתובת ה- IP שלו.
שינוי מפתחות ובעיות מארח
ישנן כמה סיבות מדוע מפתחות המארח משתנים או שאינם תואמים את מה שנרשם בקובץ הידוע שלך.
- המערכת הותקנה מחדש / הוגדרה מחדש.
- מפתחות המארח שונו באופן ידני עקב פרוטוקולי אבטחה.
- שרת OpenSSH עודכן ומשתמש בסטנדרטים שונים עקב בעיות אבטחה.
- שכירות ה- IP או ה- DNS השתנתה. זה בדרך כלל אומר שאתה מנסה לגשת למחשב אחר.
- המערכת נפגעה בצורה כלשהי כך שמפתח המארח השתנה.
סביר להניח שהנושא הוא אחד משלושת הראשונים, ותוכלו להתעלם מהשינוי. אם חכירת ה- IP / DNS השתנתה, ייתכן שיש בעיה בשרת ואתה עלול להיות מנותב למכונה אחרת. אם אינך בטוח מה הסיבה לשינוי, סביר להניח שאתה צריך להניח שזה האחרון ברשימה.
כיצד OpenSSH מטפל במארחים לא ידועים
ל- OpenSSH הגדרה כיצד היא מטפלת במארחים לא ידועים, המשתקפת במשתנה "StrictHostKeyChecking" (ללא מרכאות).
בהתאם לתצורה שלך, חיבורי SSH עם מארחים לא ידועים (שהמפתחות שלהם עדיין לא נמצאים בקובץ הידוע שלך) יכולים לעבור שלוש דרכים.
- StrictHostKeyChecking מוגדר כלא; OpenSSH יתחבר אוטומטית לכל שרת SSH ללא קשר למצב מפתח המארח. זה לא בטוח ולא מומלץ, למעט אם אתה מוסיף חבורה של מארחים לאחר התקנה מחדש של מערכת ההפעלה שלך, ולאחר מכן תשנה אותה בחזרה.
- StrictHostKeyChecking אמור לשאול; OpenSSH יציג בפניכם מפתחות מארח חדשים ויבקש אישור לפני הוספתם. זה ימנע מחיבורים לעבור למפתחות מארח שהשתנו. זו ברירת המחדל.
- StrictHostKeyChecking מוגדר כן; ההפך מ"לא ", זה ימנע ממך להתחבר לכל מארח שכבר לא קיים בקובץ הידוע שלך.
אתה יכול לשנות משתנה זה בקלות בשורת הפקודה באמצעות הפרדיגמה הבאה:
ssh -o 'StrictHostKeyChecking [option]' user @ host
החלף את [option] ב- "לא", "שאל" או "כן". שים לב שיש ציטוטים ישרים בודדים סביב משתנה זה והגדרתו. החלף גם את user @ host עם שם המשתמש ושם המארח של השרת שאליו אתה מתחבר. לדוגמה:
ssh -o 'StrictHostKeyChecking שאל' [email protected]
מארחים חסומים עקב מפתחות שהשתנו
אם יש לך שרת שאתה מנסה לגשת אליו שהמפתח שלו כבר השתנה, תצורת OpenSSH המוגדרת כברירת מחדל תמנע ממך גישה אליו. אתה יכול לשנות את ערך StrictHostKeyChecking עבור אותו מארח, אבל זה לא יהיה מאובטח לחלוטין, ביסודיות, באופן פרנואידי, נכון? במקום זאת, אנו יכולים פשוט להסיר את הערך הפוגע מקובץ ה-host שלנו.
זה בהחלט דבר מכוער שיש לך על המסך. למרבה המזל, הסיבה שלנו הייתה מערכת הפעלה שהותקנה מחדש. אז, בואו ונתקרב לקו שאנחנו צריכים.
הנה. ראה כיצד הוא מצטט את הקובץ שעלינו לערוך? זה אפילו נותן לנו את מספר השורה! אז בואו נפתח את הקובץ הזה בננו:
הנה המפתח הפוגע שלנו, בשורה 1. כל שעלינו לעשות הוא להכות Ctrl + K כדי לחתוך את כל השורה.
זה הרבה יותר טוב! אז עכשיו נלחץ על Ctrl + O כדי לכתוב (לשמור) את הקובץ, ואז Ctrl + X כדי לצאת.
כעת אנו מקבלים הנחיה נחמדה, אליה אנו יכולים לענות ב"כן ".
יצירת מפתחות מארח חדשים
למען הפרוטוקול, באמת שאין לך יותר מדי סיבה להחליף את מפתח המארח שלך בכלל, אבל אם אי פעם תמצא את הצורך, תוכל לעשות זאת בקלות.
ראשית, שנה לספריית המערכת המתאימה:
cd / etc / ssh /
זה בדרך כלל המקום שבו מקשי המארח הגלובאליים נמצאים, אם כי חלק מההפצות מציבות אותם במקום אחר. במקרה של ספק בדוק את התיעוד שלך!
לאחר מכן, נמחק את כל המקשים הישנים.
sudo rm / etc / ssh / ssh_host_ *
לחלופין, ייתכן שתרצה להעביר אותם לספריית גיבוי בטוחה. רק מחשבה!
לאחר מכן נוכל לומר לשרת OpenSSH להגדיר את עצמו מחדש:
sudo dpkg- הגדר מחדש את שרת openssh
תופיע הודעה בזמן שהמחשב שלך יוצר את המפתחות החדשים שלו. טא-דה!
עכשיו שאתה יודע איך SSH עובד קצת יותר טוב, אתה אמור להיות מסוגל להוציא את עצמך מנקודות קשות. אזהרת / שגיאת "זיהוי המארח המרוחק השתנה" היא דבר שזורק הרבה משתמשים, גם אלה שמכירים את שורת הפקודה.
לקבלת נקודות בונוס, אתה יכול לבדוק כיצד להעתיק קבצים מרחוק באמצעות SSH מבלי להזין את הסיסמה שלך . שם תלמד קצת יותר על סוגים אחרים של אלגוריתמי הצפנה וכיצד להשתמש בקבצי מפתח לצורך אבטחה נוספת.
