no tty 존재 및 no askpass 프로그램 지정 출력 라인은 문제를 일으키는 요점에 실제로 도달하지 않기 때문에 실제로 그다지 도움이 되지 않는 ssh 오류 메시지 중 하나입니다. 아마도 메시지를 볼 때 실제로 일종의 유효한 TTY로 작업하고 있고 ssh를 통해 sudo 암호를 입력하는 것을 잘 처리했을 가능성이 큽니다. 구문 오류를 처리할 가능성이 높지만 메시지는 이 사실을 직접적으로 다루지 않습니다.
이것은 ssh 자체와 관련된 문제이기 때문에 Microsoft Windows의 Linux, FreeBSD, macOS 및 Cygwin의 Unix 서비스에서 문제를 재현할 수 있을 가능성이 큽니다. 다행히 수정 사항은 이러한 모든 플랫폼에서 거의 동일해야 합니다.
방법 1:ssh용 터미널 찾기
이미 터미널에서 작업하고 있을 가능성이 높지만 ssh는 이를 인식하지 못할 수 있습니다. 명령 프롬프트 창 안에 있음에도 불구하고 여전히 TTY 터미널 에뮬레이터를 찾으려고 할 수 있습니다. 이를 테스트하려면 오류를 재현해 보십시오. 가상 머신을 예제로 구성하고 ssh [email protected] 'sudo /var/mail/startup.sh'를 실행했습니다. 테스트로. 당연히 명령 및 ssh 행을 수행하려는 작업과 일치하는 것으로 변경하고 싶을 것입니다.
당신은 당신이 생각했던 서버에 로그인하고 있는지 확인하고 싶을 것입니다. 그럼에도 불구하고 sudo:no tty present 및 no askpass program specified 오류 메시지가 계속 표시되는지 확인하세요. 아마도 여전히 수신 중인 경우 세 번 표시되고 Debian 또는 Ubuntu에서 로컬로 sudo를 실행할 때와 같은 방식으로 비밀번호를 입력하라는 메시지가 표시될 수도 있습니다.
구문 오류를 수정하려면 ssh 다음에 -t를 추가하십시오. 10번 중 9번은 ssh가 가상 TTY를 자신에게 할당하도록 강제하고 실제 터미널 내부에서 실행되는 것처럼 가장합니다. 명령에 대해 다른 것을 변경할 필요는 없습니다. ssh 문자 뒤에 -t 옵션을 추가한 다음 호스트와 전달된 명령을 동일하게 유지하기만 하면 됩니다. 명령의 후반부에서 ssh를 실행해야 하는 경우에도 이 점을 염두에 두시기 바랍니다.
예를 들어 ssh -t [email protected] 'ssh [email protected]' 형식의 명령을 실행할 때 이와 같은 종류의 오류가 발생한 경우 이를 방지하려면 첫 번째 ssh 이후에 -t 옵션을 유지해야 합니다. 나중에 데이터를 생성하거나 소비하도록 두 번째 명령을 변경했다면 -t를 전혀 사용하고 싶지 않을 것입니다. 예를 들어 스크립트 대신 cat을 실행하기 시작했다면 터미널을 할당할 필요가 없기 때문에 -t를 덤프할 수 있습니다.
방법 2:visudo 파일 패치
이 오류를 생성하는 구성 문제가 있을 수도 있습니다. sudo visudo를 실행하여 visudo 파일 수정 명령을 수행하고 이 파일을 다른 방법으로 편집하고 싶지는 않을 것임을 명심하십시오. 실행하기 위해 관리자 암호를 입력할 필요가 없는 명령 유형이 뒤에 오는 ALL =NOPASSWD가 있는 줄을 찾아야 합니다.
각 개별 명령은 줄의 마지막 명령을 제외하고 쉼표로 끝나야 합니다. 따라서 /sbin/poweroff /sbin/start /sbin/stop과 같이 읽는 것이 있는 경우 이 모든 것을 단일 명령으로 처리하고 오류를 발생시킵니다. 마찬가지로 ssh를 통해 실행하려는 명령이 누락된 경우에도 이 오류가 발생합니다. 오류가 여전히 재현 가능한지 확인하기 전에 필요한 조정을 수행하고 파일을 저장하십시오.
이렇게 하고 서비스를 다시 시작한 후에도 오류가 계속 발생하면 아래 이미지의 다음 명령을 시도하세요. 그리고 PermitTTY 행 뒤에 yes라는 단어가 있는지 확인하십시오. 이것이 파일의 마지막 줄이면 뒤에 빈 줄 바꿈이 있는지 확인하십시오. GNU nano는 기본적으로 이 작업을 자동으로 수행합니다.
오류 메시지를 다시 재현하기 전에 관련 서비스를 다시 시작해야 합니다.