מנהרת SSH של QGIS ו-PostGIS: שמרו על שם השרת עבור TLS

העברת SSH נותנת ל-QGIS פורט מקומי, אבל מסד הנתונים עדיין זקוק לשמו האמיתי עבור TLS. השתמשו בשירות libpq עם hostaddr ומאזין loopback.

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

למה הלקוח חושב שהוא מתחבר

תחת sslmode=verify-full, libpq משווה את התעודה שהשרת מציג לשם המארח שהתבקש. כשהשם הזה הוא כתובת loopback, ההשוואה נכשלת גם אם התעודה תקפה עבור מארח מסד הנתונים האמיתי. העברת SSH משנה איזה שקע נושא את הבתים, לא את הזהות שהלקוח אמור לצפות לה. ברגע ששני הרעיונות האלה מופרדים, השגיאה מפסיקה להיראות כתקלת TLS.

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

קשרו את ההעברה ל-loopback בלבד

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

ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 [email protected]

היעד שאחרי הנקודתיים השנייה נפתר מצד שרת SSH, ולכן הדוגמה הזו מניחה ש-PostgreSQL נמצא באותו מארח כמו sshd; מסד נתונים במכונה אחרת זקוק לכתובת הזו ולהרשאות שלה. הפעילו את הסשן עם -N כדי שלא ייפתח שום מעטפת, הניחו לאימות מפתח המארח והאמתו שהמאזין מופיע לפני שאתם מאשימים את QGIS. אם הפורט כבר בשימוש, ההעברה נכשלת בהפעלה ולא בזמן השאילתה.

שימו את השם ואת השקע ברשומת שירות אחת

קובץ שירות מאפשר לאותו חיבור לשאת שם אימות ויעד שקע אחר. שמרו את הרשומה במקום שבו libpq מחפש שירותים, או כוונו את PGSERVICEFILE אליה.

[gis-via-ssh]
host=db.geo.example
hostaddr=127.0.0.1
port=15432
dbname=gisdb
user=gis_reader
sslmode=verify-full
gssencmode=disable
sslrootcert=/path/to/approved-root.crt

כאן host שומר על הזהות המשמשת לבדיקות תעודה בעוד hostaddr שולח חבילות לפורט ה-loopback המועבר, ושניהם נחוצים כדי שהסדר הזה יעבוד. gssencmode=disable חשוב בגרסאות שאחרת היו מנהלות משא ומתן על הצפנת GSSAPI תחילה, מפני שהמסלול הזה מתעלם מהגדרות ה-TLS שזה עתה הוגדרו. הפנו לשירות בשמו מתיבת הדו-שיח של חיבור PostgreSQL ב-QGIS ומסרו את הסיסמה דרך ההנחיה הרגילה, לא בתוך קובץ משותף. השמות והנתיבים שלמעלה הם מצייני מקום; החליפו אותם בערכים המאושרים שלכם.

מה PostgreSQL עדיין בודק אחרי המנהרה

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

psql "service=gis-via-ssh" -c "select inet_server_addr(), current_user"

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

מאמרים קשורים