يعد سطر الإخراج المحدد لبرنامج no tty و no askpass أحد رسائل خطأ ssh التي ليست مفيدة حقًا لأنها لا تصل حقًا إلى نقطة سبب المشكلة. على الأرجح ، أنت تعمل فعليًا باستخدام TTY صالح من نوع ما عندما ترى الرسالة وربما تكون قد تعاملت مع إدخال كلمة مرور sudo عبر ssh على ما يرام. من المرجح أنك تتعامل مع خطأ نحوي ، لكن الرسالة لا تتناول هذه الحقيقة بشكل مباشر.
نظرًا لأن هذه مشكلة مرتبطة بـ ssh نفسها ، فستتمكن على الأرجح من إعادة إنتاج المشكلة على خدمات Linux و FreeBSD و macOS و Cygwin's Unix على Microsoft Windows. لحسن الحظ ، يجب أن يكون الإصلاح متماثلًا إلى حد كبير على جميع هذه الأنظمة الأساسية.
الطريقة الأولى: البحث عن محطة طرفية لـ ssh
على الرغم من أنك تعمل بالفعل من محطة طرفية ، فمن المحتمل ألا تدرك ssh ذلك. ربما لا يزال يحاول البحث عن محاكي طرفية TTY على الرغم من حقيقة أنك داخل نافذة موجه الأوامر. حاول إعادة إنتاج الخطأ لاختبار ذلك. قمنا بتكوين جهاز افتراضي ليكون بمثابة مثال وقمنا بتشغيله ssh user@linuxtest.example 'sudo /var/mail/startup.sh' كاختبار. بطبيعة الحال ، سترغب في تغيير الأمر وسطر ssh إلى شيء يطابق ما تحاول القيام به.
ستحتاج إلى التأكد من أنك تقوم بتسجيل الدخول إلى الخادم الذي كنت تعتقد أنك كذلك. بغض النظر ، تحقق لمعرفة ما إذا كنت لا تزال تتلقى sudo: لا يوجد tty ولا توجد رسالة خطأ محددة لبرنامج askpass. على الأرجح ، إذا كنت لا تزال تستقبلها ، فسترى ذلك ثلاث مرات وربما يُطلب منك إدخال كلمة المرور بالطريقة التي تريدها إذا كنت تقوم بتشغيل sudo محليًا على Debian أو Ubuntu.
حاول إضافة -t بعد ssh لتصحيح الخطأ النحوي. تسع مرات من أصل عشرة ، سيجبر ذلك ssh على تخصيص TTY افتراضي لنفسه والتظاهر بأنه يعمل داخل محطة حقيقية. لست مضطرًا لتغيير أي شيء آخر بخصوص أوامرك. ما عليك سوى إضافة الخيار -t بعد الأحرف ssh ثم احتفظ بالمضيف وأمر الأمر نفسه. ستحتاج أيضًا إلى وضع ذلك في الاعتبار إذا كان عليك تشغيل ssh في الجزء الأخير من الأمر.
على سبيل المثال ، إذا كنت تتلقى نفس النوع من الخطأ عند تشغيل أمر تم تنسيقه كـ ssh -t user@linuxtest.example 'ssh user@linuxtest2.example' سيتعين عليك الاحتفاظ بخيار -t بعد أول ssh لمنعه. لاحظ أنك إذا غيرت الأمر الثاني لاحقًا لإنتاج البيانات أو استهلاكها ، فلن ترغب في استخدام -t على الإطلاق. على سبيل المثال ، إذا بدأت تشغيل cat بدلاً من نص برمجي ، فيمكنك التخلص من -t نظرًا لأنك لن تحتاج إلى تخصيص محطة طرفية لذلك.
الطريقة 2: تصحيح ملف visudo
قد يكون لديك أيضًا مشكلة في التكوين تؤدي إلى ظهور هذا الخطأ. قم بتعديل ملف visudo بإصدار ملف sudo visudo الأمر ، وتذكر أنك لن ترغب أبدًا في تعديل هذا الملف بأي طريقة أخرى. يجب أن تجد سطرًا يحتوي على ALL = NOPASSWD فيه متبوعًا بأنواع الأوامر التي لا تحتاجها لإدخال كلمة مرور المسؤول للتشغيل.
يجب أن ينتهي كل أمر فردي بفاصلة باستثناء آخر أمر في السطر. وبالتالي ، إذا كان لديك شيء يقرأ مثل / sbin / poweroff / sbin / start / sbin / stop ، فسوف يتعامل مع كل ذلك كأمر واحد ويرمي الخطأ إليك. وبالمثل ، إذا كنت تفتقد أمرًا تحاول تشغيله عبر ssh ، فستتلقى هذا الخطأ أيضًا. قم بإجراء التعديلات اللازمة واحفظ الملف قبل التحقق مما إذا كان الخطأ لا يزال قابلاً للتكرار.
إذا كان لا يزال لديك الخطأ حتى بعد القيام بذلك وإعادة تشغيل الخدمة ، فجرّب الأمر التالي في الصورة أدناه وتأكد من أن سطر PermitTTY يحتوي على كلمة نعم بعدها. إذا كان هذا هو آخر سطر في ملفك ، فتأكد من وجود سطر جديد فارغ بعد ذلك. ينفذ GNU nano هذه المهمة تلقائيًا بشكل افتراضي.
ستحتاج إلى إعادة تشغيل أي خدمات ذات صلة قبل محاولة إعادة إنتاج رسالة الخطأ مرة أخرى.
3 دقائق للقراءة
