सवाल एसएसएच एजेंट अग्रेषण और सुडो किसी अन्य उपयोगकर्ता को


अगर मेरे पास एक सर्वर ए है जिसमें मैं अपनी एसएस कुंजी के साथ लॉगिन कर सकता हूं और मेरे पास "सुडो सु-ऑउसर" की क्षमता है, तो मैं कुंजी अग्रेषण खो देता हूं, क्योंकि एनवी चर हटा दिए जाते हैं तथा सॉकेट केवल मेरे मूल उपयोगकर्ता द्वारा पठनीय है। क्या कोई तरीका है कि मैं "सुडो सु-ऑउसर" के माध्यम से कुंजी अग्रेषण को पुल कर सकता हूं, इसलिए मैं सर्वर बी पर अपनी अग्रेषित कुंजी (गिट क्लोन और मेरे मामले में rsync) के साथ सामान कर सकता हूं?

एकमात्र तरीका जिसे मैं सोच सकता हूं, मेरी कुंजी को अन्य उपयोगकर्ता के अधिकृत_की और "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 एसएसएच_एयूथ_SOCK सही ढंग से स्थापित होगा, लेकिन user2 उदाहरण तक पहुंचने में सक्षम नहीं होंगे / Tmp / ssh-GjglIJ9337 /। root उस पहुंच है। तो यह समस्या का हिस्सा हल कर सकता है, लेकिन ओपी नहीं: "तथा सॉकेट केवल मेरे मूल उपयोगकर्ता द्वारा पठनीय है " - Peter V. Mørch
Defaults>root env_keep+=SSH_AUTH_SOCK यह सुनिश्चित करना चाहिए कि जब यह सूडिंग हो तो केवल आगे बढ़ें सेवा मेरे जड़। आप सुरक्षा कारणों से अन्य उपयोगकर्ताओं को वैसे भी ऐसा नहीं करना चाहते हैं। दूसरे के लिए एक अलग एसएसएच एजेंट बेहतर बेहतर करें, और उचित कुंजी जोड़ें। - Paul Schyska
sudo su - मेरे लिए काम नहीं करता है, संभवतः यह पर्यावरण को संरक्षित नहीं कर सकता क्योंकि यह नहीं है sudo खोल स्टार्टअप समय पर। sudo su काम करने लगता है। - Alex Fortuna
मैंने कभी नहीं समझा है कि लोग क्यों उपयोग करते हैं sudo su वैसे भी। यदि आपको रूट खोल की आवश्यकता है, तो यही है sudo -s या sudo -i के लिए है। - eaj


sudo -E -s
  • -ई पर्यावरण को संरक्षित रखेगा
  • -s एक कमांड चलाता है, एक खोल के लिए डिफ़ॉल्ट

यह आपको मूल कुंजी अभी भी लोड होने के साथ एक रूट खोल देगा।


54
2018-01-01 15:31



उपर्युक्त टिप्पणी के साथ, यदि आप रूट बन रहे हैं, तो यह केवल प्रश्न को संबोधित करता है, क्योंकि उस स्थिति में रूट $ SSH_AUTH_SOCK पर सामान्य एक्सेस अनुमतियों के आसपास पहुंचने में सक्षम है। - doshea


अनुमति दें otheruser उपयोग करने के लिए $SSH_AUTH_SOCK फ़ाइल और इसकी निर्देशिका, उदाहरण के लिए सही एसीएल द्वारा, उन्हें स्विच करने से पहले। उदाहरण मानता है 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 अपने एसएसएच प्रमाणीकरण का भी उपयोग कर सकते हैं। - gitaarik
यह मेरे लिए काम करता है सिवाय इसके कि मुझे "सुडो सु-ऑउसर" को "सुडो सु ऑउसर" ("को हटाने) को बदलना पड़ा। - Charles Finkel
क्यूं कर rwx और नहीं rw (या r बिल्कुल भी)? - anatoly techtonik
@anatolytechtonik से man 7 unix - सॉकेट से कनेक्ट होने वाले लिनक्स पर उस सॉकेट पर पढ़ने और लिखने की आवश्यकता होती है। इसके अलावा आपको उस सॉफ़्टवेयर पर खोज (निष्पादित) और लिखने की अनुमति चाहिए जहां आप सॉकेट बनाते हैं या जब आप इस सॉकेट से कनेक्ट होते हैं तो केवल खोज (निष्पादित) अनुमति की आवश्यकता होती है। तो उपर्युक्त उत्तर में सॉकेट पर निष्पादन अनुमति अनावश्यक है। - 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"

हालांकि यह बहुत जोखिम भरा है। आप मूल रूप से अपने अन्य एसएसएच एजेंट (जब तक आप लॉग आउट नहीं करते) का उपयोग करने के लिए सिस्टम अनुमति पर हर दूसरे उपयोगकर्ता को दे रहे हैं। आप समूह को सेट करने और अनुमतियों को 770 में बदलने में भी सक्षम हो सकते हैं, जो अधिक सुरक्षित हो सकता है। हालांकि, जब मैंने समूह को बदलने की कोशिश की, तो मुझे "ऑपरेशन की अनुमति नहीं मिली"।


16
2018-03-21 00:01



यह बेहद जोखिम भरा है। अपने एसएसएच एजेंट का उपयोग करने के लिए हर दूसरे उपयोगकर्ता को अनुमति देना उन्हें आपके सभी प्रमाण-पत्र देने के बराबर है (और यदि आप कभी भी सूडो या सु का उपयोग करते हैं, तो उन्हें सिस्टम पर अन्य सभी उपयोगकर्ताओं के साथ-साथ अन्य सभी प्रणालियों पर रूट पावर देते हैं!) । यह कभी नहीं किया जाना चाहिए! - Matija Nalis
मैं इस बयान से असहमत हूं कि "यह कभी भी नहीं किया जाना चाहिए!" ऐसे कई मामले हैं जहां यह जोखिम स्वीकार्य है। उदाहरण के लिए, एक छोटी सी टीम जहां सभी के पास समान अनुमतियां होती हैं और आप अन्य सभी उपयोगकर्ताओं पर भरोसा करते हैं। इसमें शामिल जोखिमों को समझे बिना इसे कभी नहीं किया जाना चाहिए। लेकिन एक बार उन जोखिमों को समझने के बाद, कई बार जोखिम स्वीकार्य होता है। - phylae


यदि आप के लिए अधिकृत हैं sudo su - $USER, तो आपके पास शायद करने के लिए अनुमति देने के लिए एक अच्छा तर्क होगा ssh -AY $USER@localhost इसके बजाय, $ USER की होम निर्देशिका में आपकी मान्य सार्वजनिक कुंजी के साथ। फिर आपके प्रमाणीकरण अग्रेषण आपके साथ किया जाएगा।


6
2018-01-28 14:08



उन्होंने उल्लेख किया कि उनके प्रश्न के निचले हिस्से में, और कहा कि यह करना मुश्किल होगा। - Fahad Sadah
यह शायद सबसे अच्छा समाधान है, लेकिन अगर उपयोगकर्ता एक वास्तविक व्यक्ति (टीएम) है तो यह बालों वाली हो जाता है - वे अधिकृत_की से एसए की कुंजी को हटा सकते हैं या अपना पासवर्ड बदल सकते हैं ... - voretaq7
आप अधिकृत_की पर अपनी लेखन पहुंच को हटा सकते हैं (हालांकि यदि वे वास्तव में फ्लोरियन पहुंच को अस्वीकार करने पर सेट हैं, तो वे इसे हटा सकते हैं और इसे फिर से बना सकते हैं, यह एक निर्देशिका में है) - Fahad Sadah


आप हमेशा sudo का उपयोग करने के बजाय एजेंट अग्रेषण के साथ स्थानीयहोस्ट के लिए ssh कर सकते हैं:

ssh -A otheruser@localhost

नुकसान यह है कि आपको फिर से लॉग इन करने की आवश्यकता है, लेकिन यदि आप इसे स्क्रीन / टीएमक्स टैब में उपयोग कर रहे हैं, तो यह केवल एक बार प्रयास है, हालांकि, यदि आप सर्वर से डिस्कनेक्ट करते हैं, तो सॉकेट (निश्चित रूप से) फिर से टूटा जाएगा । तो यह आदर्श नहीं है अगर आप हर समय अपनी स्क्रीन / tmux सत्र नहीं खोल सकते हैं (हालांकि, आप मैन्युअल रूप से अपना अपडेट कर सकते हैं SSH_AUTH_SOCKअगर आप शांत हैं तो env var)।

यह भी ध्यान रखें कि एसएसएच अग्रेषण का उपयोग करते समय, रूट हमेशा आपकी सॉकेट तक पहुंच सकता है और आपके एसएसएच प्रमाणीकरण का उपयोग कर सकता है (जब तक आप एसएसएच अग्रेषण के साथ लॉग इन होते हैं)। तो सुनिश्चित करें कि आप रूट पर भरोसा कर सकते हैं।


4
2017-11-27 14:56





उपयोग न करें sudo su - USER, बल्कि sudo -i -u USER। मेरे लिये कार्य करता है!


3
2018-01-28 16:51



आपके पास सुडो का क्या संस्करण है? मेरा (1.6.7 पी 5, सेंटोस 4.8) में अपने मैन पेज में नहीं है। - David Mackintosh
Sudo version 1.6.9p17 डेबियन लेनी पर चल रहा है। प्रयत्न sudo -s? - Fahad Sadah
मेरे लिए काम नहीं करता है।
उबंटू पर, सूडो 1.8.9 5 का उपयोग करके, न तो 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





दुर्भाग्यवश जब आप किसी अन्य उपयोगकर्ता (या सूडो का उपयोग भी करते हैं) के लिए मुकदमा करते हैं तो आप अपनी अग्रेषित कुंजी का उपयोग करने की क्षमता खो देंगे। यह एक सुरक्षा सुविधा है: आप नहीं चाहते हैं कि यादृच्छिक उपयोगकर्ता आपके एसएसएच एजेंट से जुड़ें और अपनी चाबियों का उपयोग करें :)

"Ssh -Ay $ {USER} @localhost" विधि थोड़ा बोझिल है (और जैसा कि डेविड के उत्तर पर मेरी टिप्पणी में उल्लेख किया गया है), लेकिन शायद यह सबसे अच्छा है जो आप कर सकते हैं।


1
2018-01-28 16:52



हम्म, लेकिन अगर मैं इसे एसएसएच के साथ करता हूं, तो मेरा एजेंट उस उपयोगकर्ता द्वारा वैसे भी सुलभ है, या मैं गलत हूं?
यदि आप अपने एजेंट अनुरोधों को अग्रेषित करने वाले एजेंट के साथ लक्षित उपयोगकर्ता में एसएसएच को "वास्तविक" एजेंट कहां से श्रृंखला तक उछाल देंगे। जब आप मूल उपयोगकर्ता से su या sudo दूर करते हैं तो आपका एसएसएच एजेंट सॉकेट एक्सेस नहीं करेगा (या नहीं होना चाहिए) - जिस निर्देशिका में वह रहता है वह मोड 700 है और मूल उपयोगकर्ता के स्वामित्व में है। (स्पष्ट चेतावनी: यदि आप रूट पर स्विच कर रहे हैं और SSH_AUTH_SOCK वातावरण को रीसेट कर सकते हैं तो यह काम कर सकता है, लेकिन मैं इस पर भरोसा नहीं करता) - voretaq7
मेरे सर्वर पर (उबंटू 12.04, एसएसएच संस्करण ओपनएसएसएच_5.9पी 1 डेबियन -5ubuntu1.1, ओपनएसएसएल 1.0.1 14 मार्च 2012), एसएसएच है -a तथा -A तर्क। -a क्या इरादा है इसके ठीक विपरीत है, यह एजेंट अग्रेषण अक्षम करता है! तो, उबंटू के हालिया (और संभवतः सभी) संस्करण के तहत, उपयोग करें -A एजेंट अग्रेषण सक्षम करने के लिए। - knite
@knite आप सही हैं - यह मेरे उत्तर में एक (3 साल पुराना!) टाइपो है। अब फिक्स्ड :-) - voretaq7


मुझे लगता है कि इसमें कोई समस्या है - (डैश) विकल्प के बाद su आपके आदेश में:

sudo su - otheruser

यदि आप के मैन पेज को पढ़ते हैं सु, आप विकल्प को पा सकते हैं -, -l, --login लॉगिन खोल के रूप में खोल पर्यावरण शुरू होता है। यह पर्यावरण के लिए होगा otheruser जहां आप चलाते हैं env चर के बावजूद su

सीधे शब्दों में कहें, डैश आपके द्वारा पारित कुछ भी कमजोर कर देगा sudo

इसके बजाय, आपको यह आदेश आज़माएं:

sudo -E su otheruser

जैसा कि @ जोओ-कोस्टा ने बताया, -E पर्यावरण में सभी चरों को संरक्षित रखेगा जहां आप भाग गए थे sudo। फिर डैश के बिना, su उस पर्यावरण का सीधे उपयोग करेंगे।


0
2018-04-05 10:03