سؤال ssh-agent forwarding و sudo إلى مستخدم آخر


إذا كان لدي خادم A يمكنني تسجيل الدخول إليه باستخدام مفتاح ssh الخاص بي ولدي القدرة على "sudo su - otheruser" ، أفقد إعادة توجيه المفاتيح ، لأنه تتم إزالة متغيرات env و المقبس قابل للقراءة فقط من قبل المستخدم الأصلي. هل هناك طريقة يمكنني من خلالها توصيل مفتاح إعادة التوجيه من خلال "sudo su - otheruser" ، حتى أتمكن من القيام بالأشياء على الخادم B مع مفتاح إعادة التوجيه (git clone و rsync في حالتي)؟

الطريقة الوحيدة التي يمكنني التفكير فيها هي إضافة مفتاحي إلى keys_keys of otheruser و "ssh otheruser @ localhost" ، ولكن هذا أمر مرهق للقيام به لكل تركيبة مستخدم وخادم قد أكون.

بالمختصر:

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

144
2018-01-28 13:52


الأصل




الأجوبة:


كما ذكرتم ، يتم إزالة متغيرات البيئة من قبل sudo، لأسباب أمنية.

لكن لحسن الحظ sudo هو شكلي تماما: يمكنك معرفة ذلك بدقة متغيرات البيئة التي تريد الاحتفاظ بها بفضل env_keep خيار التكوين في /etc/sudoers.

لإعادة توجيه الوكيل ، يلزمك الاحتفاظ بـ SSH_AUTH_SOCK متغيرات البيئة. للقيام بذلك ، ببساطة تحرير الخاص بك /etc/sudoers ملف التكوين (دائما باستخدام visudo) وضبط env_keep الخيار للمستخدمين المناسبين. إذا كنت تريد تعيين هذا الخيار لجميع المستخدمين ، فاستخدم Defaults خط مثل هذا:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers لمزيد من التفاصيل.

يجب أن تكون الآن قادرًا على القيام بشيء كهذا (بشرط user1المفتاح العام موجود في ~/.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

168
2018-03-03 21:24



هذه هي الإجابة الصحيحة ، يجب أن تكون مميزة. - Xealot
هذه فقط يعمل ، إذا user2 أعلاه هو root! غير ذلك، user2 سوف يتم إعداد SSH_AUTH_SOCK بشكل صحيح ، لكن user2 لن يتمكن من الوصول على سبيل المثال. / تمة / سه-GjglIJ9337 /. root لديه هذا الوصول. لذلك قد يحل هذا جزءًا من المشكلة ، لكن لا يمكن حلها: "و المقابس قابلة للقراءة فقط بواسطة المستخدم الأصلي الخاص بي " - Peter V. Mørch
Defaults>root env_keep+=SSH_AUTH_SOCK يجب التأكد من أنها فقط إلى الأمام عند sudoing إلى جذر. لا تريد القيام بذلك على أي حال للمستخدمين الآخرين لأسباب أمنية. أفضل تشغيل وكيل ssh منفصل عن otherother ، وإضافة المفاتيح المناسبة. - Paul Schyska
sudo su - لا يعمل بالنسبة لي ، ويفترض أنه لا يمكن الحفاظ على البيئة لأنها ليست كذلك sudo في وقت بدء قذيفة. sudo su يبدو أنه يعمل. - Alex Fortuna
لم أفهم أبدًا لماذا يستخدم الناس sudo su على أي حال. إذا كنت بحاجة إلى جذر قذيفة ، هذا ما sudo -s أو sudo -i هو ل. - eaj


sudo -E -s
  • -E سوف الحفاظ على البيئة
  • -s يدير أمرًا افتراضيًا إلى shell

سيعطيك هذا shell الجذر مع استمرار تحميل المفاتيح الأصلية.


55
2018-01-01 15:31



كما هو الحال مع التعليق أعلاه ، يعالج هذا السؤال فقط إذا أصبحت جذرًا ، لأنه في هذه الحالة يكون الجذر قادرًا على الالتفاف حول أذونات الوصول المعتادة على SSH_AUTH_SOCK $. - doshea


السماح 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$

أكثر أمنا ويعمل للمستخدمين غير الجذر كذلك ؛-)


33
2017-11-15 10:58



تذكر عند استخدام هذه الطريقة ، قام أشخاص آخرون بتسجيل الدخول باسم otheruser يمكن أيضًا استخدام مصادقة ssh الخاصة بك. - gitaarik
هذا يعمل بالنسبة لي إلا أنني اضطررت إلى تغيير "sudo su - otheruser" إلى "sudo su otheruser" (إزالة -). - Charles Finkel
لماذا ا rwx و لا rw (أو r على الاطلاق)؟ - anatoly techtonik
anatolytechtonik من man 7 unix - يتطلب اتصال Linux إلى مأخذ توصيل أذونات القراءة والكتابة على هذا المقبس. كما أنك تحتاج إلى البحث (تنفيذ) وكتابة إذن على الدليل الذي تقوم بإنشاء مأخذ أو فقط البحث (تنفيذ) إذن عند الاتصال إلى هذا مأخذ التوصيل. حتى في الإجابة المذكورة أعلاه تنفيذ إذن على مأخذ التوصيل هو زائدة عن الحاجة. - mixel


لقد وجدت أن هذا يعمل أيضا.

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 الخاص بك (حتى تقوم بتسجيل الخروج). قد تتمكن أيضًا من تعيين المجموعة وتغيير الأذونات إلى 770 ، والتي قد تكون أكثر أمانًا. ومع ذلك ، عندما حاولت تغيير المجموعة ، حصلت على "عملية غير مسموح بها".


16
2018-03-21 00:01



هذا أمر محفوف بالمخاطر للغاية. إن منح كل إذن مستخدم آخر لاستخدام وكيل SSH يكافئ منحهم جميع وثائق الإعتماد الخاصة بك (وإذا كنت تستخدم sudo أو su في أي وقت ، مما يمنحهم السلطة الجذرية على جميع المستخدمين الآخرين على النظام ، بالإضافة إلى جميع الأنظمة الأخرى التي تستخدمها!) . هذا يجب أبدا أن يتم ذلك! - Matija Nalis
أنا لا أتفق مع العبارة التي تقول "يجب ألا يتم ذلك أبداً!" هناك العديد من الحالات التي تكون فيها هذه المخاطر مقبولة. على سبيل المثال ، فريق صغير حيث يملك كل شخص نفس الأذونات وتثق في جميع المستخدمين الآخرين. لا ينبغي أبدا أن يتم ذلك دون فهم المخاطر التي تنطوي عليها. ولكن بمجرد فهم هذه المخاطر ، هناك أوقات تكون فيها المخاطر مقبولة. - phylae


إذا كنت مخولًا بذلك sudo su - $USER، من المحتمل أن يكون لديك حجة جيدة لأنه مسموح لك بالقيام ssh -AY $USER@localhost بدلاً من ذلك ، مع المفتاح العمومي الخاص بك في الدليل الرئيسي USER USER. ثم سيتم تنفيذ إعادة توجيه المصادقة الخاصة بك معك.


6
2018-01-28 14:08



وذكر أنه في الجزء السفلي من سؤاله ، وقال أنه سيكون من الصعب القيام به. - Fahad Sadah
من المحتمل أن يكون هذا هو الحل الأفضل ، ولكنه يصبح مشعرًا إذا كان USER هو شخص حقيقي (tm) - قد يحذف مفتاح SA من المفتاح author_keys أو يغير كلمة المرور الخاصة به ... - voretaq7
يمكنك إزالة حق الوصول للكتابة إلى authorized_keys (على الرغم من أنه إذا تم تعيينهم حقًا على رفض وصول Florian ، فيمكنهم حذفها وإعادة إنشائها ، وذلك في دليل يمتلكونه) - Fahad Sadah


يمكنك دائمًا فقط ssh إلى localhost من خلال إعادة توجيه الوكيل بدلاً من استخدام sudo:

ssh -A otheruser@localhost

العيب هو أنك تحتاج إلى تسجيل الدخول مرة أخرى ، ولكن إذا كنت تستخدمه في علامة تبويب الشاشة / tmux ، فهذا مجرد جهد لمرة واحدة ، ومع ذلك ، إذا قمت بالاتصال من الخادم ، فسيتم فصل المقبس (مرة أخرى) . لذا فهي ليست مثالية إذا كنت لا تستطيع إبقاء جلسة الشاشة / tmux مفتوحة في جميع الأوقات (ومع ذلك ، يمكنك تحديث هاتفك يدويًا SSH_AUTH_SOCKenv var إذا كنت باردا).

لاحظ أيضًا أنه عند استخدام إعادة توجيه ssh ، يمكن للجذر الوصول دائمًا إلى المقبس الخاص بك واستخدام مصادقة ssh الخاصة بك (طالما أنك قمت بتسجيل الدخول باستخدام إعادة توجيه ssh). لذا تأكد من أنك تثق في الجذر.


4
2017-11-27 14:56





لا تستخدم sudo su - USER، لكن بالأحرى sudo -i -u USER. يعمل لدي!


3
2018-01-28 16:51



ما هو إصدار sudo لديك؟ لا يوجد لدى منجم (1.6.7p5، CentOS 4.8) - i في صفحة man. - David Mackintosh
Sudo version 1.6.9p17 يعمل على ديبيان ليني. محاولة sudo -s؟ - Fahad Sadah
لا يعمل بالنسبة لي.
على أوبونتو ، باستخدام سودو 1.8.9p5 ، لا sudo -s ولا sudo -i يعمل لدي... - Jon L.


الجمع بين المعلومات من الإجابات الأخرى توصلت إلى هذا:

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 ملف.

اختبارها على أوبونتو 14.04 (اضطرت إلى تثبيت acl صفقة).


2
2018-06-10 17:39





للأسف عندما ترضيك مستخدمًا آخر (أو حتى تستخدم sudo) ، ستفقد القدرة على استخدام المفاتيح المعاد توجيهها. هذه ميزة أمان: أنت لا تريد مستخدمين عشوائيين يتصلون بك إلى ssh-agent ويستخدمون المفاتيح الخاصة بك :)

إن طريقة "ssh -Ay $ USER}localhost" مرهقة بعض الشيء (وكما هو مذكور في تعليقي على إجابة ديفيد عرضة للكسر) ، لكنه على الأرجح أفضل ما يمكنك القيام به.


1
2018-01-28 16:52



عفوًا ، ولكن إذا قمت بذلك باستخدام ssh ، فهل يمكن الوصول إلى الوكيل الخاص بي بواسطة هذا المستخدم على أي حال ، أم هل أنا مخطئ؟
إذا كنت SSH في المستخدم المستهدف مع وكيل إعادة توجيه طلبات وكيل الخاص بك سوف ترتد السلسلة إلى أي مكان الوكيل "الحقيقي". عندما ترضع أو تبتعد عن المستخدم الأصلي ، لن يكون مقبس الوكيل الخاص بشركة SSH متاحًا (أو لا يجب أن يكون متاحًا) - فالدليل الذي يعيش فيه هو وضع 700 وامتلاكه من قبل المستخدم الأصلي. (تحذير واضح: إذا كنت تقوم بالتبديل إلى الجذر وإعادة ضبط بيئة SSH_AUTH_SOCK فقد تعمل ، لكنني لن أعتمد عليها) - voretaq7
على الخادم الخاص بي (Ubuntu 12.04 ، إصدار ssh OpenSSH_5.9p1 Debian-5ubuntu1.1، OpenSSL 1.0.1 14 Mar 2012)، ssh has -a و -A الحجج. -a يفعل عكس بالضبط ما هو المقصود ، فإنه يعطل إعادة توجيه وكيل! لذلك ، في إطار الإصدار الأخير (وربما جميع) من أوبونتو ، استخدم -A لتمكين إعادة توجيه الوكيل. - knite
knite أنت على حق - وهذا هو مطبعي (3 سنوات من العمر)! في إجابتي. ثابت الآن :-) - voretaq7