העברת מנהרת HTTP CONNECT קיימת אל Paramiko

חברו את Paramiko דרך נתיב HTTP CONNECT מורשה תוך שמירה על אימות מפתח מארח SSH.

לאחר שעוזר HTTP CONNECT החזיר מנהרה לשרת ה-SSH המיועד, מסרו את הזרם הזה ל-Paramiko:

with paramiko.SSHClient() as client:
    client.load_system_host_keys()
    client.connect('ssh.example.com',
                   username='operator',
                   sock=tunnel,
                   banner_timeout=10,
                   auth_timeout=10)
    # Use the verified SSH connection.

החליפו את המארח בדוגמה וטענו את נתוני known-hosts הנכונים של הפריסה. tunnel חייב כבר להוביל לאותו שרת. שם המארח שנמסר ל-connect מזהה את מפתח מארח ה-SSH, ולא את ה-proxy.

ממשק ה-sock מקבל socket פתוח או אובייקט דמוי socket. הוא אינו מנהל משא ומתן HTTP עבורכם. לפני החזרתו, המחבר חייב:

  1. להתחבר ל-proxy ולשלוח בקשת CONNECT תקפה ליעד.
  2. להשלים כל אימות proxy נתמך ולאמת מצב מנהרה מוצלח.
  3. לקרוא את כל קטע הכותרות של ה-proxy, תוך טיפול בקריאות חלקיות ושמירת בייטים מעבר לגבול.
  4. לתחום את ההגדרה ולסגור sockets שנדחו/שגויים דרך נתיב הניקוי שלו.

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

ה-proxy חייב לאפשר את פורט ה-SSH המבוקש; הרשאת גלישה באינטרנט אינה יוצרת גישת CONNECT לפורט 22. 407 מתרחש לפני התחברות SSH, בעוד כשל בחשבון SSH מתרחש לאחר המנהרה. הפרידו בין החשבונות האלה.

סגרו את לקוח ה-SSH ואת המשאבים שבבעלות המחבר כשתסיימו. עצירת הקריאות של משימה אינה סוגרת בעצמה חיבור חי.

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