SSH StrictModes, Agent Forwarding (ssh -A) और ssh -a: पूरी जानकारी
अगर home, ~/.ssh या authorized_keys दूसरों द्वारा लिखने योग्य हों तो SSH StrictModes कीज़ को ठुकरा देता है; chmod से ठीक करें। अविश्वसनीय होस्ट पर ssh -A से बचें; ssh -a इसे बंद करता है।
संक्षेप में: `StrictModes yes` (OpenSSH का डिफ़ॉल्ट) sshd को किसी key को स्वीकार करने से पहले आपकी home डायरेक्टरी, `~/.ssh` और `~/.ssh/authorized_keys` का स्वामित्व और permissions जाँचने को कहता है। अगर इनमें से कोई भी group या others द्वारा लिखने योग्य है, या किसी दूसरे यूज़र का है, तो यह "Authentication refused: bad ownership or modes" के साथ लॉगिन ठुकरा देता है। जाँच बंद करने के बजाय permissions ठीक करें। `ssh -A` के साथ agent forwarding, कनेक्ट रहते हुए रिमोट होस्ट को आपकी लोकल keys इस्तेमाल करने देता है, इसलिए जिन होस्ट पर आपको पूरा भरोसा नहीं है वहाँ इससे बचें और उसकी जगह `ssh -J` (ProxyJump) अपनाएँ; छोटा `ssh -a` agent forwarding को स्पष्ट रूप से बंद करता है।
यह गाइड SSH hardening गाइड का पूरक है और Debian 12/13, Ubuntu 24.04 तथा AlmaLinux 9 और Rocky 9 जैसे RHEL-परिवार के सिस्टम पर लागू होती है।
SSH StrictModes क्या जाँचता है
StrictModes `/etc/ssh/sshd_config` में एक सर्वर-साइड सेटिंग है। इसका मकसद सीधा है: अगर कोई दूसरा यूज़र आपकी `authorized_keys` में लिख सकता है, तो वह अपनी key जोड़कर आपके नाम से लॉगिन कर सकता है। इसलिए जब तक पूरा पाथ सुरक्षित न हो, sshd उस फ़ाइल पर भरोसा नहीं करता। यह फ़ाइल और उसके ऊपर की डायरेक्टरियाँ, home डायरेक्टरी समेत, जाँचता है।
असल में लागू वैल्यू `sshd -T | grep -i strictmodes` से पक्की करें। Ubuntu 24.04 और Debian 13 पर `/etc/ssh/sshd_config.d/` की drop-in फ़ाइलें भी देखें।
| पाथ | StrictModes की शर्त | सुझाया गया mode |
|---|---|---|
| /home/alice | alice या root का स्वामित्व, group/world-writable नहीं | 755, 750 या 700 |
| /home/alice/.ssh | alice या root का स्वामित्व, group/world-writable नहीं | 700 |
| /home/alice/.ssh/authorized_keys | alice या root का स्वामित्व, group/world-writable नहीं | 600 |
| /root और /root/.ssh (root लॉगिन) | root का स्वामित्व, group/world-writable नहीं | 700 |
"Authentication refused: bad ownership or modes" कैसे ठीक करें
क्लाइंट सिर्फ़ एक सामान्य `Permission denied (publickey)` दिखाता है। असली वजह सर्वर लॉग में होती है, जो सटीक पाथ बताता है, जैसे `Authentication refused: bad ownership or modes for directory /home/alice` या `... for file /home/alice/.ssh/authorized_keys`। इसे ठीक करने के लिए अपने VPS कंसोल या किसी दूसरे सेशन का इस्तेमाल करें।
- 01.लॉग पढ़ें: Debian और Ubuntu पर `journalctl -u ssh -n 50`, या AlmaLinux और Rocky पर `journalctl -u sshd -n 50`।
- 02.यूज़र की SSH डायरेक्टरी का स्वामित्व ठीक करें: `chown -R alice:alice /home/alice/.ssh`।
- 03.modes ठीक करें: `chmod 700 /home/alice/.ssh` और `chmod 600 /home/alice/.ssh/authorized_keys`।
- 04.home डायरेक्टरी से group और world write हटाएँ: `chmod go-w /home/alice`।
- 05.SELinux वाले सिस्टम (AlmaLinux, Rocky, Fedora) पर labels बहाल करें: `restorecon -Rv /home/alice/.ssh`।
- 06.चालू सेशन खुला रखते हुए नए टर्मिनल से `ssh -v alice@server` चलाकर टेस्ट करें।
# all-in-one, run as root on the server
chown -R alice:alice /home/alice/.ssh
chmod go-w /home/alice
chmod 700 /home/alice/.ssh
chmod 600 /home/alice/.ssh/authorized_keys
namei -l /home/alice/.ssh/authorized_keys # shows owner and mode of every path componentNote · एरर हटाने के लिए `StrictModes no` सेट न करें। इससे एक असली सुरक्षा हट जाती है और गलत कॉन्फ़िगरेशन ठीक होने के बजाय छिप जाता है।
StrictModes बनाम StrictHostKeyChecking
"ssh strictmode" खोजने वाले अक्सर दो अलग-अलग विकल्पों को मिला देते हैं। `StrictModes` सर्वर की `sshd_config` में होता है और फ़ाइल permissions जाँचता है। `StrictHostKeyChecking` क्लाइंट की `ssh_config` या `~/.ssh/config` में होता है और तय करता है कि सर्वर की host key अज्ञात हो या बदल गई हो तो क्या हो। क्लाइंट की अपनी permission जाँच भी होती है: जिस private key को दूसरे यूज़र पढ़ सकें, उसे वह unprotected private key file की चेतावनी के साथ इस्तेमाल करने से मना कर देता है; `chmod 600 ~/.ssh/id_ed25519` से यह ठीक हो जाता है।
ssh -A के साथ agent forwarding: जोखिम
`ssh -A` (या `ForwardAgent yes`) रिमोट होस्ट पर `$SSH_AUTH_SOCK` से संदर्भित एक socket बनाता है, जो signing अनुरोधों को आपकी मशीन के ssh-agent तक वापस भेजता है। आपकी private key कभी आपकी मशीन से बाहर नहीं जाती, लेकिन जो भी उस socket तक पहुँच सकता है, वह आपके कनेक्ट रहते आपकी key इस्तेमाल कर सकता है। रिमोट होस्ट पर इसमें root और आपके यूज़र के रूप में चलने वाली हर प्रोसेस शामिल है।
अगर सर्वर compromise हो जाए या उसे कोई और संभालता हो, तो हमलावर चुपचाप उन सभी होस्ट में लॉगिन कर सकता है जिन्हें आपकी key खोलती है, Git होस्टिंग और प्रोडक्शन सर्वर समेत। इसी वजह से OpenSSH क्लाइंट का डिफ़ॉल्ट `ForwardAgent no` है।
- ▹अपना agent कभी भी साझा, थर्ड-पार्टी या हाल ही में दोबारा इंस्टॉल किए गए ऐसे होस्ट पर forward न करें जिन्हें आपने harden नहीं किया है।
- ▹अगर forward करना ही पड़े, तो `ssh-add -c` इस्तेमाल करें ताकि key के हर उपयोग पर लोकल पुष्टि माँगी जाए।
- ▹OpenSSH 8.9 और नए वर्ज़न `ssh-add -h` के साथ destination constraints सपोर्ट करते हैं, जिससे सीमित होता है कि forward की गई key किन होस्ट के लिए इस्तेमाल हो सकती है।
- ▹सर्वर-साइड पर `sshd_config` में `AllowAgentForwarding no` इसे बंद करता है, हालाँकि shell एक्सेस वाले यूज़र फिर भी अपने forwarders बना सकते हैं।
bastion के लिए ProxyJump (ssh -J) को प्राथमिकता दें
ज़्यादातर agent forwarding किसी bastion के ज़रिए अंदरूनी मशीन तक पहुँचने के लिए होती है। `ssh -J` यह काम आपका agent उजागर किए बिना करता है: bastion सिर्फ़ एक एन्क्रिप्टेड TCP स्ट्रीम आगे भेजता है, और अंदरूनी होस्ट पर authentication सीधे आपके लैपटॉप से end to end होता है। जो सर्वर सिर्फ़ प्राइवेट नेटवर्क पर पहुँचने योग्य हैं, उनके लिए WireGuard टनल एक और विकल्प है; देखें WireGuard VPN गाइड या WireGuard mesh गाइड, और keepalive व PSK सेटिंग्स के लिए यह WireGuard tuning गाइड।
NoctisNode VPS पर आपको KVM मशीन पर SSH के ज़रिए पूरा root मिलता है, इसलिए एक छोटा Wisp प्लान बिना किसी और सेवा के एक समर्पित jump host बन सकता है; देखें VPS प्लान।
# one-off
ssh -J [email protected] [email protected]
# ~/.ssh/config
Host bastion
HostName bastion.example.com
User alice
ForwardAgent no
Host db1
HostName 10.88.0.3
User alice
ProxyJump bastionssh -a (छोटा a) क्या करता है
छोटा `ssh -a` उस कनेक्शन के लिए agent forwarding बंद करता है, यानी `-A` का उल्टा। यह तब काम आता है जब आपकी `~/.ssh/config` किसी wildcard होस्ट के लिए `ForwardAgent` चालू करती है और आप पक्का करना चाहते हैं कि कोई खास कनेक्शन forward न करे, जैसे `ssh -a admin@untrusted-host`। इसे `ssh-agent -a` से न मिलाएँ, जो agent के socket का पाथ तय करता है, और न ही `ssh-add` से, जो agent में keys लोड करता है।
अक्सर पूछे जाने वाले सवाल
Qsshd_config में StrictModes क्या करता है?
Aयह sshd से जाँच करवाता है कि यूज़र की home डायरेक्टरी, ~/.ssh और authorized_keys यूज़र या root के स्वामित्व में हों और group या others द्वारा लिखने योग्य न हों। जाँच फ़ेल होने पर key authentication ठुकरा दिया जाता है।
QAuthentication refused: bad ownership or modes कैसे ठीक करूँ?
A`chmod go-w ~`, `chmod 700 ~/.ssh` और `chmod 600 ~/.ssh/authorized_keys` चलाएँ, और पक्का करें कि फ़ाइलें यूज़र के स्वामित्व में हों। सर्वर लॉग सटीक गलत पाथ बताता है।
Qक्या ssh -A agent forwarding सुरक्षित है?
Aसिर्फ़ उन होस्ट पर जिन पर आपको पूरा भरोसा हो। आपके कनेक्ट रहते, रिमोट होस्ट का root या कोई compromised अकाउंट आपके forward किए गए agent से कहीं और आपके नाम से authenticate कर सकता है; इसकी जगह `ssh -J` इस्तेमाल करें।
Qssh -A और ssh -a में क्या अंतर है?
Aबड़ा `-A` आपके ssh-agent को रिमोट होस्ट तक forward करना चालू करता है। छोटा `-a` उस कनेक्शन के लिए agent forwarding बंद करता है और आपकी config में किसी भी `ForwardAgent yes` को ओवरराइड करता है।
Qक्या मुझे StrictModes no सेट करना चाहिए?
Aनहीं। इसे बंद करने से तब भी लॉगिन हो जाता है जब दूसरे यूज़र आपकी authorized_keys बदल सकते हों, जो एक असली सुरक्षा छेद है; इसकी जगह स्वामित्व और permissions ठीक करें।