mindscribeals.com

No tty present og no askpass program spesifisert output line er en av de ssh feilmeldingene som egentlig ikke er så nyttige fordi det egentlig ikke kommer til poenget med hva som forårsaker problemet. Mer enn sannsynlig jobber du faktisk med en gyldig TTY av noe slag når du ser meldingen, og du har sannsynligvis håndtert å skrive inn sudo-passordet ditt over ssh helt fint. Du har mer enn sannsynlig å gjøre med en syntaksfeil, men meldingen tar ikke direkte opp dette.

Siden dette er et problem forbundet med selve ssh, vil du mer enn sannsynlig kunne reprodusere problemet på Linux, FreeBSD, macOS og Cygwins Unix-tjenester på Microsoft Windows. Heldigvis bør løsningen være stort sett den samme på alle disse plattformene.

Metode 1: Finne en terminal for ssh

Mens du mer enn sannsynlig allerede jobber fra en terminal, skjønner ssh sannsynligvis ikke dette. Det kan fortsatt forsøke å lete etter en TTY-terminalemulator til tross for at du er inne i et ledetekstvindu. Prøv å reprodusere feilen for å teste dette. Vi konfigurerte en virtuell maskin til å fungere som et eksempel og løp ssh [email protected] ‘sudo /var/mail/startup.sh’ som en test. Naturligvis vil du endre kommandoen og ssh-linjen til noe som samsvarer med det du prøver å gjøre.

Du vil forsikre deg om at du logger på serveren du trodde du var. Uansett, sjekk for å se om du fremdeles mottar sudo: no tty present og no askpass program spesifisert feilmelding. Mer enn sannsynlig, hvis du fremdeles mottar det, vil du se det tre ganger og muligens til og med bli bedt om å skrive inn passordet ditt slik du ville gjort hvis du kjører sudo lokalt på Debian eller Ubuntu.

Prøv å legge til -t etter ssh for å rette på syntaksfeilen. Ni ganger av ti vil dette tvinge ssh til å tildele en virtuell TTY til seg selv og late som om det tilfeldigvis kjører inne i en ekte terminal. Du trenger ikke endre noe annet ved kommandoen din. Bare legg til alternativet -t etter bokstavene ssh, og hold deretter verten og kommandoen den samme. Du vil også ha dette i bakhodet hvis du noen gang må kjøre ssh i siste del av kommandoen.

For eksempel hvis du fikk den samme typen feil når du kjørte en kommando som var formatert som ssh -t [email protected] ‘ssh [email protected]’ du må beholde alternativet -t etter første ssh for å forhindre det. Vær oppmerksom på at hvis du senere endret den andre kommandoen til å enten produsere eller konsumere data, vil du ikke bruke -t i det hele tatt. Hvis du for eksempel begynte å kjøre katt i stedet for et skript, kan du dumpe -t siden du ikke trenger å tildele en terminal for det.

Metode 2: Patching av visudo-filen

Du kan også ha et konfigurasjonsproblem som gir denne feilen. Endre visudo-filen ved å utstede sudo visudo kommandoen, og husk at du aldri vil redigere denne filen på annen måte. Du bør finne en linje som inneholder ALL = NOPASSWD, etterfulgt av de typer kommandoer du ikke trenger å oppgi administratorpassordet for å kjøre.

Hver enkelt kommando må ende med et komma bortsett fra den siste på linjen. Dermed hvis du hadde noe som leste som / sbin / poweroff / sbin / start / sbin / stop, vil det behandle disse alle som en enkelt kommando og kaste feilen mot deg. På samme måte, hvis du mangler en kommando du prøver å kjøre via ssh, får du også denne feilen. Gjør de nødvendige justeringene og lagre filen før du kontrollerer om feilen fremdeles er reproduserbar.

Skulle du fremdeles ha feilen selv etter at du har gjort det og startet tjenesten på nytt, kan du prøvefølgende kommando i bildet nedenfor og sørg for at PermitTTY-linjen inneholder ordet ja etter det. Hvis dette er den siste linjen i filen din, må du sørge for at det er en tom ny linje etterpå. GNU nano utfører denne oppgaven automatisk som standard.

Du må starte alle relevante tjenester på nytt før du prøver å reprodusere feilmeldingen igjen.