การส่งต่อ ssh-agent และ sudo ไปยังผู้ใช้รายอื่น

หากฉันมีเซิร์ฟเวอร์ A ซึ่งฉันสามารถเข้าสู่ระบบด้วยคีย์ ssh ของฉันและฉันมีความสามารถในการ "sudo su - otheruser" ฉันจะสูญเสียการส่งต่อคีย์เนื่องจากตัวแปร env ถูกลบและซ็อกเก็ตสามารถอ่านได้โดยผู้ใช้ดั้งเดิมของฉันเท่านั้น มีวิธีที่ฉันสามารถเชื่อมโยงคีย์การส่งต่อผ่าน "sudo su - otheruser" ดังนั้นฉันสามารถทำสิ่งต่าง ๆ บนเซิร์ฟเวอร์ B ด้วยคีย์การส่งต่อของฉัน (git clone และ rsync ในกรณีของฉัน)?

วิธีเดียวที่ฉันคิดได้ก็คือการเพิ่มกุญแจของฉันไปที่ authorized_keys ของ otheruser และ "ssh otheruser @ localhost" แต่นั่นเป็นเรื่องยุ่งยากที่จะทำสำหรับผู้ใช้และชุดเซิร์ฟเวอร์ที่ฉันมี

ในระยะสั้น:

$ sudo -HE ssh user@host
(success)
$ sudo -HE -u otheruser ssh user@host
Permission denied (publickey). 

ดังที่คุณกล่าวถึงตัวแปรสภาพแวดล้อมจะถูกลบออกsudoเพื่อความปลอดภัย

แต่โชคดีที่sudoสามารถกำหนดค่าได้มาก: คุณสามารถบอกได้ว่ามันแม่นยำซึ่งเป็นตัวแปรสภาพแวดล้อมที่คุณต้องการให้ขอบคุณการกำหนดค่าตัวเลือกในenv_keep/etc/sudoers

สำหรับการส่งต่อเอเจนต์คุณต้องเก็บSSH_AUTH_SOCKตัวแปรสภาพแวดล้อม โดยแก้ไข/etc/sudoersไฟล์กำหนดค่าของคุณ(ใช้งานอยู่เสมอvisudo) และตั้งค่าenv_keepตัวเลือกให้กับผู้ใช้ที่เหมาะสม หากคุณต้องการให้ตัวเลือกนี้ถูกตั้งค่าสำหรับผู้ใช้ทุกคนให้ใช้Defaultsบรรทัดดังนี้:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers สำหรับรายละเอียดเพิ่มเติม

ตอนนี้คุณควรจะสามารถทำอะไรเช่นนี้ (ให้user1's คีย์สาธารณะในปัจจุบันคือ~/.ssh/authorized_keysในuser1@serverAและuser2@serverBและserverAของ/etc/sudoersไฟล์มีการติดตั้งตามที่ระบุไว้ข้างต้น):

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

sudo -E -s

• - E จะรักษาสิ่งแวดล้อม
• -s รันคำสั่งเริ่มต้นที่เชลล์

สิ่งนี้จะทำให้คุณรูทเชลล์พร้อมคีย์ต้นฉบับที่โหลดอยู่

อนุญาตให้otheruserในการเข้าถึง$SSH_AUTH_SOCKไฟล์และไดเรกทอรีเช่นโดย ACL ที่ถูกต้องก่อนที่จะเปลี่ยนให้กับพวกเขา ตัวอย่างสมมติDefaults:user env_keep += SSH_AUTH_SOCKใน/etc/sudoersเครื่องโฮสต์:

$ ssh -A user@host
user@host$ setfacl -m otheruser:x   $(dirname "$SSH_AUTH_SOCK")
user@host$ setfacl -m otheruser:rwx "$SSH_AUTH_SOCK"
user@host$ sudo su - otheruser
otheruser@host$ ssh server
otheruser@server$

ปลอดภัยยิ่งขึ้นและใช้ได้กับผู้ใช้ที่ไม่ใช่รูทด้วย ;-)

ฉันได้พบว่าสิ่งนี้ยังใช้งานได้

sudo su -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

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

chmod 777 -R `dirname $SSH_AUTH_SOCK`
sudo su otheruser -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

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

หากคุณได้รับอนุญาตsudo su - $USERคุณอาจจะมีข้อโต้แย้งที่ดีสำหรับการได้รับอนุญาตให้ทำssh -AY $USER@localhostแทนโดยใช้รหัสสาธารณะที่ถูกต้องในโฮมไดเร็กตอรี่ของ US $ จากนั้นการตรวจสอบความถูกต้องของคุณจะถูกส่งต่อไปกับคุณ

คุณสามารถ ssh ไปยัง localhost ได้ตลอดเวลาพร้อมตัวแทนส่งต่อแทนที่จะใช้ sudo:

ssh -A otheruser@localhost

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

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

อย่าใช้sudo su - USERแต่จะดีsudo -i -u USERกว่า ใช้งานได้สำหรับฉัน!

การรวมข้อมูลจากคำตอบอื่น ๆ ที่ฉันพบกับสิ่งนี้:

user=app
setfacl -m $user:x $(dirname "$SSH_AUTH_SOCK")
setfacl -m $user:rwx "$SSH_AUTH_SOCK"
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" -u $user -i

ฉันชอบสิ่งนี้เพราะฉันไม่จำเป็นต้องแก้ไขsudoersไฟล์

ทดสอบบน Ubuntu 14.04 (ต้องติดตั้งaclแพ็คเกจ)

ฉันคิดว่ามีปัญหากับ-ตัวเลือก (เส้นประ) หลังจากsuอยู่ในคำสั่งของคุณ:

sudo su - otheruser

หากคุณอ่าน man page ของsuคุณอาจพบว่าตัวเลือก-, -l, --loginเริ่มต้นสภาพแวดล้อมเชลล์เป็นเชลล์ล็อกอิน นี้จะเป็นสภาพแวดล้อมสำหรับการotheruserไม่คำนึงถึงตัวแปร env suที่คุณเรียก

sudoใส่เพียงแค่เส้นประจะทำลายสิ่งที่คุณส่งผ่านจาก

คุณควรลองคำสั่งนี้แทน:

sudo -E su otheruser

ในฐานะที่เป็น Joao-Costa @ ชี้จะเก็บตัวแปรทั้งหมดในสภาพแวดล้อมที่คุณวิ่ง-E sudoจากนั้นไม่มีเส้นประsuจะใช้สภาพแวดล้อมนั้นโดยตรง

น่าเสียดายที่เมื่อคุณใช้กับผู้ใช้รายอื่น (หรือแม้แต่ใช้ sudo) คุณจะสูญเสียความสามารถในการใช้คีย์ที่ส่งต่อของคุณ นี่คือคุณลักษณะด้านความปลอดภัย: คุณไม่ต้องการให้ผู้ใช้แบบสุ่มที่เชื่อมต่อกับ ssh-agent ของคุณและใช้กุญแจของคุณ :)

วิธี "ssh -Ay $ {USER} @localhost" นั้นค่อนข้างยุ่งยาก (และตามที่ระบุไว้ในความคิดเห็นของฉันเกี่ยวกับคำตอบของเดวิดที่มีแนวโน้มที่จะแตกหัก) แต่อาจเป็นวิธีที่ดีที่สุดที่คุณจะทำได้