SSH คืออะไรและทำงานอย่างไร

Secure Shell (SSH) เป็นโปรโตคอลความปลอดภัยที่ใช้กันทั่วไปพร้อมกับการใช้งานที่หลากหลาย แอปพลิเคชั่นที่โด่งดังที่สุดช่วยให้ผู้ใช้ เข้าถึงคอมพิวเตอร์และเซิร์ฟเวอร์ระยะไกลอย่างปลอดภัย, แต่มันยังสามารถใช้สำหรับการขุดอุโมงค์การส่งต่อพอร์ตการถ่ายโอนไฟล์ที่ปลอดภัยและอีกมากมาย.

ในคู่มือนี้เราจะกล่าวถึง SSH คืออะไรใช้สำหรับประวัติของโปรโตคอลรายละเอียดทางเทคนิค, เช่นเดียวกับ ปัญหาด้านความปลอดภัย ที่ต้องนำมาพิจารณาด้วย.

SSH ประกอบด้วยสามโปรโตคอลแยก: ชั้นการขนส่ง, ชั้นการตรวจสอบและชั้นการเชื่อมต่อ. ร่วมกันเหล่านี้ทำหน้าที่ในการตรวจสอบบุคคลอื่นในการเชื่อมต่อให้ความลับผ่านการเข้ารหัสและตรวจสอบความสมบูรณ์ของข้อมูล ตอนนี้ SSH ถูกนำไปใช้บ่อยที่สุดในฐานะที่เป็นกรรมสิทธิ์ของ SSH-2 หรือเป็นการทำซ้ำโอเพนซอร์ส, OpenSSH.

การใช้ประโยชน์จาก SSH

SSH เป็นโปรโตคอลที่หลากหลาย โครงสร้างและคุณสมบัติด้านความปลอดภัยช่วยให้สามารถใช้งานได้หลายวิธีเช่นการเข้าถึงระยะไกลการส่งต่อพอร์ตการขุดอุโมงค์และการถ่ายโอนไฟล์ที่ปลอดภัย.

การเข้าถึงระยะไกล

การเข้าถึงระยะไกลทำให้ผู้ใช้มีวิธีในการ เข้าสู่ระบบคอมพิวเตอร์หรือเซิร์ฟเวอร์อื่นจากเครื่องของตนเอง. มันถูกใช้เพื่อเข้าถึงไฟล์ภายในเครื่องของเป้าหมายหรือให้บริการกับมันโดยไม่ต้องอยู่ที่นั่น.

โปรแกรมอย่าง Telnet และ rlogin ก็มีฟังก์ชั่นนี้เช่นกัน แต่ไม่มีคุณสมบัติด้านความปลอดภัยของ SSH มาตรการการเข้ารหัสและการรับรองความถูกต้องที่เกี่ยวข้องกับ SSH ช่วยให้ผู้ใช้เชื่อมต่อกับเซิร์ฟเวอร์หรือคอมพิวเตอร์เครื่องอื่นในลักษณะที่ได้รับการป้องกันแม้ผ่านเครือข่ายกลางที่อาจเป็นอันตราย.

การเข้าถึงระยะไกลด้วย SSH นั้นถูกนำมาใช้เพื่อให้พนักงานสามารถทำงานจากระยะไกลหรืออนุญาตให้แผนกไอทีทำงานให้สำเร็จโดยไม่ต้องไปที่เครื่อง สามารถใช้สำหรับการดูแลระยะไกลการจัดการโครงสร้างพื้นฐานเครือข่ายเพื่อตั้งค่าระบบอัตโนมัติสร้างการสำรองข้อมูลและอื่น ๆ.

การส่งต่อพอร์ต

การส่งต่อพอร์ตใช้เพื่อโอนคำขอจากที่อยู่หนึ่งและหมายเลขพอร์ตไปยังอีกชุดหนึ่ง มันใช้การแปลที่อยู่เครือข่าย (NAT) เพื่อเปลี่ยนเส้นทางพอร์ตระหว่างเครือข่ายท้องถิ่นและคอมพิวเตอร์ระยะไกลช่วยให้คุณสามารถเข้าถึงอุปกรณ์จากนอกเครือข่าย.

การส่งต่อพอร์ตสามารถทำได้สามวิธี:

• ในประเทศ การส่งต่อพอร์ต – การส่งต่อพอร์ตท้องถิ่นช่วยให้คุณสามารถเชื่อมต่อลูกค้าในพื้นที่ของคุณและเครือข่ายภายนอก มันจะมีประสิทธิภาพสำหรับการทำสิ่งต่าง ๆ เช่นการเข้าถึงเว็บไซต์ที่ถูกบล็อกในเครื่องหรือการเชื่อมต่อกับฐานข้อมูลที่อยู่หลังไฟร์วอลล์.
• การส่งต่อพอร์ตระยะไกล – การส่งต่อประเภทนี้ช่วยให้แอปพลิเคชันฝั่งเซิร์ฟเวอร์เข้าถึงบริการบนฝั่งไคลเอ็นต์ การส่งต่อพอร์ตระยะไกลของ SSH ช่วยให้ผู้ใช้เชื่อมต่อกับเซิร์ฟเวอร์ระยะไกลอย่างปลอดภัยผ่านพีซีในพื้นที่ของพวกเขาโดยเปลี่ยนเส้นทางพอร์ตท้องถิ่นไปยังเซิร์ฟเวอร์ SSH ระยะไกล.
• พลวัต การส่งต่อพอร์ต – สิ่งนี้ช่วยให้ผู้ใช้ส่งข้อมูลผ่านพอร์ตเฉพาะไปยังคอมพิวเตอร์ระยะไกลหรือเซิร์ฟเวอร์โดยใช้เซิร์ฟเวอร์ SSH จำนวนมากที่ทำหน้าที่เป็นพร็อกซี่.

tunneling

โปรโตคอลการทันเนลใช้การห่อหุ้มเพื่อย้ายข้อมูลระหว่างเครือข่าย สามารถปรับใช้อุโมงค์เพื่อให้โปรโตคอลที่ไม่ใช่เจ้าของภาษาสามารถทำงานผ่านเครือข่ายที่ปกติจะไม่สนับสนุน การใช้งานทั่วไปอื่นสำหรับ ให้ความปลอดภัยผ่านเครือข่ายที่ไม่ปลอดภัย.

โพรโทคอล Tunneling ห่อแพ็กเก็ตที่สำคัญภายในเพย์โหลดของแพ็กเก็ตอื่น SSH tunneling ช่วยให้ผู้ใช้สามารถหลีกเลี่ยงการรักษาความปลอดภัยเครือข่ายเชื่อมโยงอุปกรณ์โดยใช้โปรโตคอลเครือข่ายที่ไม่ใช่แบบดั้งเดิมและเพื่อรักษาความปลอดภัยข้อมูลที่ถูกส่ง มักใช้เพื่อเชื่อมต่อผู้ใช้ระยะไกลกับแหล่งข้อมูลออนไลน์ขององค์กรอย่างปลอดภัย.

SFTP

SSH File Transfer Protocol (FTP) บางครั้งเรียกว่า Secure File Transfer Protocol มีวิธีที่ปลอดภัยในการเข้าถึงถ่ายโอนและจัดการไฟล์ มันเป็นทางเลือกที่ปลอดภัยสำหรับ FTP และใช้ประโยชน์จากโปรโตคอล SSH เพื่อส่งรับและจัดการไฟล์อย่างปลอดภัย.

SCP

Secure Copy Protocol (SCP) นั้นคล้ายกับ SFTP แต่มีข้อ จำกัด ในขอบเขตมากกว่า อนุญาตเฉพาะการถ่ายโอนไฟล์ที่ปลอดภัยแทนที่จะเป็นชุดคุณสมบัติที่อนุญาตให้ SFTP ทำหน้าที่เป็นโปรโตคอลระบบไฟล์ระยะไกล.

แพลทฟอร์ม & แอปพลิเคชันที่ใช้ SSH

SSH หรือ OpenSSH ที่เป็นกรรมสิทธิ์สามารถใช้ได้กับระบบปฏิบัติการหลักทั้งหมด สามารถใช้งานได้บนแพลตฟอร์มที่ใช้ Unix เช่น OpenBSD, macOS, Linux และ Solaris ในขณะที่ผู้ใช้ Windows สามารถใช้ SSH ผ่าน PowerShell.

ประวัติความเป็นมาของ SSH

SSH ได้รับการพัฒนาที่มหาวิทยาลัยเทคโนโลยีแห่งเฮลซิงกิในปี 1995 โดย Tatu Ylönenเพื่อตอบโต้การโจมตีด้วยรหัสผ่านบนเครือข่ายของมหาวิทยาลัย มันมีวัตถุประสงค์เพื่อให้ทางเลือกกับโปรโตคอลเช่น FTP, TELNET, rsh และ rlogin, ซึ่งไม่รับประกันความลับหรือรับรองความถูกต้องของผู้ใช้ในลักษณะที่ปลอดภัย.

SSH ถูกปล่อยให้เป็นอิสระแก่สาธารณะในปี 1995 และได้รับการตอบรับดี ท่ามกลางการยอมรับอย่างรวดเร็วYlönenก่อตั้ง SSH Communications Security ภายในสิ้นปีเดียวกันเพื่อดำเนินการพัฒนาและทำการค้า SSH ต่อไป.

ในปีพ. ศ. 2538 Ylönenได้ตีพิมพ์ร่าง Internet Task Task (IETF) Internet Draft ด้วย จัดทำเอกสารโปรโตคอล SSH-1. พบข้อ จำกัด ในโปรโตคอลในไม่ช้าและไม่สามารถแก้ไขได้โดยไม่ส่งผลต่อความเข้ากันได้ย้อนหลัง การแก้ปัญหาเป็นโปรโตคอลรุ่นใหม่และ SSH-2 เปิดตัวโดย บริษัท ของYlönenในปี 1996.

SSH-2 เป็นอัลกอริธึมใหม่ที่โดดเด่นซึ่งทำให้ IETF พบกลุ่มทำงานที่มีเป้าหมายเพื่อสร้างมาตรฐานโปรโตคอล กลุ่มได้รับฉายา SECSH สำหรับ วินาทีure Shell และเผยแพร่ Internet Draft ครั้งแรกสำหรับ SSH-2 ในปี 1997.

ซอฟต์แวร์สำหรับ SSH-2 เปิดตัวในปี 2541 แต่ไม่ได้รับการยอมรับอย่างแพร่หลายในทันทีเนื่องจากมีใบอนุญาตที่เข้มงวดกว่า. ในปี 2549 โปรโตคอลที่ได้รับการดัดแปลงเป็นมาตรฐานโดย IETF. นี่คือความปลอดภัยมากขึ้นโดยใช้รหัสการตรวจสอบข้อความเพื่อตรวจสอบความสมบูรณ์และการแลกเปลี่ยนคีย์ Diffie-Hellman สำหรับการตรวจสอบความถูกต้อง.

ในปี 1999 โครงการ OpenBSD เปิดตัว OpenSSH. OpenSSH เป็นโปรโตคอลฟรี ขึ้นอยู่กับการดัดแปลงแก้ไขที่BjörnGrönvallทำกับ SSH 1.1.12 นักพัฒนากลับไปใช้รุ่นเก่านี้และเปลี่ยนแปลงอย่างมากเพราะเป็นเวอร์ชั่นสุดท้ายของ SSH ที่เป็นโอเพ่นซอร์สอย่างสมบูรณ์ ตอนนี้ OpenSSH เป็นตัวเลือกที่ใช้กันอย่างแพร่หลายและได้ถูกนำไปใช้ในระบบปฏิบัติการต่างๆเช่น Windows, MacOS, Linux, Solaris และอื่น ๆ.

SSH-1 กับ SSH-2 เทียบกับ OpenSSH

ตามที่ระบุไว้ข้างต้น SSH-1 เป็นรุ่นแรกของโปรโตคอลซึ่งเปิดตัวครั้งแรกภายใต้ ใบอนุญาตโอเพนซอร์ซ. ถือว่าไม่ปลอดภัยและไม่ควรนำมาใช้ สิ่งนี้ทำให้รุ่นที่เป็นกรรมสิทธิ์, SSH-2, และรุ่นที่มีอิสระ, OpenSSH เป็นทางเลือกที่ทำงานได้.

SSH-2 และ OpenSSH นั้นเหมือนกันเมื่อพูดถึงสถาปัตยกรรมและวิธีการทำงานของพวกเขา ข้อแตกต่างที่สำคัญคือรุ่นที่เป็นกรรมสิทธิ์นั้นมาพร้อมกับตัวเลือกการสนับสนุนที่หลากหลายในขณะที่รุ่นที่ใช้ OpenSSH จำเป็นต้องพึ่งพาทรัพยากรที่สร้างขึ้นโดยชุมชน.

SSH: รายละเอียดทางเทคนิค

SSH-1 ทำหน้าที่เป็นโปรโตคอลเดียว แต่เราจะไม่เข้าไปที่นี่เพราะมันล้าสมัย แต่เราจะเน้นที่ SSH-2 และ OpenSSH ซึ่งประกอบด้วยโปรโตคอลที่แยกกันสามตัว:

• โปรโตคอลการขนส่ง – สิ่งนี้จะสร้างการเชื่อมต่อและให้ความปลอดภัยพื้นฐาน.
• โปรโตคอลการตรวจสอบ – เลเยอร์นี้ใช้เพื่อตรวจสอบสิทธิ์ลูกค้า.
• โปรโตคอลการเชื่อมต่อ – โปรโตคอลนี้จัดการช่องสัญญาณที่ส่งข้อมูล.

แต่ละโพรโทคอลเหล่านี้ทำหน้าที่มีลักษณะเฉพาะที่ทำงานเพื่อสร้างและรักษาความปลอดภัยการเชื่อมต่อรับรองความถูกต้องของอีกฝ่ายและถ่ายโอนข้อมูล พอร์ตการเชื่อมต่อ TCP เริ่มต้นคือ 22 และการเชื่อมต่อถูกตั้งค่าระหว่างไคลเอนต์ SSH และเซิร์ฟเวอร์ SSH ตาม รูปแบบไคลเอนต์ – เซิร์ฟเวอร์.

กระบวนการล็อกอินระยะไกลของ SSH ดำเนินการตามโครงสร้างพื้นฐานต่อไปนี้ (พร้อมการเปลี่ยนแปลงขึ้นอยู่กับการกำหนดค่า) ซึ่งเราจะกล่าวถึงรายละเอียดเพิ่มเติมในภายหลัง:

• ไคลเอ็นต์ติดต่อเซิร์ฟเวอร์ SSH เพื่อเริ่มการเชื่อมต่อ.
• จากนั้นเซิร์ฟเวอร์จะส่งกุญแจสาธารณะไปยังลูกค้าเพื่อตรวจสอบตัวตนของมัน.
• ทั้งสองฝ่ายเจรจาต่อรองพารามิเตอร์สำหรับการเชื่อมต่อจากนั้นสร้างช่องทางที่ปลอดภัยตามสายเหล่านั้น.
• จากนั้นผู้ใช้ล็อกอินเข้าสู่ระบบปฏิบัติการของโฮสต์เซิร์ฟเวอร์และสามารถจัดการงานของพวกเขาได้จากระยะไกล.

โปรโตคอลการขนส่ง

transport layer เป็นโปรโตคอลระดับต่ำที่ดูแลงานต่อไปนี้.

• ตรวจสอบโฮสต์เซิร์ฟเวอร์
• แลกเปลี่ยนกุญแจ
• การเข้ารหัสเพื่อรักษาความลับของข้อมูล
• การตรวจสอบความสมบูรณ์เพื่อตรวจสอบว่าข้อมูลไม่ได้ถูกเปลี่ยนแปลง
• สร้างรหัสเซสชันซึ่งสามารถใช้ในโปรโตคอลอื่น

transport protocol พิสูจน์ตัวตนเซิร์ฟเวอร์เท่านั้นและไม่ใช่ไคลเอ็นต์ (การตรวจสอบลูกค้าจะทำในโปรโตคอลการตรวจสอบถ้าจำเป็น).

ในเลเยอร์การขนส่งการเชื่อมต่อจะเริ่มต้นโดยไคลเอนต์และทั้งสองฝ่ายจะเจรจากันว่าจะแลกเปลี่ยนคีย์ได้อย่างไรซึ่งจะใช้อัลกอริธึมกุญแจสาธารณะซึ่งจะใช้การเข้ารหัสลับแบบสมมาตรในคีย์ข้อมูล เพื่อตรวจสอบข้อมูลและวิธีการบีบอัด (ถ้ามี) ที่จะถูกนำไปใช้.

เมื่อการเชื่อมต่อเริ่มต้นขึ้นทั้งเซิร์ฟเวอร์และไคลเอนต์จำเป็นต้องส่งผ่านสตริงการระบุซึ่งรวมถึงรุ่นโปรโตคอล (2.0).

การเจรจาอัลกอริทึม

ในการตั้งค่าพารามิเตอร์ของการเชื่อมต่อทั้งสองฝ่ายส่งผ่านแพ็กเก็ตที่มีรายการพร้อมตัวเลือกต่อไปนี้:

ไบต์ SSH_MSG_KEXINIT

ไบต์ [16] คุกกี้ (สุ่มไบต์)
ชื่อรายการ kex_algorithms
รายชื่อ server_host_key_algorithms
ชื่อรายการเข้ารหัส _algorithms_client_to_server
ชื่อรายการเข้ารหัส _algorithms_server_to_client
รายชื่อ mac_algorithms_client_to_server
รายชื่อ mac_algorithms_server_to_client
รายการชื่อการบีบอัด _ อัลกอริทึม _client_to_server
รายการชื่อการบีบอัด _ อัลกอริทึม _server_to_client
รายชื่อ languages_client_to_server
รายชื่อ languages_server_to_client
บูลีน first_kex_packet_follows
uint32 0 (สงวนไว้สำหรับส่วนขยายในอนาคต)

แต่ละด้านแสดงรายการพารามิเตอร์ที่พวกเขายินดีที่จะยอมรับในการเชื่อมต่อโดยคั่นด้วยเครื่องหมายจุลภาค อัลกอริทึมที่ต้องการควรจะระบุไว้ก่อน.

สำหรับ การแลกเปลี่ยนที่สำคัญ (kex_algorithms) อัลกอริทึมแรกที่ทั้งสองฝ่ายสนับสนุนจะถูกเลือกสำหรับการเชื่อมต่อ (อาจมีปัจจัยอื่น ๆ ที่จำเป็นต้องพบขึ้นอยู่กับอัลกอริทึมที่ได้รับเลือก) หากทั้งสองฝ่ายไม่พบอัลกอริทึมที่ได้รับการสนับสนุนซึ่งตรงตามข้อกำหนดเหล่านี้แสดงว่าการเชื่อมต่อล้มเหลว.

อัลกอริทึมของคีย์โฮสต์เซิร์ฟเวอร์ เป็นอัลกอริธึมที่รองรับสำหรับโฮสต์ของเซิร์ฟเวอร์ เซิร์ฟเวอร์วางอัลกอริธึมที่มีคีย์โฮสต์ให้ในขณะที่ไคลเอ็นต์ระบุอัลกอริทึมที่เตรียมไว้ให้ยอมรับ การเลือกจะขึ้นอยู่กับว่าวิธีการแลกเปลี่ยนคีย์ที่ตัดสินตามนั้นต้องใช้คีย์โฮสต์ที่มีความสามารถในการเข้ารหัสหรือลายเซ็นดิจิทัล

ทั้งสองรายการ อัลกอริธึม – กุญแจสมมาตร พวกเขายินดีที่จะยอมรับด้วยวิธีการที่ต้องการด้านบน ตัวเลือกแรกที่ปรากฏในรายการของลูกค้าที่ต้องอยู่ในรายการเซิร์ฟเวอร์จะต้องใช้ด้วย หากไม่มีข้อตกลงสามารถทำการเชื่อมต่อล้มเหลว.

ทั้งคู่ อัลกอริทึม MAC และ อัลกอริทึมการบีบอัด มีการเจรจาในลักษณะเดียวกัน.

แลกเปลี่ยนกุญแจ

การแลกเปลี่ยนกุญแจรับผิดชอบ การตรวจสอบเซิร์ฟเวอร์, และมัน ตั้งค่าปุ่มที่จะใช้เพื่อรักษาความปลอดภัยการเชื่อมต่อ ในขั้นตอนต่อไปนี้ โดยทั่วไปแล้วเริ่มต้นด้วยฝ่ายที่ส่งรายการอัลกอริธึมที่สนับสนุนให้กัน อีกทางหนึ่งแต่ละด้านสามารถคาดเดาอัลกอริทึมที่ต้องการของอีกด้านหนึ่งและส่งแพ็กเก็ตที่เหมาะกับพารามิเตอร์ของอัลกอริทึมในตอนเริ่มต้น.

หากการเดาของฝ่ายหนึ่งถูกต้องแพ็กเก็ตนั้นจะถูกใช้เป็นแพ็กเก็ตแลกเปลี่ยนคีย์แรก หากเดาไม่ถูกต้องแต่ละด้านจะต้องย้อนกลับไปและส่งรายการอัลกอริทึมที่ต้องการ หากข้อความแลกเปลี่ยนกุญแจมีลายเซ็นดิจิทัลของเซิร์ฟเวอร์เป็นหลักฐานการพิสูจน์ความถูกต้องของเซิร์ฟเวอร์ก็จะถือว่าเป็น รับรองความถูกต้องของเซิร์ฟเวอร์ที่ชัดเจน. หากใช้ความลับร่วมกันแทนจะถูกเรียกว่า การพิสูจน์ตัวตนเซิร์ฟเวอร์โดยนัย.

การแลกเปลี่ยนที่สำคัญยังรับผิดชอบในการสร้างความลับร่วมกันและแฮช ค่าแฮชจากการแลกเปลี่ยนคีย์เริ่มต้นกลายเป็นตัวระบุที่ไม่ซ้ำกันสำหรับเซสชันและยังใช้เป็นส่วนหนึ่งของลายเซ็นดิจิทัลที่พิสูจน์ว่าปาร์ตี้เป็นเจ้าของที่แท้จริงของคีย์ส่วนตัว.

ฟังก์ชันแฮชที่ใช้จะขึ้นอยู่กับวิธีการแลกเปลี่ยนคีย์ที่ตัดสินใจในการเจรจา เมื่อการแลกเปลี่ยนกุญแจเสร็จสิ้นการสื่อสารในอนาคตทั้งหมดจะใช้ชุดคีย์และอัลกอริธึมใหม่.

ตามที่ Internet Internet Task Task (IETF) Internet Draft วิธีการแลกเปลี่ยนที่สำคัญดังต่อไปนี้ได้รับการพิจารณาว่าปลอดภัย:

• curve25519-SHA256
• curve448-SHA512
• Diffie-Hellman กลุ่มแลกเปลี่ยน-SHA256
• Diffie-Hellman-group14-SHA256
• Diffie-Hellman-group15-SHA512
• Diffie-Hellman-group16-SHA512
• Diffie-Hellman-group17-SHA512
• Diffie-Hellman-group18-SHA512
• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• GSS-group14-SHA256
• GSS-group15-SHA512
• GSS-group16-SHA512
• GSS-group17-SHA512
• GSS-group18-SHA512
• GSS-nistp256-SHA256
• GSS-nistp384-SHA384
• GSS-nistp521-SHA512
• GSS-curve25519-SHA256
• GSS-curve448-SHA512
• rsa2048-SHA256

อัลกอริทึมของคีย์โฮสต์เซิร์ฟเวอร์

อัลกอริธึมกุญแจสาธารณะเหล่านี้ใช้สำหรับ ตรวจสอบเซิร์ฟเวอร์เช่นเดียวกับการสร้างรหัสเซสชันที่ใช้ร่วมกันอย่างปลอดภัย. พวกเขายังสามารถใช้เพื่อรับรองความถูกต้องของโฮสต์ SSH ถูกออกแบบมาเพื่อทำงานกับช่วงของอัลกอริทึมกุญแจสาธารณะประเภทการเข้ารหัสและรูปแบบ:

• มันใช้อัลกอริทึมกุญแจสาธารณะสำหรับการเข้ารหัสและ / หรือลายเซ็นดิจิทัล.
• สามารถใช้วิธีการเข้ารหัสได้หลากหลายซึ่งช่วยให้สามารถกำหนดค่าด้วยรูปแบบข้อมูลที่แตกต่างกันการแพ็ดดิ้งและการเรียงลำดับไบต์.
• รูปแบบคีย์ที่หลากหลายช่วยให้สามารถเข้ารหัสคีย์ได้หลายวิธีรวมถึงช่วงของการรับรองใบรับรอง.

อัลกอริทึมเริ่มต้นรวมถึงสิ่งต่อไปนี้อย่างไรก็ตามยังมีความหลากหลายของรูปแบบอื่น ๆ ที่สามารถนำไปใช้ได้:

• SSH-RSA
• SSH-RSA-SHA256
• SSH-DSS
• SSH-DSS-SHA256
• x509v3-Sign-DSS
• x509v3-Sign-DSS-SHA256
• x509v3 ลงชื่อ RSA
• x509v3 ลงชื่อ RSA-SHA256

อัลกอริทึมการเข้ารหัส

ใช้อัลกอริธึมคีย์สมมาตร เข้ารหัสข้อมูลและให้การรักษาความลับ. พารามิเตอร์และคีย์ที่ใช้ร่วมกันที่ใช้ในกระบวนการเข้ารหัสถูกสร้างขึ้นในเฟสก่อนหน้าของการเชื่อมต่อ อัลกอริทึมที่เลือกจะเข้ารหัสเพย์โหลดความยาวของแพ็คเก็ตความยาวการแพ็ดและฟิลด์การแพ็ด.

ช่วงของอัลกอริทึมการเข้ารหัสที่แตกต่างกันนั้นได้รับการยอมรับใน SSH แต่เพื่อความปลอดภัยควรใช้ AES คีย์ควรมีอย่างน้อย 128 บิต แต่ต้องการรหัสที่ใหญ่กว่า.

อัลกอริธึม MAC

โปรโตคอลการขนส่ง ตรวจสอบความถูกต้องของข้อมูลโดยการเพิ่มข้อความการรับรองความถูกต้องของข้อความ (MAC) ไปยังแพ็กเก็ต. MAC นี้ขึ้นอยู่กับความลับที่ใช้ร่วมกัน (ซึ่งจัดตั้งขึ้นในการแลกเปลี่ยนคีย์) หมายเลขลำดับของแพ็คเก็ตและเนื้อหาของแพ็คเก็ต มันถูกคำนวณก่อนการเข้ารหัสจะเกิดขึ้น.

การนำไปใช้งานจำเป็นต้องเสนออัลกอริธึมที่เป็นอิสระเพื่อให้ทำงานในแต่ละทิศทางแม้ว่าจะเป็นวิธีที่ดีถ้าใช้ทั้งสองฝั่งเดียวกัน อัลกอริธึมการพิสูจน์ตัวตนข้อความที่หลากหลายสามารถนำมาใช้ได้อย่างไรก็ตามควรใช้ SHA-256 ขึ้นไปในสถานการณ์ส่วนใหญ่เพื่อให้มั่นใจในความปลอดภัยระดับสูง.

การอัด

การบีบอัดไม่ได้บังคับในโปรโตคอล SSH และการใช้งานจะต้องอนุญาตการเชื่อมต่อเพื่อดำเนินการต่อโดยไม่มีการบีบอัด การบีบอัดสามารถทำได้ในรูปแบบตัวเลือกโดยใช้แบบแผนเช่น zlib. หากมีการใช้การบีบอัดจะมีผลกับน้ำหนักบรรทุกเท่านั้น จากนั้นฟิลด์ MAC และฟิลด์ความยาวของแพ็กเก็ตจะถูกคำนวณตามอัตราที่บีบอัด.

โปรโตคอลการขนส่งแพ็คเก็ต

แพ็คเก็ตโปรโตคอลการขนส่งถูกจัดรูปแบบเพื่อรวมข้อมูลต่อไปนี้ (รวมถึงรายละเอียดที่เกี่ยวข้องน้อยกว่าซึ่งถูกทิ้งไว้):

• ความยาวของแพ็กเก็ต
• ความยาวของช่องว่างภายใน
• ส่วนของข้อมูล
• การขยายความ
• รหัสตรวจสอบข้อความ (MAC)

โปรโตคอลการตรวจสอบ

โปรโตคอลนี้ใช้โดยเซิร์ฟเวอร์เพื่อ ตรวจสอบลูกค้า. มันสามารถทำได้ด้วยกลไกที่แตกต่างหลากหลายซึ่งหลายคนอาศัย ID เซสชั่นที่จัดตั้งขึ้นในโปรโตคอลการขนส่ง บางคนใช้การเข้ารหัสและการตรวจสอบความสมบูรณ์จากโปรโตคอลการขนส่งร่วมกับรหัสเซสชันในขณะที่คนอื่นใช้อัลกอริทึมเหล่านี้ด้วยตนเอง.

เซิร์ฟเวอร์ใช้นโยบายโลคัลเพื่อตัดสินใจว่าวิธีการพิสูจน์ตัวตนใดที่จะยอมรับจากผู้ใช้แต่ละราย เนื่องจากเซิร์ฟเวอร์ได้รับการรับรองความถูกต้องแล้วในโปรโตคอลการขนส่ง, ไม่จำเป็นต้องตรวจสอบเซิร์ฟเวอร์อีกครั้ง.

ความปลอดภัยของโปรโตคอลการตรวจสอบความถูกต้องขึ้นอยู่กับโปรโตคอลการขนส่งที่ทำงานอยู่ด้านบน หากโปรโตคอลการขนส่งไม่สามารถรับประกันความลับหรือตรวจสอบความถูกต้องของข้อมูลได้นี่จะเป็นการ จำกัด วิธีการใช้โปรโตคอลการตรวจสอบความปลอดภัยอย่างปลอดภัย.

ตัวอย่างเช่นหากการป้องกันความสมบูรณ์ไม่ได้ถูกนำไปใช้โดยโปรโตคอลการขนส่งดังนั้นการร้องขอเช่นการเปลี่ยนรหัสผ่านไม่ควรได้รับอนุญาตเพราะจะทำให้ผู้โจมตีสามารถยุ่งเกี่ยวกับข้อมูลโดยไม่ต้องสังเกต.

โปรโตคอลการตรวจสอบความถูกต้องใช้การรับรองความถูกต้องของรหัสสาธารณะภายใต้ข้อสันนิษฐานว่าไม่มีคีย์ส่วนตัวของโฮสต์เซิร์ฟเวอร์หรือคีย์ของโฮสต์ไคลเอนต์. หากเซิร์ฟเวอร์ถูกโจมตีสิ่งนี้อาจนำไปสู่ชื่อผู้ใช้และรหัสผ่านของลูกค้าที่ถูกปล่อยออกไปยังผู้โจมตี.

สำหรับการรับรองความถูกต้องตามโฮสต์จะปลอดภัยลูกค้าจะต้องไม่ถูกบุกรุก หากเป็นไปได้ควรเพิ่มวิธีการรับรองความถูกต้องอื่น ๆ สิ่งสำคัญที่ควรทราบคือ กระบวนการพิสูจน์ตัวตนมีความแรงเท่ากับวิธีการแลกเปลี่ยนอ่อนที่สุดที่เซิร์ฟเวอร์ยอมรับ.

กระบวนการโพรโทคอลการรับรองความถูกต้อง

โพรโทคอลการรับรองความถูกต้องเริ่มต้นเมื่อเซิร์ฟเวอร์ส่งรายการวิธีการรับรองความถูกต้องที่ยอมรับให้กับลูกค้า ลูกค้าสามารถเลือกวิธีการเหล่านี้ในลำดับใดก็ได้ กระบวนการนี้ให้การควบคุมเซิร์ฟเวอร์ แต่ยังให้ความยืดหยุ่นเพียงพอเพื่อให้ลูกค้าสามารถจัดเรียงเพื่อใช้วิธีที่สะดวกที่สุด.

วิธีการตรวจสอบลูกค้าที่พบบ่อยที่สุด ได้แก่ :

• กุญแจสาธารณะ – วิธีนี้ใช้อัลกอริทึมเช่น RSA, DSA และ ECDSA เพื่อตรวจสอบสิทธิ์ลูกค้าผ่านการเข้ารหัสคีย์สาธารณะ การใช้งานบางอย่างใช้ใบรับรอง x.509 เช่นกัน เซิร์ฟเวอร์ตรวจสอบลายเซ็นดิจิตอลของลูกค้ากับกุญแจสาธารณะของพวกเขาเพื่อตรวจสอบตัวตนของลูกค้า.
• รหัสผ่าน – รหัสผ่านสามารถใช้เพื่อตรวจสอบสิทธิ์ลูกค้า ไคลเอนต์ส่งรหัสผ่าน (ซึ่งควรถูกเข้ารหัสโดยโปรโตคอลการขนส่ง) หากรหัสผ่านตรงกับค่าที่เก็บไว้ของเซิร์ฟเวอร์จะเป็นที่ยอมรับและการตรวจสอบสิทธิ์จะดำเนินต่อไป.
• GSSAPI – ภายใต้วิธีนี้สามารถใช้ชุดรูปแบบภายนอกเช่น Kerberos สำหรับการลงชื่อเข้าใช้ครั้งเดียว.
• แป้นพิมพ์แบบโต้ตอบ – เทคนิคนี้ให้การรับรองความถูกต้องด้วยรหัสผ่านครั้งเดียวโดยให้เซิร์ฟเวอร์แจ้งให้ลูกค้าทราบข้อมูล.

โปรโตคอลการเชื่อมต่อ

โปรโตคอลการเชื่อมต่อที่กำหนดไว้ วิธีรวมข้อมูลหลายช่องทางในเลเยอร์การส่งข้อมูลที่ปลอดภัย. นอกจากนี้ยังเกี่ยวข้องกับพารามิเตอร์ที่ใช้ในการเข้าถึงระบบย่อยที่ปลอดภัยบนโฮสต์เซิร์ฟเวอร์รวมถึงการส่งต่อพร็อกซีและการเข้าถึงเชลล์.

โปรโตคอลการเชื่อมต่อตั้งอยู่ที่ด้านบนของชั้นการขนส่งและโปรโตคอลการตรวจสอบความถูกต้อง จะช่วยให้การดำเนินการคำสั่งระยะไกลเช่นเดียวกับการเชื่อมต่อ X11 และ TCP / IP ที่ส่งต่อ หากเซิร์ฟเวอร์หรือไคลเอ็นต์ถูกโจมตีโปรโตคอลการเชื่อมต่อจะไม่ปลอดภัย.

ช่อง

แชนเนลเป็นเส้นทางการสื่อสารขั้นพื้นฐานและสามารถเปิดได้โดยฝ่ายใดฝ่ายหนึ่ง แชแนลสามารถรวมเซสชันเทอร์มินัลการเชื่อมต่อที่ส่งต่อและรูปแบบการสื่อสารอื่น ๆ เมื่อมีหลายช่องสัญญาณจะมีการมัลติเพล็กซ์เป็นการเชื่อมต่อเดียว.

เปิดช่อง

แต่ละช่องจะถูกกำหนดหมายเลขที่ปลายทั้งสองของตัวเองแม้ว่าหมายเลขนั้นอาจแตกต่างกันในแต่ละด้าน เมื่อฝ่ายหนึ่งร้องขอให้เปิดช่องสัญญาณจะส่งหมายเลขช่องเป็นส่วนหนึ่งของข้อความรวมถึงข้อมูลเกี่ยวกับ ขนาดหน้าต่างเริ่มต้น และ ขนาดแพ็คเก็ตสูงสุด.

ขนาดหน้าต่างเริ่มต้นระบุจำนวนข้อมูลที่ฝ่ายที่เปิดช่องสามารถรับได้ หากจำเป็นต้องส่งข้อมูลเพิ่มเติมจะต้องปรับหน้าต่างก่อน ขนาดแพ็คเก็ตสูงสุดระบุขนาดของแพ็คเก็ตที่สามารถรับได้เช่นเดียวกัน.

เมื่อด้านใดด้านหนึ่งร้องขอให้เปิดช่องอีกด้านหนึ่งจะเปิดช่องถ้ามันสามารถรองรับได้ หากไม่ส่งจะส่งข้อความแจ้งความล้มเหลว ไม่สามารถเปิดช่องได้ด้วยเหตุผลต่อไปนี้:

• ต้องห้ามโดยผู้บริหาร
• การเชื่อมต่อล้มเหลว
• ประเภทช่องที่ไม่รู้จัก
• การขาดแคลนทรัพยากร

หากทั้งสองด้านของการเชื่อมต่อต้องการส่งข้อมูลมากกว่าที่อนุญาตให้หน้าต่างในขณะนี้พวกเขาสามารถส่งข้อความที่ร้องขอให้เพิ่มจำนวนไบต์ได้.

ปิดช่องทาง

เมื่อการเชื่อมต่อด้านใดด้านหนึ่งเสร็จสิ้นการส่งข้อมูลควรส่งข้อความที่ระบุว่าได้ใช้แชนเนลเสร็จแล้ว อย่างไรก็ตามช่องนี้จะยังคงเปิดอยู่และอีกฝ่ายสามารถส่งข้อมูลได้ หากฝ่ายต้องการยุติช่องทางอย่างสมบูรณ์ฝ่ายนั้นจะทำเช่นนั้นพร้อมกับข้อความบอกเลิกแยกต่างหาก.

ความปลอดภัยของ SSH

SSH เวอร์ชั่นต่าง ๆ มีปัญหาด้านความปลอดภัยของตัวเองแม้ว่าจะมีการกำหนดค่าปัจจุบันของ SSH-2 และ OpenSSH ถือว่าปลอดภัยกว่า SSH-1.

SSH-1

โดยทั่วไปแล้ว SSH-1 ถือว่ามีข้อบกพร่องพร้อมช่องโหว่ที่แตกต่างกันหลายช่วง. สิ่งเหล่านี้รวมถึงบั๊กใน SSH 1.5 ที่อนุญาตให้ผู้ใช้ที่ไม่ได้รับอนุญาตแทรกเนื้อหาลงในสตรีมข้อมูล SSH การโจมตีนี้ใช้ประโยชน์จากการป้องกันความสมบูรณ์ของข้อมูลขั้นต่ำของ CRC-32.

การโจมตีนี้ลดลงด้วยเครื่องตรวจจับการจู่โจมค่าตอบแทน SSH ซึ่งรวมเข้ากับการใช้งานที่ใหม่กว่า การแก้ไขนี้มาพร้อมกับช่องโหว่ใหม่ซึ่งมีอำนาจในการเรียกใช้รหัสโดยอำเภอใจด้วยสิทธิ์ของรูท.

นอกจากนี้ยังมีช่องโหว่ที่ทำให้ฝ่ายตรงข้ามสามารถเปลี่ยนบล็อกสุดท้ายในเซสชันที่ใช้การเข้ารหัส IDEA ได้เช่นเดียวกับช่องโหว่ที่อนุญาตให้เซิร์ฟเวอร์ที่ถูกบุกรุกส่งต่อกระบวนการตรวจสอบสิทธิ์ไคลเอ็นต์ไปยังเซิร์ฟเวอร์อื่น.

เนื่องจากปัญหาด้านความปลอดภัยเหล่านี้จึงควรใช้ SSH-2 แทน เพื่อให้การใช้งานของคุณปลอดภัยคุณควร ปิดใช้งานการเจรจาต่อรองใหม่เป็น SSH-1, เนื่องจากการโจมตีสามารถใช้ประโยชน์จากสิ่งนี้เพื่อเข้าถึงข้อมูลของคุณผ่านการป้องกันที่อ่อนแอกว่าของ SSH-1.

SSH-2

SSH-2 มีความเสี่ยงต่อการโจมตีทางทฤษฎีกับโหมดการเข้ารหัสเริ่มต้นของ CBC. จะช่วยให้ผู้โจมตีสามารถกู้คืน plaintext ได้สูงสุด 32 บิตจากบล็อกที่เข้ารหัส สิ่งนี้สามารถบรรเทาได้โดยใช้โหมดเคาน์เตอร์ (CTR) และเปลี่ยนการเข้ารหัสบล็อกเป็นกระแสการเข้ารหัสแทน.

ในตอนท้ายของปี 2014 Der Spiegel ได้เปิดตัวเอกสาร NSA ซึ่งบ่งบอกว่า NSA บางครั้งอาจทำลาย SSH PowerPoint NSA ที่รั่วไหลออกไปนี้ระบุว่า NSA สามารถ“อาจกู้คืนชื่อผู้ใช้และรหัสผ่าน” แม้ว่าจะไม่ได้รับรายละเอียดเพิ่มเติม ไม่ทราบว่าวิธีการที่หน่วยงานใช้ในการทำเช่นนี้ แต่ดูเหมือนว่าไม่น่าจะเกี่ยวกับขีดความสามารถในเอกสารภายในของตัวเอง.

ในปี [year] การรั่วไหลของ Vault 7 นั้นถูกเปิดเผยว่า CIA มีเครื่องมือสองอย่างที่สามารถใช้ในการสกัดกั้นและขโมยการเข้าสู่ระบบและรหัสผ่าน SSH. BothanSpy กำหนดเป้าหมายให้กับไคลเอนต์ Windows Xshell ในขณะที่ Gyrfalcon ถูกใช้เทียบกับไคลเอนต์ OpenSSH ในการกระจาย Linux ที่แตกต่างกัน.

เครื่องมือเหล่านี้มีความสามารถในการขโมยข้อมูลประจำตัวแล้วส่งกลับไปยังเซิร์ฟเวอร์ CIA การโจมตีเหล่านี้ไม่สามารถทำลายโปรโตคอลได้ พวกเขาใช้การโจมตีช่องทางอื่น ๆ ที่สามารถหลบเลี่ยงได้ในการใช้งานบางอย่าง.

แม้จะมีการโจมตีเหล่านี้ แต่ SSH-2 ถือว่าปลอดภัยในสถานการณ์ส่วนใหญ่ตราบใดที่มีการใช้งานอย่างเหมาะสม เป้าหมายที่มีมูลค่าสูงหรือผู้ที่ใช้งานที่ล้าสมัยหรือไม่ดีควรพิจารณาตัวเลือกอื่น ๆ.

OpenSSH

ใน OpenSSH เวอร์ชั่น 2, ค้นพบการโจมตีที่ใช้ประโยชน์จากจุดอ่อนในแพ็คเก็ตไบนารี SSH. การโจมตีดังกล่าวทำให้นักวิจัยจากมหาวิทยาลัยลอนดอนสามารถกู้คืนข้อความธรรมดาจำนวน 14 บิตจากบล็อกที่เข้ารหัส สิ่งนี้ได้รับการลดลงในรีลีส 5.2 โดยทำให้โปรโตคอลอ่านครบทั้งความยาวของแพ็คเก็ตที่ไม่ถูกต้องหรือรหัสการตรวจสอบข้อความแทนที่จะจบการเชื่อมต่อ.

ในเวอร์ชัน 6.8 และ 6.9, Linux สามารถใช้เพื่อรันคำสั่งโดยพลการบนเทอร์มินัลของผู้ใช้รายอื่น สิ่งนี้สำเร็จได้ผ่านช่องโหว่การเลื่อนระดับสิทธิ์ที่อนุญาตให้ผู้โจมตีสามารถฉีดอักขระด้วยการควบคุมอินพุต / เอาต์พุต TIOCSTI.

SSH ปลอดภัยหรือไม่?

ในขณะที่ดูเหมือนว่า SSH มีปัญหาด้านความปลอดภัยจำนวนมาก, มันเปลี่ยนแปลงได้เป็นเรื่องปกติที่จะพบช่องโหว่จำนวนหนึ่งในการนำไปใช้งานต่าง ๆ ของโปรโตคอล นี่ไม่ได้หมายความว่าโปรโตคอล SSH ไม่ปลอดภัย แต่มันก็หมายความว่า จำเป็นต้องดำเนินการอย่างถูกต้อง.

ตราบใดที่คุณกำลังใช้ SSH-2 หรือ OpenSSH และมีการกำหนดค่าในลักษณะที่เหมาะสมสำหรับการใช้งานของคุณคุณควรรู้สึกมั่นใจในการป้องกันที่ SSH ให้การเชื่อมต่อของคุณ. นั่นเป็นเหตุผลว่าทำไมจึงยังคงเป็นโปรโตคอลที่ใช้บ่อยโดยเฉพาะอย่างยิ่งสำหรับการเข้าถึงระยะไกลและการเจาะอุโมงค์.

ดูเพิ่มเติมที่: อธิบายประเภทการเข้ารหัสทั่วไป

พื้นหลังเทคโนโลยีเครือข่ายไซเบอร์ โดย TheDigitalArtist ได้รับอนุญาตภายใต้ มอนส์ CC0