ग़ैर-इंटरैक्टिव SSH पासवर्ड प्रमाणीकरण
SSH connections को automate करना जिनमें पासवर्ड की आवश्यकता होती है, अब भी विवादास्पद है: कुछ इंजीनियर `sshpass` जैसे tools पर निर्भर रहते हैं, जबकि अन्य तर्क देते हैं कि ये तरीके नाज़ुक हैं क्योंकि ये prompts को parse करने और fragile TTY behavior पर निर्भर करते हैं। कई प्रतिभागी मानते हैं कि public key या certificate-based authentication, Kerberos, या short‑lived SSH certificates अधिक सुरक्षित और scalable हैं, लेकिन यह भी स्वीकार करते हैं कि legacy network gear, TACACS/RADIUS setups, और vendor constraints अक्सर password-only SSH को ही एकमात्र व्यावहारिक विकल्प छोड़ देते हैं। बातचीत privileged access को scale पर manage करने तक फैलती है—configuration management, PAM products, bastion hosts, या custom agents के माध्यम से—और वास्तविक-world infrastructures में security, complexity, और reliability के बीच trade-offs को उजागर करती है।
ग़ैर-इंटरैक्टिव SSH पासवर्ड प्रमाणीकरण के तरीके
- कई टिप्पणीकारों का तर्क है कि SSH के लिए पासवर्ड प्रमाणीकरण से बचना चाहिए; कुंजियाँ/प्रमाणपत्र बेहतर हैं, और कुछ लोग पासवर्ड लॉगिन पूरी तरह बंद कर देते हैं।
- अन्य लोग बताते हैं कि कुछ नेटवर्क डिवाइसों, BMCs, विक्रेता बॉक्सों, TACACS+/RADIUS सेटअपों, या प्रारंभिक provisioning में, जहाँ केवल पासवर्ड उपलब्ध होते हैं, ग़ैर-इंटरैक्टिव पासवर्ड प्रमाणीकरण से बचा नहीं जा सकता।
- कुछ लोग OTP/TOTP-आधारित SSH को स्वचालित करने का प्रयास कर रहे हैं, लेकिन ठोस, मज़बूत recipes का विवरण नहीं दिया गया है।
sshpass बनाम विकल्प (passh, ASKPASS, expect)
- कई लोग कहते हैं कि sshpass “काफी अच्छा” है, और उदाहरण देते हैं कि इसे बड़े पैमाने पर (दसियों हज़ार मशीनों पर) बिना समस्या इस्तेमाल किया गया है; वे इसकी सरलता की भी प्रशंसा करते हैं।
- आलोचकों का कहना है कि sshpass नाज़ुक है क्योंकि यह पासवर्ड prompts को parse करता है; prompt या TTY व्यवहार में बदलाव इसे तोड़ सकता है।
- एक वैकल्पिक तरीका SSH_ASKPASS और SSH_ASKPASS_REQUIRE (नए OpenSSH clients में) का उपयोग करके अधिक नियंत्रित तरीके से पासवर्ड inject करना है, जिससे अतिरिक्त tools सरल हो सकते हैं या अनावश्यक हो सकते हैं।
- passh tool को TTY handling के मामले में अधिक मज़बूत बताया गया है; sshpass पर “broken by design” का आरोप उसी project से आया है, न कि लेख के लेखक से।
- expect जैसे पारंपरिक tools का भी उल्लेख है; वे शक्तिशाली हैं, लेकिन ख़ासकर cron के तहत या वास्तविक TTY के बिना, नाज़ुक हो सकते हैं।
कुंजियाँ, प्रमाणपत्र, और वास्तविक-विश्व की सीमाएँ
- टिप्पणीकार फिर दोहराते हैं कि keys/certs “सही तरीका” हैं, लेकिन कई बाधाएँ बताते हैं:
- नेटवर्क gear (जैसे कुछ Cisco/Juniper variants, Ubiquiti devices) जहाँ key setup awkward या non-persistent होता है।
- TACACS+/RADIUS के माध्यम से केंद्रीय authentication अक्सर पासवर्ड के आसपास डिज़ाइन किया गया होता है, key support सीमित या ad‑hoc होता है।
- कई embedded SSH stacks में FIDO2 जैसी आधुनिक सुविधाएँ नहीं होतीं।
- कुछ लोग SSH certificates, Kerberos, या FreeIPA सुझाते हैं, लेकिन operational और organizational जटिलता को स्वीकार करते हैं।
TTY, scripting, और मज़बूती
- cron jobs, sftp, और ऐसे tools की कई कहानियाँ हैं जो controlling TTY के बिना अलग तरह से व्यवहार करते हैं।
- workaround में
script,screen,ssh -t, Paramiko, और sftp की जगह rsync शामिल हैं। - इस पर बहस है कि क्या TTY/
/procparsing और shell scripting “manual पढ़ने पर trivial” हैं या मूलतः footguns से भरे हुए हैं; principle of least astonishment का मुद्दा उठाया जाता है।
विशेषाधिकार प्राप्त पहुँच और उच्च-स्तरीय समाधान
- कुछ लोग privileged access management systems, bastions, user-associated VPNs, या short‑lived SSH certs (जैसे Vault/Teleport के माध्यम से) का समर्थन करते हैं ताकि पासवर्ड को सीधे embedded करने से बचा जा सके।
- अन्य चेतावनी देते हैं कि ये products स्वयं भी high-value, fragile targets हो सकते हैं, और अच्छा IAM/PAM design एक और proxy layer जोड़ने से अधिक महत्वपूर्ण हो सकता है।