A nincs tty jelen és nincs askpass program által megadott kimeneti sor egyike azoknak az ssh hibaüzeneteknek, amelyek valóban nem annyira hasznosak, mert nem igazán jutnak el odáig, hogy mi okozza a problémát. Több mint valószínű, hogy valójában valamilyen érvényes TTY-vel dolgozik, amikor meglátja az üzenetet, és valószínűleg foglalkozott azzal, hogy a sudo jelszavát az ssh felett megadja. Nagy valószínűséggel foglalkozik egy szintaktikai hibával, de az üzenet nem foglalkozik közvetlenül ezzel a ténnyel.
Mivel ez a probléma magában az ssh-ben van, valószínűleg többször is képes lesz újratermelni a problémát Linuxon, FreeBSD-n, macOS-on és a Cygwin Unix szolgáltatásain Microsoft Windows rendszeren. Szerencsére a javításnak nagyjából azonosnak kell lennie ezeken a platformokon.
1. módszer: Terminál keresése az ssh számára
Bár több mint valószínű, hogy már terminálról dolgozik, az ssh valószínűleg ezt nem veszi észre. Lehet, hogy még mindig próbál TTY terminál emulátort keresni, annak ellenére, hogy a parancssor ablakában tartózkodik. Ennek teszteléséhez próbálja meg megismételni a hibát. Konfiguráltunk egy virtuális gépet, amely példaként szolgál, és futtattuk ssh user@linuxtest.example ’sudo /var/mail/startup.sh’ mint teszt. Természetesen meg akarja változtatni a parancsot és az ssh sort olyasmire, amely megfelel annak, amit megpróbál.
Gondoskodnia kell arról, hogy bejelentkezzen abba a kiszolgálóba, amelyet korábban gondolt. Ettől függetlenül ellenőrizze, hogy továbbra is megkapja-e a sudo: nincs tty jelen és nincs askpass program által megadott hibaüzenet. Több mint valószínű, hogy ha még mindig megkapja, akkor háromszor látni fogja, és esetleg felkérést kap arra, hogy írja be a jelszavát, ahogyan tenné, ha helyileg futtatná a sudo-t a Debianon vagy az Ubuntun.
Próbálja meg hozzáadni a -t az ssh után a szintaktikai hiba kijavításához. Tízből kilencszer ez arra kényszeríti az ssh-t, hogy allokáljon magának egy virtuális TTY-t, és úgy tegyen, mintha történetesen egy valós terminál belsejében futna. Nem kell mást változtatnia a parancsán. Egyszerűen adja hozzá a -t opciót az ssh betűk után, majd a host és a pass parancsot tartsa ugyanazon. Ezt is szem előtt kell tartania, ha valaha is az ssh-t kell futtatnia a parancs utolsó részében.
Például, ha ugyanezt a hibát kapta, amikor egy parancsot formázott ssh -t user@linuxtest.example ’ssh user@linuxtest2.example’ az első ssh után meg kellene tartania a -t opciót, hogy megakadályozza. Vegye figyelembe, hogy ha később megváltoztatja a második parancsot adatok előállítására vagy felhasználására, akkor egyáltalán nem akarja használni a -t. Például, ha a szkript helyett a macskát kezdte futtatni, akkor kiírhatja a -t, mivel ehhez nem kell terminált rendelnie.
2. módszer: A visudo fájl javítása
Előfordulhat, hogy konfigurációs probléma is okozza ezt a hibát. Módosítsa a visudo fájlt a sudo visudo parancsot, és ne feledje, hogy ezt a fájlt soha nem akarja más módon szerkeszteni. Találnia kell egy sort, amely tartalmazza az ALL = NOPASSWD szót, majd azokat a parancsokat, amelyeket a rendszergazda jelszavának megadásához nem kell megadnia.
Minden egyes parancsnak vesszővel kell végződnie, a sor utolsó kivételével. Így ha valami olyasmi van, mint a / sbin / poweroff / sbin / start / sbin / stop, akkor ezeket mind egyetlen parancsként kezeli, és a hibát rád dobja. Hasonlóképpen, ha hiányzik egy parancs, amelyet az ssh-n keresztül próbál futtatni, akkor ezt a hibát is megkapja. Végezze el a szükséges beállításokat, és mentse a fájlt, mielőtt ellenőrizné, hogy a hiba továbbra is megismételhető-e.
Ha ennek ellenére és a szolgáltatás újraindítása után is fennáll a hiba, akkor próbálkozzon a következő parancsot az alábbi képen és győződjön meg arról, hogy a PermitTTY sorban szerepel az igen szó. Ha ez a fájl utolsó sora, akkor győződjön meg róla, hogy utána üres új sor van. A GNU nano alapértelmezés szerint automatikusan elvégzi ezt a feladatot.
Mielőtt megpróbálná újból megismételni a hibaüzenetet, újra kell indítania a releváns szolgáltatásokat.
3 perc olvasás
