ปลอดภัยไหมที่จะเชื่อมต่อเซิร์ฟเวอร์โดย SSH จากโรงแรมในระหว่างการเดินทาง?

ปลอดภัยไหมที่จะเชื่อมต่อเซิร์ฟเวอร์โดยใช้ SSH จากโรงแรมระหว่างการเดินทาง?

เซิร์ฟเวอร์ :
- CentOS 7
- การอนุญาตโดยคีย์ RSA เท่านั้น - การรับรองความถูกต้องรหัสผ่านถูกปฏิเสธ
- พอร์ตที่ไม่ได้มาตรฐาน

เวิร์กสเตชัน :
- Ubuntu 14
- รหัสผ่านผู้ใช้
- รหัสผ่านเพื่อใช้คีย์ RSA (วิธีมาตรฐาน)

อาจเป็นความคิดที่ดีที่จะเก็บคีย์ส่วนตัวครึ่งหนึ่งไว้ใน USB Stick และโดยอัตโนมัติ (โดยสคริปต์) จะเพิ่มครึ่งนี้เป็น ~ / .ssh / private_key ก่อนทำการเชื่อมต่อ?

อินเทอร์เน็ตจะมีทั้ง WiFi ในโรงแรมหรือเคเบิลในอพาร์ตเมนต์ที่เช่า

UPD
ขออภัยที่ไม่ชัดเจนในตอนแรก ฉันหมายถึงความปลอดภัยในสองด้านที่นี่:

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

security physical-security

— Sergey Serov
แหล่งที่มา

คีย์ RSA ครึ่งใด ส่วนสาธารณะของคีย์โฮสต์ ssh? ครึ่งหนึ่งของส่วนส่วนตัวของคีย์ผู้ใช้ ssh ของคุณ?

— andol

ครึ่งหนึ่งของคีย์ RSA ส่วนตัวของฉันแน่นอน :) และโดยอัตโนมัติโดยสคริปต์เพื่อเพิ่มครึ่งนี้เป็น ~ / .ssh / private_key ก่อนเชื่อมต่อกับเซิร์ฟเวอร์

— Sergey Serov

คุณมีความปลอดภัยมากกว่าผู้ใช้ส่วนใหญ่อยู่แล้วเพราะคุณใช้งาน Linux เนื่องจากคุณใช้งานเวอร์ชันล่าสุดคุณควรมี OpenSSH เวอร์ชันใหม่ซึ่งรองรับ crypto ที่แรงกว่า หลังจากติดตามtecmint.com/5-best-practices-to-secure-and-protect-ssh-serverคุณสามารถเล่นกับการ จำกัด ตัวเองให้แข็งแกร่ง crypto เช่นstribika.github.io/2015/01/04/secure-secure- shell.html

— chicks

@ ลูกไก่ "ปลอดภัยกว่าคนส่วนใหญ่เพราะคุณใช้ Linux" เป็นสิ่งที่โง่ที่จะพูด SSH คือ SSH โดยไม่คำนึงถึงว่ามันทำงานบน Linux, Unix (Mac) หรือ Windows และเราสามารถชี้ไปที่ข้อบกพร่องด้านความปลอดภัยที่ร้ายแรงอย่างมากใน Linux ในประวัติศาสตร์เมื่อไม่นานมานี้ (Heartbleed, any?) เพียงแค่บอกว่าเราปล่อยให้เปลวไฟสงครามระบบปฏิบัติการโง่ ๆ บนสนามที่พวกเขาอยู่เพราะมันเบี่ยงเบนความสนใจจากคำถามและปัญหาที่เกิดขึ้นจริง ขอบคุณ! ;-)

— Craig

@ ลูกไก่ฉันคิดว่านั่นคือสิ่งที่ฉันพยายามสื่อ ปัญหาด้านความปลอดภัยจำนวนมากในทุกระบบปฏิบัติการและ Microsoft ได้ก้าวย่างอย่างใหญ่หลวงตั้งแต่เริ่มต้น "การคำนวณที่เชื่อถือได้ * เมื่อหลายปีก่อนฉันคิดว่า" คุณปลอดภัยมากขึ้นเพราะ Linux "เปลี่ยนการสนทนาจากปัญหาจริงในมือ ด้วยความเคารพ). ;-)

— Craig

คำตอบ:

ดังนั้นเกี่ยวกับการเชื่อมต่อ ssh ผ่านการเชื่อมต่อที่ไม่น่าเชื่อถืออย่างชัดเจน

สมมติว่าคุณมีรายการ ~ / .ssh / known_hosts จากการเชื่อมต่อก่อนหน้านี้แล้วคุณควรจะสามารถเชื่อมต่อได้โดยไม่ต้องกังวลว่าเครือข่ายจะปลอดภัยหรือไม่ เช่นเดียวกันถ้าคุณมีวิธีอื่นในการตรวจสอบ ssh host key

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

— Andol
แหล่งที่มา

ขอขอบคุณ!! ดังนั้นจึงปลอดภัยที่จะเชื่อมต่อกับเซิร์ฟเวอร์โดย SSH แม้ผ่าน Wi-Fi สาธารณะใด ๆ

— Sergey Serov

ที่จริงแล้วคำตอบนี้ใช้กับสถานการณ์ใด ๆที่คุณต้องการ ssh ไปยังเซิร์ฟเวอร์ระยะไกลและส่วนใดส่วนหนึ่งของเส้นทางไม่ได้อยู่ภายใต้การควบคุมของคุณ (ดังนั้นในทางปฏิบัติอะไรนอกเหนือจาก ssh-ing ไปยัง localhost ที่ติดตั้งใหม่หรือผ่านสายเคเบิล )

— Hagen von Eitzen

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

— kasperd

@kasperd: ถ้าลูกค้าเชื่อมต่อมีการเปิดใช้ตัวแทนการส่งต่อแม้การรับรองความถูกต้องของรหัสสาธารณะสามารถให้ประสบการณ์ MITM ที่สมบูรณ์ได้ แต่ใช่การรับรองความถูกต้องของรหัสสาธารณะนั้นดีกว่ารหัสผ่านปกติทุกวัน

— andol

@kasperd: เอาละฉันสามารถนึกภาพใครบางคนที่เพิ่งค้นพบการส่งต่อเอเจนต์ แต่ไม่เข้าใจอย่างเต็มที่โดยวางบางอย่างเช่น "Host * \ n \ tForwardAgent ใช่" ไว้ใน ~ / .ssh / config ผู้คนทำสิ่งต่าง ๆ ที่บ้าคลั่งทุกอย่าง :-)

— andol

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

โปรดทราบว่าสิ่งนี้สามารถแก้ไขได้อย่างง่ายดาย (ปัญหาคีย์ส่วนตัว) โดยการจัดเก็บคีย์ส่วนตัว "เข้ารหัส" ด้วย "ข้อความรหัสผ่าน": พวกเขาสามารถเข้ารหัสในขั้นต้นในขณะที่สร้างด้วยยูทิลิตี้ssh-keygenโดยระบุข้อความรหัสผ่านที่ กระบวนการสร้างหรือหากคุณไม่ได้เข้ารหัสไว้ให้ใช้ยูทิลิตีssh-keygenพร้อม-pตัวเลือก เมื่อรหัสถูกเข้ารหัสทุกครั้งที่เข้าสู่ระบบคุณจะถูกขอให้ป้อนข้อความรหัสผ่านที่เกี่ยวข้องและ .... หากถูกต้องทุกอย่างจะดำเนินการตามปกติ

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

โปรดทราบว่า ssh-agent สามารถจัดการกุญแจได้มากมายและเห็นได้ชัดว่าคุณสามารถ "ปรับ" โน๊ตบุ๊ค / เดสก์ท็อปของคุณเพื่อเรียกใช้งานssh-addยูทิลิตีนี้

นอกจากนี้หากใครบางคนขโมยแล็ปท็อปของคุณคีย์ส่วนตัวของคุณอาจไม่ใช่เนื้อหา "ละเอียดอ่อน" เพียงอย่างเดียวที่คุณจะให้: โปรดทราบว่าด้วยการแจกแจงเดสก์ท็อปบน Linux ในปัจจุบันมันง่ายมากในการตั้งค่า "ระบบไฟล์ (ใน/homeฐานะผู้เริ่มระบบ แต่เป็นทั้งระบบ/หากจำเป็น) ดังนั้นโปรดพิจารณาด้วย

ทั้งหมดที่กล่าวมาเห็นได้ชัดว่าไม่ไม่ใช้ถ้าคุณไม่พึ่งพาของคุณเองโน๊ตบุ๊ค

PS: สำหรับความเป็นไปได้ของการจัดเก็บทั้งสองส่วนของคีย์ส่วนตัวที่ไม่ได้เข้ารหัสบนสื่อที่แตกต่างกัน: ผมขอแนะนำให้คุณไม่ได้ที่จะทำเช่นนี้การรักษาทั้งสองชิ้นส่วนของเนื้อหาที่สำคัญในรูปแบบที่ไม่ได้เข้ารหัสเป็นมากเลวร้ายมากไปกว่าการรักษาสอง สำเนาทั้งหมดของเนื้อหาทั้งหมดเข้ารหัส!

— Damiano Verzulli
แหล่งที่มา

ส่วนแรกของคำถามของคุณได้รับคำตอบแล้วจากคำตอบก่อนหน้า ตามส่วนที่สองของคุณฉันขอแนะนำให้เพิ่มปัจจัยที่สองในการเข้าสู่ระบบ ssh ของคุณโดยใช้ pam_google_authenticator มันค่อนข้างง่ายตั้งค่าและกำหนดค่าใน distro ใด ๆ ในกรณีที่รหัสส่วนตัวที่คุณถือกุญแจถูกขโมยพวกเขาไม่สามารถลงชื่อเข้าใช้เซิร์ฟเวอร์ของคุณด้วยรหัสผ่านครั้งเดียว TOTP จาก google-authenticator

https://www.howtoforge.com/tutorial/secure-ssh-with-google-authenticator-on-centos-7

— Arul Selvan
แหล่งที่มา