Den nuvarande och ingen askpass-programspecificerade utgångslinjen är ett av de ssh-felmeddelandena som verkligen inte är så bra eftersom det inte riktigt kommer till punkten vad som orsakar problemet. Mer än troligtvis arbetar du faktiskt med en giltig TTY av något slag när du ser meddelandet och du har förmodligen behandlat att ange ditt sudo-lösenord över ssh bara bra. Du har mer än troligtvis att göra med ett syntaxfel, men meddelandet adresserar inte detta faktum direkt.
Eftersom detta är ett problem associerat med ssh i sig, kommer du mer än troligt att kunna reproducera problemet på Linux, FreeBSD, macOS och Cygwins Unix-tjänster på Microsoft Windows. Lyckligtvis borde fixen vara ungefär densamma på alla dessa plattformar.
Metod 1: Hitta en terminal för ssh
Medan du med stor sannolikhet redan arbetar från en terminal inser ssh förmodligen inte detta. Det kan fortfarande försöka leta efter en TTY-terminalemulator trots att du befinner dig i ett kommandotolkfönster. Försök att reproducera felet för att testa detta. Vi konfigurerade en virtuell maskin för att fungera som ett exempel och sprang ssh user@linuxtest.example ‘sudo /var/mail/startup.sh’ som ett test. Naturligtvis vill du ändra kommandot och ssh-raden till något som matchar det du försöker göra.
Du vill se till att du loggar in på servern som du trodde du var. Oavsett, kolla om du fortfarande får sudo: no tty present och inget askpass-program specificerat felmeddelande. Mer än troligt, om du fortfarande tar emot det kommer du att se det tre gånger och eventuellt till och med bli ombedd att ange ditt lösenord som du skulle ha om du kör sudo lokalt på Debian eller Ubuntu.
Försök att lägga till -t efter ssh för att rätta till syntaxfelet. Nio gånger av tio kommer detta att tvinga ssh att allokera en virtuell TTY till sig själv och låtsas att den råkar springa inuti en riktig terminal. Du behöver inte ändra något annat om ditt kommando. Lägg bara till alternativet -t efter bokstäverna ssh och behåll sedan värden och kommandot samma. Du vill också ha detta i åtanke om du någonsin måste köra ssh i den senare delen av ditt kommando.
Till exempel om du fick samma typ av fel när du kör ett kommando som har formaterats som ssh -t user@linuxtest.example ‘ssh user@linuxtest2.example’ du måste behålla alternativet -t efter första ssh för att förhindra det. Observera att om du senare ändrade det andra kommandot till att antingen producera eller konsumera data, skulle du inte vilja använda -t alls. Om du till exempel började köra katt istället för ett skript kan du dumpa -t eftersom du inte behöver tilldela en terminal för det.
Metod 2: Patching av visudofilen
Du kan också ha ett konfigurationsproblem som ger detta fel. Ändra visudo-filen genom att utfärda sudo visudo kommandot och kom ihåg att du aldrig vill redigera den här filen på något annat sätt. Du bör hitta en rad som innehåller ALL = NOPASSWD i den följt av de typer av kommandon som du inte behöver ange administratörens lösenord för att köra.
Varje enskilt kommando måste avslutas med ett kommatecken förutom det sista på raden. Således om du hade något som läste som / sbin / poweroff / sbin / start / sbin / stop kommer det att behandla alla som ett enda kommando och kasta felet åt dig. På samma sätt, om du saknar ett kommando som du försöker köra via ssh, får du också det här felet. Gör nödvändiga justeringar och spara filen innan du kontrollerar om felet fortfarande är reproducerbart.
Om du fortfarande har felet även efter att ha gjort det och startat om tjänsten, försök sedan följande kommando i bilden nedan och se till att linjen PermitTTY innehåller ordet ja efter det. Om det är den sista raden i din fil, se till att det finns en tom ny rad efteråt. GNU nano utför denna uppgift automatiskt som standard.
Du måste starta om alla relevanta tjänster innan du försöker återskapa felmeddelandet igen.
3 minuter läst
