Wiersz wyjściowy określony przez no tty present i no askpass program jest jednym z tych komunikatów o błędach ssh, które naprawdę nie są aż tak pomocne, ponieważ tak naprawdę nie docierają do tego, co powoduje problem. Jest bardziej niż prawdopodobne, że faktycznie pracujesz z jakimś ważnym TTY, kiedy widzisz wiadomość i prawdopodobnie masz do czynienia z wprowadzeniem hasła sudo przez ssh. Najprawdopodobniej masz do czynienia z błędem składniowym, ale wiadomość nie odnosi się bezpośrednio do tego faktu.
Ponieważ jest to problem związany z samym ssh, najprawdopodobniej będziesz w stanie odtworzyć problem w usługach Linux, FreeBSD, macOS i Unix Cygwin w systemie Microsoft Windows. Na szczęście poprawka powinna być prawie taka sama na wszystkich tych platformach.
Metoda 1: znalezienie terminala dla ssh
Chociaż prawdopodobnie pracujesz już z poziomu terminala, ssh prawdopodobnie nie zdaje sobie z tego sprawy. Może nadal próbować szukać emulatora terminala TTY, mimo że jesteś w oknie wiersza polecenia. Spróbuj odtworzyć błąd, aby to sprawdzić. Skonfigurowaliśmy maszynę wirtualną jako przykład i uruchomiliśmy ssh user@linuxtest.example „sudo /var/mail/startup.sh” jako test. Oczywiście będziesz chciał zmienić polecenie i wiersz ssh na coś, co pasuje do tego, co próbujesz zrobić.
Musisz się upewnić, że logujesz się na serwer, o którym myślisz, że jesteś. Niezależnie od tego, sprawdź, czy nadal otrzymujesz komunikat o błędzie sudo: no tty present i żaden program askpass nie podał komunikatu o błędzie. Bardziej niż prawdopodobne, jeśli nadal go otrzymujesz, zobaczysz go trzy razy, a być może nawet zostaniesz poproszony o wpisanie hasła w taki sposób, w jaki byś korzystał z sudo lokalnie na Debianie lub Ubuntu.
Spróbuj dodać -t po ssh, aby poprawić błąd składni. Dziewięć razy na dziesięć zmusi to ssh do przydzielenia sobie wirtualnego TTY i udawania, że akurat działa w prawdziwym terminalu. Nie musisz nic więcej zmieniać w swoim poleceniu. Po prostu dodaj opcję -t po literach ssh, a następnie zachowaj hosta i przekazaną komendę bez zmian. Warto o tym pamiętać, jeśli kiedykolwiek będziesz musiał uruchomić ssh w drugiej części polecenia.
Na przykład, jeśli otrzymujesz ten sam rodzaj błędu podczas uruchamiania polecenia sformatowanego jako ssh -t użytkownik@linuxtest.example „ssh użytkownik@linuxtest2.example” aby temu zapobiec, musiałbyś zachować opcję -t po pierwszym ssh. Zwróć uwagę, że jeśli później zmienisz drugie polecenie, aby albo wytwarzało, albo zużywało dane, nie chciałbyś w ogóle używać -t. Na przykład, jeśli zacząłeś uruchamiać cat zamiast skryptu, możesz zrzucić -t, ponieważ nie musiałbyś przydzielać do tego terminala.
Metoda 2: Poprawianie pliku visudo
Możesz również mieć problem z konfiguracją, który powoduje ten błąd. Zmodyfikuj plik visudo, wydając plik sudo visudo polecenie i pamiętaj, że nigdy nie będziesz chciał edytować tego pliku w żaden inny sposób. Powinieneś znaleźć wiersz zawierający ALL = NOPASSWD, a po nim typy poleceń, których nie trzeba wprowadzać do uruchomienia hasła administratora.
Każde indywidualne polecenie musi kończyć się przecinkiem, z wyjątkiem ostatniego w wierszu. Tak więc, jeśli masz coś, co brzmi jak / sbin / poweroff / sbin / start / sbin / stop, potraktuje to wszystko jako pojedyncze polecenie i wyrzuci błąd na ciebie. Podobnie, jeśli brakuje polecenia, które próbujesz uruchomić przez ssh, również pojawi się ten błąd. Dokonaj niezbędnych zmian i zapisz plik przed sprawdzeniem, czy błąd jest nadal odtwarzalny.
Jeśli błąd nadal występuje, nawet po wykonaniu tej czynności i ponownym uruchomieniu usługi, wypróbuj plik następujące polecenie na obrazku poniżej i upewnij się, że wiersz PermitTTY zawiera po nim słowo tak. Jeśli jest to ostatnia linia w Twoim pliku, upewnij się, że jest tam pusty nowy wiersz. GNU nano domyślnie wykonuje to zadanie automatycznie.
Przed ponownym odtworzeniem komunikatu o błędzie konieczne będzie ponowne uruchomienie wszystkich odpowiednich usług.
3 minuty czytania
