บางครั้งเราก็ต้องการ ส่งข้อมูลผ่านซ็อกเก็ต ระหว่างเครื่องต่างๆเช่นการเชื่อมต่อ Telnet การดาวน์โหลดไฟล์ FTP แบบสอบถาม SQL หรือการส่งข้อมูลประเภทอื่น ๆ
ข้อมูลนั้นเดินทางผ่านเครือข่ายดังนั้น ไม่ปลอดภัยซึ่งหมายความว่าโหนดใด ๆ ที่อยู่บนเส้นทางระหว่างต้นทางและปลายทางอาจถูกดักฟังได้นั่นคือ โรบาโดส.
เราไม่สามารถป้องกันไม่ให้จับข้อมูลนี้ได้ แต่สิ่งที่เราสามารถป้องกันได้คือข้อมูลนั้นจะถูกตีความและเข้าใจโดยบุคคลที่สามโดยเข้ารหัสการสื่อสาร
SSH เป็นเครื่องมือที่ช่วยให้เราทำ การเชื่อมต่อที่ปลอดภัย ระหว่างเครื่อง การใช้งานโดยทั่วไปคือการเชื่อมต่อจากระยะไกลกับตัวแปลคำสั่ง
อย่างไรก็ตามมีความเป็นไปได้อื่น ๆ เช่นการสร้าง อุโมงค์เข้ารหัส ระหว่างเครื่องต่างๆ
สมมติว่าเราต้องการ telnet จาก host1 ถึง host2:
host1$ telnet host2
การสื่อสารนี้เปิดกว้างโดยสิ้นเชิงและสามารถทำได้ ตัด. เพื่อป้องกันเราจะเปลี่ยนเส้นทางพอร์ตที่เลือกโดยพลการ (เช่น 5000) บนโฮสต์ 1 ไปยังพอร์ต 23 (telnet) บนโฮสต์ 2
ด้วยวิธีนี้เราจะได้รับข้อมูลทั้งหมดที่ส่งไปยังพอร์ต 5000 ของ host1 เพื่อเดินทางที่เข้ารหัสผ่านอุโมงค์ที่ ssh เปิดผ่านพอร์ต 22 ของ host2 จากนั้นจะถูกเปลี่ยนเส้นทางไปยังพอร์ต 23 ของ host2 ซึ่งจะไปถึงปลายทางสุดท้าย
ในการดำเนินการนี้เราจำเป็นต้องทราบชื่อผู้ใช้และรหัสผ่านของ host2
ในการเปิดอุโมงค์เราเขียน:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
O ดี:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
ตัวเลือกทั้งสองเทียบเท่ากัน ในการสร้างการเชื่อมต่อ telnet เราไม่ได้อ้างถึง host2 อีกต่อไป แต่เป็นพอร์ตที่เลือกบน host1:
host1$ telnet localhost 5000
ด้วยเหตุนี้เราจึงทำให้การสื่อสารมีความปลอดภัยไม่ว่าจะเป็นเทลเน็ตหรืออื่น ๆ ตรวจสอบเพิ่มเติมอีกเล็กน้อยเราจะเห็นว่าต้องขอบคุณพลังของ SSH การเปลี่ยนเส้นทางเหล่านี้สามารถทำได้กับเครื่องที่สามซึ่งจะช่วยให้เราสามารถเข้าถึงได้อย่างปลอดภัยจาก LAN ทั้งหมดไปยัง LAN อื่น
ทฤษฎีนี้ดูน่าสนใจมาก แต่จะดียิ่งกว่านั้นถ้าเราเห็นกรณีที่ใช้งานได้จริง
แต่ความจริงก็คือแม้ว่าฉันจะสั้น แต่ฉันก็รักบทความนี้
อาจจะดูวิกิที่คุณได้รับแรงบันดาลใจ https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
และเหมือนกัน แต่เป็นส่วนอัตโนมัติ https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
จริงๆแล้วทุกสิ่งที่คุณสามารถส่งโดย ssh ไม่ว่าจะเป็นการสตรีมการเชื่อมต่อกับโฮสต์ เป็นต้น นั่นด้วยเหตุผล x ที่คุณต้องการเข้ารหัส
และกฎ securecrt
บางครั้งฉันใช้ SSH ในระดับพื้นฐาน พอร์ตเริ่มต้นคือ 22 ใช่ไหม?
ดังนั้นถ้าฉันเข้าใจถูกต้องพีซีของฉันคือโฮสต์ 1 และเครื่องที่ฉันต้องการเชื่อมต่อคือ host2 อุโมงค์นี้จะสร้างการเชื่อมต่อระหว่างพอร์ต 5000 และพอร์ต 23 จากนั้นไปสิ้นสุดที่พอร์ต 22?
ทำไมต้องเปลี่ยนพอร์ต? คุณสามารถสร้างอุโมงค์ด้วยพอร์ต 22 ได้หรือไม่?
บทความที่น่าสนใจมาก เช่นเดียวกับนาโนฉันต้องการมากกว่านี้!
SSH ใช้พอร์ต 22 ตามค่าเริ่มต้น (แม้ว่าจะสามารถเปลี่ยนแปลงได้) พอร์ตนี้เป็นพอร์ตที่จะใช้ในการสื่อสารจริงระหว่างสองโฮสต์ เป็นสิ่งที่คุณต้องแน่ใจว่าเปิดอยู่และไม่มีไฟร์วอลล์ตัดไฟ แต่สำหรับผู้ใช้นั้นโปร่งใสทั้งหมด คุณลืมเขาได้เลย ในตัวอย่างการเปลี่ยนเส้นทางอยู่ระหว่างพอร์ต 5000 ถึง 23 สองพอร์ตนี้เป็นเพียงพอร์ตเดียวที่คุณต้องกังวล ผู้ใช้จะเห็นว่าทุกสิ่งที่เขาส่งไปยังพอร์ต 5000 ของโฮสต์ของเขาปรากฏที่ 23 ของโฮสต์ปลายทาง
เห็นได้ชัดว่าผู้ใช้แต่ละคนสามารถเปลี่ยนเส้นทางพอร์ตที่เขาเห็นว่าเหมาะสมได้
ขอบคุณสำหรับความคิดเห็นของคุณ นี่เป็นกระทู้แรกของฉันและความคิดเห็นของคุณจะช่วยให้บทความถัดไปดีขึ้น
สามารถทำได้ด้วย VPS หรือไม่?
ตกลงนี่เป็นกรณีของฉัน PC1 เข้าถึงเซิร์ฟเวอร์ แต่ PC2 ไม่ได้ทั้งสองเชื่อมต่อด้วย ssh ฉันต้องการเข้าถึงใน PC2 แต่ฉันเปลี่ยนเส้นทางพอร์ตใดของ PC1 ถ้าจริงสิ่งที่ฉันต้องการคือเข้าถึงพอร์ตเซิร์ฟเวอร์จาก PC2 และแพ็กเก็ตนั้นมี PC1 เป็น IP ต้นทาง ฉันเข้าใจไหม
คุณทำให้ตัวเองเข้าใจ ในกรณีนี้คุณต้องใช้ PC1 เพื่อเปลี่ยนเส้นทางพอร์ตของ PC2 ไปยังพอร์ต 22 ของเซิร์ฟเวอร์:
PC2 $ ssh -L 5000: เซิร์ฟเวอร์: ผู้ใช้ 22 คน PC1 @ PC1
และทำให้การเชื่อมต่อนี้เปิดอยู่จากเทอร์มินัลอื่น:
PC2 $ ssh userServer @ localhost -p 5000
และคุณอยู่ข้างในแล้ว
ในที่สุดโซลูชั่นที่ใช้งานได้ !! ขอบคุณ Getafix ที่มอบโลกแห่งความเป็นไปได้ให้ฉัน !!
ฉันดีใจ!
บทความที่ยอดเยี่ยม ยินดีต้อนรับสู่ DesdeLinux ????
และจะทำอย่างไรถ้าเรามี 22 บล็อก? ฮ่า ๆ..
ขอบคุณ elav
หากคุณมีพอร์ต 22 ถูกบล็อกอืมเราจะต้องมองหาทางเลือกอื่นในการแฮ็กไฟร์วอลล์ XD
และที่แย่ที่สุด (สมมุติฐาน): ถูกบล็อกโดยผู้ให้บริการ VPS
ฉันเพิ่งทำข้อสอบเมื่อไม่กี่ชั่วโมงก่อนโดยมีคำถามเกี่ยวกับเรื่องนี้😛
ฉันจะไม่พูดอย่างนั้น:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
มันเทียบเท่ากับบรรทัดคำสั่งอื่น ... บรรทัดที่มี -L
เนื่องจาก -R ระบุว่าพอร์ตที่เปิดสำหรับการเชื่อมต่อใหม่อยู่ทางด้านระยะไกลนั่นคือที่ด้านข้างของเซิร์ฟเวอร์ ssh ของคุณ ในขณะที่ -L เปิดพอร์ตในฝั่ง Local บนฝั่งไคลเอ็นต์เพื่อรับการเชื่อมต่อใหม่
คำแปลของบรรทัด:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
มันจะเป็นแบบนี้: เมื่ออยู่บน host1 ให้เชื่อมต่อกับเซิร์ฟเวอร์ ssh (พอร์ต 22) ของ host2 กับผู้ใช้ของฉัน userhost2 และส่งต่อการเชื่อมต่อที่สร้างบนพอร์ตระยะไกล 5000 ของ host2 ไปยังพอร์ต 23 บน host1 (localhost ของฉัน)
ถ้าไม่ถูกต้องฉัน! 😉
-
ในทางกลับกัน ... หากเซิร์ฟเวอร์ปิดกั้นการเข้าสู่พอร์ต 22 นั่นคือเราไม่สามารถเชื่อมต่อจากระยะไกลไปยังเซิร์ฟเวอร์ ssh ได้ สิ่งที่ทำได้คือ; จากเซิร์ฟเวอร์ (sysadmin เพื่อนที่อยู่เบื้องหลังไฟร์วอลล์ของระบบรีโมตโฮสต์ 2) บรรทัดคำสั่งจะถูกดำเนินการ:
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f ไปที่พื้นหลัง
-N ไม่ดำเนินการคำสั่งใด ๆ บนรีโมท
nohup ป้องกันไม่ให้การดำเนินการของคำสั่งหยุดชะงักเมื่อออกจากระบบ
host1 $ ssh userhost2 @ localhost -p 6000
ด้วยวิธีนี้จาก host1 เราสร้างการเชื่อมต่อไปยัง localhost (host1 เดียวกัน) บนพอร์ต 6000 ซึ่งจะส่งต่อการเชื่อมต่อไปยังพอร์ต 22 ของโฮสต์ระบบระยะไกล 2 ซึ่งเราจะเข้าสู่ระบบด้วยโฮสต์ผู้ใช้ 2
สิ่งนี้จะช่วยให้ (ฉันไม่ได้ลอง แต่ดูเหมือนจะใช้งานได้) เข้าสู่เซิร์ฟเวอร์ ssh ที่ถูก firewal บล็อกด้วยความช่วยเหลือเล็กน้อยจากภายใน! 😀
ตอนหลังฉันอ่านจากคำอธิบายในนิตยสาร The Geek Stuff
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
ฉันชอบสิ่งพิมพ์ของคุณมาก ฉันอ่านบ่อยๆ!
อาศิรพจน์
คุณพูดถูก มีข้อผิดพลาดในบทความ การเปลี่ยนเส้นทางไม่เทียบเท่า คำสั่ง host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 ดำเนินการเปลี่ยนเส้นทางแบบย้อนกลับนั่นคือมันเปลี่ยนทิศทางพอร์ตระยะไกล 5000 ไปยัง 23 โลคัลซึ่งตรงข้ามกับคำสั่งที่มี -L ทำ
ขอบคุณสำหรับการแก้ไข