no tty present and no askpass program specified आउटपुट लाइन उन ssh त्रुटि संदेशों में से एक है जो वास्तव में इतना उपयोगी नहीं है क्योंकि यह वास्तव में इस मुद्दे का कारण क्या है, इस बात पर नहीं पहुंचता। संभावना से अधिक, जब आप संदेश देखते हैं तो आप वास्तव में किसी प्रकार के वैध TTY के साथ काम कर रहे होते हैं और आपने शायद ssh पर अपना sudo पासवर्ड दर्ज करने के साथ ठीक से निपटाया है। आप एक सिंटैक्स गलती से निपटने की अधिक संभावना रखते हैं, लेकिन संदेश सीधे इस तथ्य को संबोधित नहीं करता है।
चूंकि यह ssh से जुड़ी एक समस्या है, आप संभवतः Linux, FreeBSD, macOS और Microsoft Windows पर Cygwin की Unix सेवाओं पर समस्या को पुन: उत्पन्न करने में सक्षम होंगे। सौभाग्य से, फिक्स इन सभी प्लेटफॉर्म पर बहुत समान होना चाहिए।
विधि 1: ssh के लिए एक टर्मिनल ढूंढना
जबकि आप संभवतः पहले से ही एक टर्मिनल से काम कर रहे हैं, ssh को शायद इसका एहसास नहीं है। यह अभी भी एक TTY टर्मिनल एमुलेटर की तलाश में हो सकता है इस तथ्य के बावजूद कि आप एक कमांड प्रॉम्प्ट विंडो के अंदर हैं। इसे टेस्ट करने के लिए त्रुटि को पुन: उत्पन्न करने का प्रयास करें। हमने एक वर्चुअल मशीन को एक उदाहरण के रूप में सेवा करने के लिए कॉन्फ़िगर किया और टेस्ट के रूप में ssh user@linuxtest.example 'sudo /var/mail/startup.sh' चलाया। स्वाभाविक रूप से, आप कमांड और ssh लाइन को उस चीज़ में बदलना चाहेंगे जो आप करने की कोशिश कर रहे हैं उससे मेल खाती हो।
आप यह सुनिश्चित करना चाहेंगे कि आप उस सर्वर में लॉग इन कर रहे हैं जिसे आपने सोचा था कि आप थे। भले ही, जांचें कि क्या आपको अभी भी sudo: no tty present and no askpass program specified त्रुटि संदेश प्राप्त हो रहा है। संभावना से अधिक, यदि आप अभी भी इसे प्राप्त कर रहे हैं तो आप इसे तीन बार देखेंगे और संभवतः अपना पासवर्ड दर्ज करने के लिए प्रेरित होंगे जैसे आपने किया होता यदि आप Debian या Ubuntu पर स्थानीय रूप से sudo चला रहे थे।
ssh के बाद -t जोड़कर अपने सिंटैक्स त्रुटि को ठीक करने का प्रयास करें। दस में से नौ बार यह ssh को खुद को एक वर्चुअल TTY आवंटित करने के लिए मजबूर करेगा और यह दिखावा करेगा कि यह एक वास्तविक टर्मिनल के अंदर चल रहा है। आपको अपनी कमांड के बारे में कुछ और बदलने की आवश्यकता नहीं है। बस ssh अक्षरों के बाद -t विकल्प जोड़ें और फिर होस्ट और पास की गई कमांड को समान रखें। आप इसे ध्यान में रखना चाहेंगे यदि आपको कभी अपने कमांड के बाद के हिस्से में ssh चलाना पड़ता है।
उदाहरण के लिए, यदि आपको ssh -t user@linuxtest.example 'ssh user@linuxtest2.example' के रूप में स्वरूपित कमांड चलाते समय इसी तरह की त्रुटि मिल रही थी, तो आपको पहले ssh के बाद -t विकल्प को रखना होगा ताकि इसे रोका जा सके। ध्यान दें कि यदि आप बाद में दूसरी कमांड को डेटा उत्पन्न करने या उपभोग करने के लिए बदलते हैं, तो आप बिल्कुल भी -t का उपयोग नहीं करना चाहेंगे। उदाहरण के लिए, यदि आप स्क्रिप्ट के बजाय cat चलाना शुरू करते हैं तो आप -t को छोड़ सकते हैं क्योंकि आपको उसके लिए टर्मिनल आवंटित करने की आवश्यकता नहीं होगी।
विधि 2: visudo फ़ाइल को पैच करना
आपके पास एक कॉन्फ़िगरेशन समस्या भी हो सकती है जो इस त्रुटि को उत्पन्न करती है। sudo visudo कमांड जारी करके visudo फ़ाइल को संशोधित करें, और ध्यान रखें कि आप इस फ़ाइल को किसी अन्य तरीके से संपादित नहीं करना चाहेंगे। आपको एक लाइन मिलनी चाहिए जिसमें ALL = NOPASSWD है जिसके बाद उन कमांड के प्रकार आते हैं जिन्हें चलाने के लिए आपको एडमिनिस्ट्रेटर का पासवर्ड दर्ज करने की आवश्यकता नहीं है।
प्रत्येक व्यक्तिगत कमांड को अंतिम को छोड़कर अल्पविराम के साथ समाप्त करने की आवश्यकता है। इस प्रकार यदि आपके पास /sbin/poweroff /sbin/start /sbin/stop जैसा कुछ था तो यह इन सभी को एक ही कमांड के रूप में मानेगा और आपको त्रुटि देगा। इसी तरह, यदि आप ssh के माध्यम से चलाने की कोशिश कर रहे कमांड को याद कर रहे हैं तो आपको यह त्रुटि भी मिलेगी। आवश्यक समायोजन करें और जांचने से पहले फ़ाइल को सेव करें कि क्या त्रुटि अभी भी पुन: उत्पन्न होती है।
यदि ऐसा करने और सेवा को पुनरारंभ करने के बाद भी आपको त्रुटि है, तो नीचे दी गई छवि में कमांड आज़माएं और सुनिश्चित करें कि PermitTTY लाइन में इसके बाद yes शब्द है। यदि यह आपकी फ़ाइल में अंतिम लाइन है, तो सुनिश्चित करें कि इसके बाद एक खाली नई लाइन है। GNU nano डिफ़ॉल्ट रूप से इस कार्य को स्वचालित रूप से करता है।
त्रुटि संदेश को फिर से पुन: उत्पन्न करने का प्रयास करने से पहले आपको किसी भी प्रासंगिक सेवा को पुनरारंभ करना होगा।
