ทำไมไม่ใช้% h ในตัวเลือก ControlPath ของ OpenSSH


13

ทำไม "ssh_config (5)" manpages แนะนำว่าControlPathตัวเลือกที่ควรมีอย่างน้อย%h, %pและ%rตัวยึดเพื่อระบุตัวตนของแต่ละการเชื่อมต่อที่ใช้ร่วมกัน?

ผมคิดว่าหลายครั้งควรแบ่งปันซ็อกเก็ตเดียวกันกับการเชื่อมต่อไปยังโฮสต์เดียวกัน มันจะไม่สมเหตุสมผลถ้ามีคำจำกัดความง่ายๆเช่น:

ControlPath ~/.cache/ssh/mux/%h

แทนสิ่งที่ชอบ:

ControlPath ~/.cache/ssh/mux/%r@%h:%p

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

ฉันต้องการที่จะมี defintion ssh -o ControlMaster=noแรกในส่วนของค่าเริ่มต้นโฮสต์เพื่อให้พอเพียงที่จะบอกว่า

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


"ฉันต้องการแบ่งปันการเชื่อมต่อกับโฮสต์ระยะไกลเดียวกันระหว่างเซสชันทั้งหมดที่เริ่มต้นโดยผู้ใช้ภายในเครื่องเดียวกันโดยไม่คำนึงถึงผู้ใช้ระยะไกลและพอร์ตระยะไกล" คำตอบสั้น ๆ : คุณไม่สามารถ ฉันได้เพิ่มคำอธิบายลงในคำตอบแล้ว
goldilocks

คำตอบ:


13

"ฉันคิดว่าหลายเซสชันควรแชร์ซ็อกเก็ตเดียวกันกับการเชื่อมต่อกับโฮสต์เดียวกัน"

พวกเขาสามารถ. อย่างไรก็ตามโปรดทราบว่าหากคุณเชื่อมต่อกับโฮสต์โดยใช้การเชื่อมต่อที่มีอยู่ผ่านControlPathไม่ว่าผู้ใช้รายใดที่คุณต้องการเข้าสู่ระบบในฐานะคุณจะเข้าสู่ระบบในฐานะผู้ใช้เดิมของการเชื่อมต่อ เช่นไม่มีการเชื่อมต่อกับ "ที่ไหน":

ssh -o ControlPath=~/.ssh/%h -o ControlMaster=yes bob@somewhere

เซสชั่นนี้คือ bob @ ที่ไหนสักแห่ง

ssh -o ControlPath=~/.ssh/%h -o ControlMaster=no sue@somewhere

เซสชั่นนี้จะยังเป็นบ๊อบ @ บางเพราะคุณใช้ ControlPath เดียวกันและชุดControlMaster=no; หากControlMaster=yesคุณลงชื่อเข้าใช้ด้วยชื่อฟ้อง แต่ ssh จะเพิกเฉยต่ออาร์กิวเมนต์ ControlPath ของคุณดังที่แสดงไว้ในman ssh_config:

การประชุมเพิ่มเติมสามารถเชื่อมต่อกับซ็อกเก็ตนี้ใช้ ControlPath เดียวกันกับ ControlMaster ตั้ง 'ไม่'

จากหลักฐานนี้ถ้าControlMaster=yesในทั้งสองกรณีเมื่อ Bob ออกจากซ็อกเก็ต ControlPath ~/.ssh/somewhereจะหายไปแม้ว่าเซสชัน "sue" ยังคงทำงานอยู่หมายความว่าเซสชัน sue ไม่เคยใช้ซ็อกเก็ตนั้น

ดังนั้นหากคุณต้องการใช้การเชื่อมต่อแบบเดียวกันก็%hโอเค แต่ระวังว่าคุณไม่สามารถแบ่งปันการเชื่อมต่อได้เนื่องจากผู้ใช้ระยะไกลที่แตกต่างกันหลายคน - ssh จะไม่ยอมให้คุณ


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

5

คุณสามารถมีผู้ใช้หลายคนและหลายพอร์ตที่ใช้งานได้แม้แต่เซิร์ฟเวอร์เดียวกัน ตัวฉันเองฉันเชื่อมต่อกับระบบหลายร้อยระบบบนอินทราเน็ตของ บริษัท ส่วนใหญ่มีผู้ใช้หลายคนที่มีฟังก์ชั่นหรือแอพเซิร์ฟเวอร์ต่างกัน การเข้าถึง userA นั้นแตกต่างกันมากในการเข้าถึง userB และการเชื่อมต่อหลักจะต้องแตกต่างกัน หากคุณต้องวิ่ง:

$ ssh -n -o ControlMaster=auto -o ControlPath=~/.cache/ssh/mux/%h -l userA localhost sleep 10 & # create the master connection and background it
$ ssh -o ControlMaster=auto -o ControlPath=~/.cache/ssh/mux/%h -l userB localhost whoami
userA

อย่างที่คุณเห็นเราไม่ได้รับเซสชัน OpenSSH กับ userB แต่เป็นของดั้งเดิมที่มี userA นั่นหมายความว่าโฮมไดเร็กตอรี่การอนุญาตและแม้แต่การพิสูจน์ตัวตนไม่ใช่สิ่งที่คาดหวัง ใช้สิ่งนี้หากคุณพยายามลบไฟล์ในไดเรกทอรีของ userB ดังนั้น a) อาจเป็นไฟล์ที่ไม่ถูกต้องและ b) อาจเป็นสิทธิ์ที่ไม่ถูกต้อง

หากคุณจะไม่เชื่อมต่อกับผู้ใช้มากกว่าหนึ่งรายบนเซิร์ฟเวอร์ใดเครื่องหนึ่งโดยใช้พอร์ตเดียวใช่แล้วการใช้%hอาจเพียงพอ ใน~/.ssh/configไฟล์ของคุณคุณต้องการใช้:

ControlMaster=auto  # use existing or create a master connection
ControlPath=~/.cache/ssh/mux/%h
ControlPersist=yes

ด้วยตัวเลือกการเชื่อมต่อหลักยังคงเปิดอยู่ด้านหลังจนเสียชีวิตหรือได้สิ้นสุดลงด้วยControlPersist ssh -O exitนี่เป็นฟีเจอร์ set-it-and-forget-it ที่ดี

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

ControlMaster=auto
ControlPath=~/.cache/ssh/mux/%r@%h:%p
ControlPersist=yes

ฉันยังสับสนอยู่ ฉันพยายามอธิบายสถานการณ์การกำหนดค่าและความตั้งใจของฉันในย่อหน้า "ฉันต้องการ" ทุกคนในคุณสามารถตอบคำถามของฉันได้อย่างแม่นยำมากขึ้นด้วยข้อมูลเพิ่มเติมนี้หรือไม่?
Tim Friske
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.