SSH에는 별도의 stdin, stdout, stderr 및 tty가 있습니다.

Question

스크립트

저는 이 질문의 작성자이며 이것이 문제를 해결하는 스크립트를 작성하려는 시도입니다. 이 스크립트는 클라이언트 측에서 작동하도록 설계되었으며 ssh문제가 있는 명령을 대체합니다. 그것은실험적인. 나는 그것을 부른다 sshe. 스크립트는 다음과 같습니다.

#!/bin/sh -

# the name of the script
me="${0##*/}"

# error handling functions
scream() { printf '%s\n' >&2 "$1"; }
die()    { scream "$2"; exit "$1"; }

# initialization of variables
redir0=''
redir1=''
redir2=''
tty="/dev/$(ps -p "$$" -o tty=)"

# edge cases
[ "$tty" = '/dev/?' ] && { scream "$me: no tty detected, falling back to regular ssh"
   exec ssh "$@"; }
[ "$#" -lt 2 ] && die 1 "usage: $me [options] [user@]hostname command"

# see what needs to be redirected
exec 7>&1
if [ "$(<&0 tty 2>/dev/null)" != "$tty" ]; then redir0=y; fi
if [ "$(<&7 tty 2>/dev/null)" != "$tty" ]; then redir1=y; fi
if [ "$(<&2 tty 2>/dev/null)" != "$tty" ]; then redir2=y; fi
exec 7>&-

# edge case
[ "$redir0$redir1$redir2" ] || { scream "$me: no redirection detected, falling back to ssh -t"
   exec ssh -t "$@"; }

# command line parsing, extract two last arguments: ... host command
z="$#"
n="$z"
for arg do
   if [ "$n" -eq "$z" ]; then
      set --
   fi
   case "$n" in
      1) command="$arg"
   ;;
      2) host="$arg"
   ;;
      *)
      set -- "$@" "$arg"
   esac
   n="$(($n - 1))"
done

# prepare to clean on exit
trap 'status="$?"; rm -r "$tmpd" 2>/dev/null; trap - EXIT; exit "$status"' EXIT HUP INT QUIT PIPE TERM

# temporary directory and socket
tmpd="$(mktemp -d)"
[ "$?" -eq 0 ] || exit 1
sock="$tmpd/sock"

# main pipe: ssh master connection -> background cat
(
[ "$redir0" ] || exec 0</dev/null
# ssh master connection, it will report the remote PID of the remote shell via its stdout
ssh -M -S "$sock" "$@" -T "$host" '</dev/null echo "$$"; exec sleep 2147483647'
) | {

# read the remote PID
IFS= read -r rpid || exit 1

# background process to pass data
exec 6<&0
cat <&6 2>/dev/null &

# move original descriptors out of the way
exec </dev/tty >/dev/tty 6>&-

# prepare remote redirections
if [ "$redir0" ]; then redir0="<&6";  fi
if [ "$redir1" ]; then redir1=">&7";  fi
if [ "$redir2" ]; then redir2="2>&8"; fi

# ssh to run the command, with remote tty
ssh -S "$sock" -t "$host" "
 trap 'status=\"\$?\"; kill $rpid 2>/dev/null; trap - EXIT; exit \"\$status\"' EXIT HUP INT QUIT PIPE TERM
 exec 6</proc/$rpid/fd/0 7>/proc/$rpid/fd/1 8>/proc/$rpid/fd/2 9>/dev/tty $redir0 $redir1 $redir2 || exit 3;
 $command"
}

일반 면책 조항

이 스크립트는 다양한 상황에서 잘 작동합니다. 나아니요무작위로 실패한다는 의미입니다. 무작위로 실패하지 않습니다. 나아니요이는 특정 데이터를 처리할 수 없다는 의미입니다. 임의의 데이터를 처리합니다.

"작동하지 않는" 경우는 로컬 tty와의 상호 작용으로 인해 발생합니다. tty(임의의 이진 데이터 포함)가 포함되지 않은 채널을 통해 흐르는 데이터는 항상 괜찮습니다. 문제를 이해하고 피해야 할 사항을 알아보려면 이 답변의 나머지 부분, 특히 "장애물 및 경고" 섹션을 읽어보세요.
다음과 같은 명령:
```
<binary_input sshe user@server 'sudo tool' >binary_output 2>error.log
```
이 문제는 방지됩니다. 기술 요구 사항(아래 "요구 사항" 참조)을 충족한다면 제대로 작동할 것입니다.
스크립트는 실험적이며 trap종료 상태를 유지하고 종료 시 제정신(?) 방식으로 정리하기 위해 s 설정을 시도했습니다. 내가 성공했는지 잘 모르겠습니다.
스크립트는 결코 완벽하지 않습니다. 개념 증명이라고 생각하세요.

용법

sshe다음과 같이 사용하세요:

sshe … [user@]hostname command

즉 , …실행 파일이 이면 여기에 도 (또는 ) ssh을 배치할 필요가 없습니다 . 이 스크립트는 원격 측에서 tty를 사용한다고 가정합니다(그렇지 않으면 그냥 tty 사용 ). 스크립트-t-tt-Tssh예상하다로컬 stdin, stdout 및 stderr 중 최소한 하나는 로컬 tty에서 리디렉션되어야 합니다. ssh -t모든 것이 로컬 tty에 연결되어 있으면 스크립트가 대체됩니다.

중요한물건:

command서버에서 실행하려는 쉘 코드입니다. 그것~ 해야 하다은 단일 매개변수이며 마지막 매개변수입니다 sshe. 생략할 수 없습니다.
hostname아니면 user@hostname끝에서 두 번째 매개변수여야 합니다. 생략할 수 없습니다.

내부적으로 스크립트는 command앞에 일부 코드를 추가하는 방법을 알아야 합니다. [user@]hostname두 번 사용되었기 때문에 알아야 합니다 . 스크립트는 각각 마지막 인수와 끝에서 두 번째 인수만 선택하므로 위의 제한 사항이 적용됩니다.

단지 로 바꾸는 것만으로 모든 유효한 호출을 호출 ssh로 변환 할 수 있는 것은 아닙니다. sshe그러나 나는 코드를 실행하는 모든 유효한 호출(대화형 셸을 생성하는 것과 반대)이 유효한 명령으로 재배열될 수 있다고 믿습니다. 예:sshsshesshsshe

ssh user@server -p 1234 echo foo

다음과 같이 재정렬해야 합니다.

sshe -p 1234 user@server 'echo foo'

sshe(정말로 필요하지 않은 이상이것사례; 이는 올바른 구문의 예일 뿐입니다. script 를 사용한 경우 sshe user@server -p 1234 echo foo해당 스크립트는 이전처럼 인수를 구문 분석 하지 않으므로 echo서버 및 명령 역할을 합니다 .foossh

여기 몇 가지 예가 있어요.

요구 사항, 이식성 문제

현지 요구 사항( sshe작업 위치):

/dev/$(ps -p "$$" -o tty=)제어 단말의 "실명"으로 추정됩니다. 비교하다이 문제.
mktemp -d.
ssh이 스크립트는 마스터 및 슬레이브 연결을 지원 -M합니다 .-S

원격 요구 사항(서버에서):

SSH 서버는 마스터-슬레이브 연결을 처리할 수 있습니다.
/proc의사 파일 시스템.
/proc/nnnn/fd/N동일한 사용자에게 속한 다른 프로세스를 사용할 수 있습니다 .
POSIX 호환 엔클로저.
자동 시작 스크립트(비교echoSCP가 항목에 작동하지 않습니다.bashrc, sshe상황과 유사합니다).

테스트하는 동안 Kubuntu(18.04.5 LTS)의 다양한 Debian 또는 Debian 파생 서버에 성공적으로 연결했습니다. 광산 ssh과 sshdOpenSSH에서.

작업

sshessh( 또는 로 대체하기로 결정하지 않는 한 ssh -t) ssh두 번 실행합니다.

ssh -M … -T …이는 기본 연결이며 원격 측에 tty를 할당하지 않습니다. 그곳에서 실행되는 쉘 코드는 execstdout 및 s 를 통해 장기 실행(약 68년)에 sleepPID를 보고합니다 . 프로세스의 표준 파일 설명자는 다른 프로세스에서 사용됩니다.

마스터로부터 보고된 PID는 ssh에 의해 획득됩니다 read. 그 후, 마스터의 표준 출력은 이를 (로컬) 표준 출력으로 전달하기 위한 목적으로만 ssh백그라운드로 이동합니다 .catsshe
나중에 ssh … -t …원격 측에 tty를 할당하는 슬레이브 연결이 제공됩니다. 원격 PID가 마스터 연결에서 이미 알려진 후 원격 측에서 별도의 stdin, stdout, stderr(마스터 연결을 통해) 및 tty(슬레이브 연결을 통해)를 사용할 sshe수 있도록 제공되는 코드를 리디렉션을 설정합니다 . 슬레이브는 원시 stdin 또는 stdout을 사용하지 않고 로컬을 사용합니다 .commandsshsshsshsshe/dev/tty

아이디어는 비슷해요이 답변(이미 질문에 연결되어 있음) 그렇습니다. 연결된 답변의 코드는 추가 설명자를 제공하기 위해 ssh(암시적으로 ) 두 번 실행됩니다. ssh -T내 스크립트가 실행 ssh -T되고 ssh -t표준 설명자와 tty를 제공합니다. 그리고 마스터-슬레이브 기능을 사용하므로 ssh인증(예: 비밀번호 요청)을 수행합니다.

로컬 stdin, stdout 및 stderr이 로컬 tty가 아닌 경우 데이터 흐름 방향은 다음과 같습니다.

로컬 stdin은 master로 이동하며 ssh다른 로컬 프로세스는 스크립트의 stdin에서 읽지 않습니다. (원격으로) 읽어옴으로써 /proc/nnnn/fd/0원격 프로세스는 로컬 표준 입력에 액세스할 수 있습니다. 슬레이브 ssh연결은 원격 측의 셸로 미리 리디렉션되어 표준 입력 command으로 사용됩니다 ./proc/nnnn/fd/0
마찬가지로 원격 측의 쉘이 /proc/nnnn/fd/1표준 출력으로 사용됩니다. 무슨 일이 일어나든 지역 소유자가 나올 것입니다 ssh. 이는 마스터가 ssh실행 중인 (원격) 셸 코드에서 올바른 PID를 검색한 후입니다. PID가 소비되고 모든 후속 데이터는 read백그라운드를 통해 원래 표준 출력으로 전송됩니다.sshecat
마찬가지로 원격 측의 셸은 /proc/nnnn/fd/2stderr을 사용합니다. 이 스트림은 로컬 마스터에서 sshstderr로 직접 전송됩니다 sshe. 스크립트에 의해 생성된 일부 로컬 프로세스는 스크립트의 표준 오류를 표준 오류로 사용하므로 sshe … 2>error.log이렇게 하면 로그에 오류 메시지도 포함됩니다. 특히 기대됩니다 Shared connection to server closed.. 이는 ssh -T … 2>error.log로그가 원격 명령 및 자체에서 메시지를 수집하는 방법 과 유사합니다 ssh. sshe다른 stdout과 연관된 채널을 통해 원격 명령에서 stderr을 전달하는 변형을 만드는 것이 가능하다고 생각합니다. ssh이 경우 원격 stderr과 로컬 도구에서 생성된 진단 메시지를 구별할 수 있습니다. 하지만 스크립트는 그렇게 하지 않습니다.
로컬 tty는 마스터 ssh(비밀번호를 요청해야 하는 경우)에 사용한 다음 슬레이브에 사용할 수 있습니다 ssh. (솔직히 스크립트에서 사용하는 로컬 도구는 local 에 액세스할 수 있지만 /dev/tty사용하지 않습니다.) 슬레이브 장치는 표준 입력 및 표준 출력 ssh -t으로 사용됩니다 . /dev/tty이렇게 하면 /dev/tty다른 리디렉션(예: ssh -t리디렉션 없이 터미널에서 실행)에도 불구하고 로컬 및 원격으로 연결할 수 있습니다. 원격 프로세스에서 읽은 내용은 로컬 슬레이브가 로컬에서 읽은 내용을 /dev/tty가져옵니다 . 원격 프로세스에 의해 쓰기 작업을 수행하면 로컬 슬레이브가 로컬에서 쓰기 작업을 수행하게 됩니다 .ssh/dev/tty/dev/ttyssh/dev/tty

로컬 stdin, stdout 또는 stderr이 로컬 tty인 경우 해당 원격 측( command슬레이브에서 원격으로 실행 중 )은 리디렉션되지 않으며 원격 tty에 대한 연결은 유지됩니다. 어느 쪽이든 현지 터미널에 도착합니다. 요점은 원격 tty를 우회해서는 안 된다는 것입니다. 그 이유는 곧 분명해질 것입니다.ssh/proc/nnnn/fd/N

sshe반드시 작동할 필요가 없는 로컬 및 원격 리디렉션은 거의 없습니다 . 이것은 나의 다른 실험적인 것들 때문입니다. 나는 sshe내가 기억하는 것보다 단독에 더 중요한 경우를 대비해 추가 리디렉션을 유지하기로 결정했습니다 .

장애물과 고려사항

전체 개념은 생각보다 쉽지 않습니다. tty는 사용자가 입력하는 내용을 처리할 수 있습니다(예:번역 ^M하다^J) 및 인쇄될 내용(예: cat터미널에서 *nix 줄 끝으로 파일을 제출하면 각 줄 바꿈은 캐리지_리턴 + 줄 바꿈처럼 작동합니다). 옮기다stty -a많은 설정을 참조하세요.

이것이 임의의 바이너리 데이터를 처리할 때 tty가 필요하지 않은 이유입니다. 그리고 상호 작용할 때 정말 필요합니다.

프로세스는 필요에 맞게 tty를 구성할 수 있습니다. 바라보다날것의그리고요리.

ssh어떻게든 서버에 tty를 할당 하면 그곳의 프로세스는 이를 자신의 tty로 처리합니다. tty를 구성해야 하는 경우 서버에 표시되는 tty를 구성합니다. 로컬 tty를 직접 구성할 수 있는 방법은 없습니다 ssh. 모든(?) "쿠킹"은 원격 tty에서 수행되며 ssh로컬 tty는 방해하지 않도록 구성됩니다.

sshe이것이 궁극적으로 로컬 tty에 연결해야 하는 원격 설명자를 리디렉션할 때 원격 tty를 우회해서는 안 되는 이유입니다. 원격 tty가 우회되면 스트림을 "쿠킹"할 개체가 없습니다. stdin, stdout 또는 stderr을 sshe로컬 tty에 연결하면 해당 항목이 "쿠킹"되기를 원함을 나타냅니다. 이는 모든 표준 스트림이 로컬 tty에 의해 "쿠킹"되는 대화형 셸에서 실행하는 것과 sshe유사합니다 (이것은 로컬 터미널을 "원시" 모드로 설정하지 않는다는 점에 유의 하세요).ssh … commandsshssh -T

그러니 sshe분명히 "요리"하고 싶은 것을 "요리"하세요. 문제는 다음을 수행할 때 발생합니다.

sshe … command | whatever

데이터는 (예상대로) "쿠킹"되지 않고 원격에서 command로컬 로 흐르지만 출력은 로컬에서 "쿠킹"되지 않습니다. 로컬 tty는 "요리"되도록 재구성될 수 있지만 로컬 tty는 해당 tty로 인쇄되는 경우 "요리"해서는 안 됩니다(즉, 설정에 따라 "요리"될 수도 있고 그렇지 않을 수도 있는 원격 tty로 인쇄). .whateverssh … command | whateverwhateversshecommand

sshe문제를 해결하려고 하지 마십시오. 기본적으로 출력이 터미널이 아닌 다른 곳(예: 일반 파일 또는 블록 장치)에서 끝나는 상황을 지원하도록 설계되었습니다. 이 문제에서는 다음 코드가 더 좋습니다.

sshe … command | whatever >some_file

stderr는 whatever"요리"되지 않습니다. 예상되는 진단 메시지바라보다이상한. 파일(또는 "쿠킹"할 다른 로컬 tty)로 리디렉션할 수 있습니다.

입력 측에서는 상황이 더욱 악화됩니다. 다른 로컬 프로세스가 로컬 tty에서 데이터를 읽으려고 하면 원래 데이터를 읽을 뿐만 아니라 sshe입력을 위해 경쟁합니다. 이는 동일한 터미널에서 데이터를 읽는 두 프로세스의 일반적인 문제입니다.

sshe요약하자면: "원시" 출력을 허용할 수 없는 한 로컬 tty에서 인쇄 이외의 도구가 sshe로컬 tty에 인쇄하도록 허용하지 않도록 로컬 명령(파이프)을 작성하십시오 .

나는 sshe이진 데이터를 전달하거나 처리하는 능력을 개발했습니다. 내 경우에는 로컬 tty에서 데이터를 읽거나 쓸 필요가 거의 없습니다. 로컬 도구의 진단 메시지가 충분히 "정교"하지 않은 채로 살아갈 수 있습니다. 그 대가 sshe로 로컬처럼 리모컨을 사용할 수 있습니다 .sudo

예

읽거나 쓰려면 원격 블록 장치에 대한 액세스가 필요합니다 sudo.
- 읽다:
```
sshe user@server 'sudo cat /dev/sdx1' >local_file
# or
sshe user@server 'sudo pv  /dev/sdx1' >local_file
```
- 글쓰기:
```
<local_file sshe user@server 'sudo tee /dev/sdx1 >/dev/null'
```
  내 테스트에서 로컬은 pv로컬 tty가 "원시"라는 사실을 신경 쓰지 않는 것 같습니다. 또는 오히려 그것이 부과하는 구성이 sshe부과하는 구성과 모순되지 않으며 어떤 도구가 로컬 tty를 먼저 구성하는지는 중요하지 않습니다. 그래서 이것은 작동하는 것 같습니다 :
```
pv local_file | sshe user@server 'sudo tee /dev/sdx1 >/dev/null'
```
  설정이 pv중단 되면 sshe리모컨에 비밀번호를 제공하지 못할 수도 있습니다 sudo. 설정이 sshe방해를 pv받으면 pv터미널에 인쇄된 내용이 손상된 것처럼 보일 수 있습니다. 이러한 가정 하에서도 콘텐츠는 local_file원격으로 그대로 전송됩니다 /dev/sdx1.
로컬 sudo과 원격이 sudo함께 제공됩니다.

로컬 sudo에서 비밀번호를 묻는 경우 로컬 과 동시에 로컬 tty에서 읽기 때문에 좋은 생각이 아닙니다 sudo … | sshe … 'sudo …'. 완전 로컬은 잠금 메커니즘이 구현되어 두 로컬이 동시에 동일한 터미널과 상호 작용하지 않기 때문에 작동합니다 . 로컬과 원격이 혼합된 경우에는 작동하지 않습니다 .sshe … 'sudo …' | sudo …sudosshesudo … | sudo …sudosudosudo

당신의 지역을 바랍니다sudo 시간 초과 허용. 그렇다면 sudo -v미리 전화하여 (필요한 경우) 중단 없이 로컬 비밀번호를 제공한 후 다음을 파이프하십시오.
- 원격 장치에서 로컬 장치로 복사:
```
sudo -v   # input local password if needed
sshe user@server 'sudo cat /dev/sdx1' | sudo tee /dev/sdy1 >/dev/null
```
- 로컬 장치에서 원격 장치로 복사:
```
sudo -v   # input local password if needed
sudo cat /dev/sdy1 | sshe user@server 'sudo tee /dev/sdx1 >/dev/null'
```

질문이 요구한 것이 바로 그것입니다.

그리고 sudo:

<binary_input sshe user@server 'sudo tool' >binary_output 2>error.log

또는 더 일반적으로:

<binary_input sshe user@server 'requires-tty' >binary_output 2>error.log

최종 메모

나는 stdin에서 stdin으로, stdout에서 stdout으로, stderr에서 stderr로 터널링하는 것을 생각하곤 했습니다.그리고 /dev/tty하는 /dev/tty것은 사소한 일이다. 나는 왜 이 작업을 수행할 수 있는 ssh옵션( 과 유사)이 없는지 궁금했습니다 . -t이제 나는 그것이 그렇게 간단하지 않다는 것을 알고 있습니다.아마도아직 뭔가가 부족해요.

Answer 1

스크립트

저는 이 질문의 작성자이며 이것이 문제를 해결하는 스크립트를 작성하려는 시도입니다. 이 스크립트는 클라이언트 측에서 작동하도록 설계되었으며 ssh문제가 있는 명령을 대체합니다. 그것은실험적인. 나는 그것을 부른다 sshe. 스크립트는 다음과 같습니다.

#!/bin/sh -

# the name of the script
me="${0##*/}"

# error handling functions
scream() { printf '%s\n' >&2 "$1"; }
die()    { scream "$2"; exit "$1"; }

# initialization of variables
redir0=''
redir1=''
redir2=''
tty="/dev/$(ps -p "$$" -o tty=)"

# edge cases
[ "$tty" = '/dev/?' ] && { scream "$me: no tty detected, falling back to regular ssh"
   exec ssh "$@"; }
[ "$#" -lt 2 ] && die 1 "usage: $me [options] [user@]hostname command"

# see what needs to be redirected
exec 7>&1
if [ "$(<&0 tty 2>/dev/null)" != "$tty" ]; then redir0=y; fi
if [ "$(<&7 tty 2>/dev/null)" != "$tty" ]; then redir1=y; fi
if [ "$(<&2 tty 2>/dev/null)" != "$tty" ]; then redir2=y; fi
exec 7>&-

# edge case
[ "$redir0$redir1$redir2" ] || { scream "$me: no redirection detected, falling back to ssh -t"
   exec ssh -t "$@"; }

# command line parsing, extract two last arguments: ... host command
z="$#"
n="$z"
for arg do
   if [ "$n" -eq "$z" ]; then
      set --
   fi
   case "$n" in
      1) command="$arg"
   ;;
      2) host="$arg"
   ;;
      *)
      set -- "$@" "$arg"
   esac
   n="$(($n - 1))"
done

# prepare to clean on exit
trap 'status="$?"; rm -r "$tmpd" 2>/dev/null; trap - EXIT; exit "$status"' EXIT HUP INT QUIT PIPE TERM

# temporary directory and socket
tmpd="$(mktemp -d)"
[ "$?" -eq 0 ] || exit 1
sock="$tmpd/sock"

# main pipe: ssh master connection -> background cat
(
[ "$redir0" ] || exec 0</dev/null
# ssh master connection, it will report the remote PID of the remote shell via its stdout
ssh -M -S "$sock" "$@" -T "$host" '</dev/null echo "$$"; exec sleep 2147483647'
) | {

# read the remote PID
IFS= read -r rpid || exit 1

# background process to pass data
exec 6<&0
cat <&6 2>/dev/null &

# move original descriptors out of the way
exec </dev/tty >/dev/tty 6>&-

# prepare remote redirections
if [ "$redir0" ]; then redir0="<&6";  fi
if [ "$redir1" ]; then redir1=">&7";  fi
if [ "$redir2" ]; then redir2="2>&8"; fi

# ssh to run the command, with remote tty
ssh -S "$sock" -t "$host" "
 trap 'status=\"\$?\"; kill $rpid 2>/dev/null; trap - EXIT; exit \"\$status\"' EXIT HUP INT QUIT PIPE TERM
 exec 6</proc/$rpid/fd/0 7>/proc/$rpid/fd/1 8>/proc/$rpid/fd/2 9>/dev/tty $redir0 $redir1 $redir2 || exit 3;
 $command"
}

일반 면책 조항

이 스크립트는 다양한 상황에서 잘 작동합니다. 나아니요무작위로 실패한다는 의미입니다. 무작위로 실패하지 않습니다. 나아니요이는 특정 데이터를 처리할 수 없다는 의미입니다. 임의의 데이터를 처리합니다.

"작동하지 않는" 경우는 로컬 tty와의 상호 작용으로 인해 발생합니다. tty(임의의 이진 데이터 포함)가 포함되지 않은 채널을 통해 흐르는 데이터는 항상 괜찮습니다. 문제를 이해하고 피해야 할 사항을 알아보려면 이 답변의 나머지 부분, 특히 "장애물 및 경고" 섹션을 읽어보세요.
다음과 같은 명령:
```
<binary_input sshe user@server 'sudo tool' >binary_output 2>error.log
```
이 문제는 방지됩니다. 기술 요구 사항(아래 "요구 사항" 참조)을 충족한다면 제대로 작동할 것입니다.
스크립트는 실험적이며 trap종료 상태를 유지하고 종료 시 제정신(?) 방식으로 정리하기 위해 s 설정을 시도했습니다. 내가 성공했는지 잘 모르겠습니다.
스크립트는 결코 완벽하지 않습니다. 개념 증명이라고 생각하세요.

용법

sshe다음과 같이 사용하세요:

sshe … [user@]hostname command

즉 , …실행 파일이 이면 여기에 도 (또는 ) ssh을 배치할 필요가 없습니다 . 이 스크립트는 원격 측에서 tty를 사용한다고 가정합니다(그렇지 않으면 그냥 tty 사용 ). 스크립트-t-tt-Tssh예상하다로컬 stdin, stdout 및 stderr 중 최소한 하나는 로컬 tty에서 리디렉션되어야 합니다. ssh -t모든 것이 로컬 tty에 연결되어 있으면 스크립트가 대체됩니다.

중요한물건:

command서버에서 실행하려는 쉘 코드입니다. 그것~ 해야 하다은 단일 매개변수이며 마지막 매개변수입니다 sshe. 생략할 수 없습니다.
hostname아니면 user@hostname끝에서 두 번째 매개변수여야 합니다. 생략할 수 없습니다.

내부적으로 스크립트는 command앞에 일부 코드를 추가하는 방법을 알아야 합니다. [user@]hostname두 번 사용되었기 때문에 알아야 합니다 . 스크립트는 각각 마지막 인수와 끝에서 두 번째 인수만 선택하므로 위의 제한 사항이 적용됩니다.

단지 로 바꾸는 것만으로 모든 유효한 호출을 호출 ssh로 변환 할 수 있는 것은 아닙니다. sshe그러나 나는 코드를 실행하는 모든 유효한 호출(대화형 셸을 생성하는 것과 반대)이 유효한 명령으로 재배열될 수 있다고 믿습니다. 예:sshsshesshsshe

ssh user@server -p 1234 echo foo

다음과 같이 재정렬해야 합니다.

sshe -p 1234 user@server 'echo foo'

sshe(정말로 필요하지 않은 이상이것사례; 이는 올바른 구문의 예일 뿐입니다. script 를 사용한 경우 sshe user@server -p 1234 echo foo해당 스크립트는 이전처럼 인수를 구문 분석 하지 않으므로 echo서버 및 명령 역할을 합니다 .foossh

여기 몇 가지 예가 있어요.

요구 사항, 이식성 문제

현지 요구 사항( sshe작업 위치):

/dev/$(ps -p "$$" -o tty=)제어 단말의 "실명"으로 추정됩니다. 비교하다이 문제.
mktemp -d.
ssh이 스크립트는 마스터 및 슬레이브 연결을 지원 -M합니다 .-S

원격 요구 사항(서버에서):

SSH 서버는 마스터-슬레이브 연결을 처리할 수 있습니다.
/proc의사 파일 시스템.
/proc/nnnn/fd/N동일한 사용자에게 속한 다른 프로세스를 사용할 수 있습니다 .
POSIX 호환 엔클로저.
자동 시작 스크립트(비교echoSCP가 항목에 작동하지 않습니다.bashrc, sshe상황과 유사합니다).

테스트하는 동안 Kubuntu(18.04.5 LTS)의 다양한 Debian 또는 Debian 파생 서버에 성공적으로 연결했습니다. 광산 ssh과 sshdOpenSSH에서.

작업

sshessh( 또는 로 대체하기로 결정하지 않는 한 ssh -t) ssh두 번 실행합니다.

ssh -M … -T …이는 기본 연결이며 원격 측에 tty를 할당하지 않습니다. 그곳에서 실행되는 쉘 코드는 execstdout 및 s 를 통해 장기 실행(약 68년)에 sleepPID를 보고합니다 . 프로세스의 표준 파일 설명자는 다른 프로세스에서 사용됩니다.

마스터로부터 보고된 PID는 ssh에 의해 획득됩니다 read. 그 후, 마스터의 표준 출력은 이를 (로컬) 표준 출력으로 전달하기 위한 목적으로만 ssh백그라운드로 이동합니다 .catsshe
나중에 ssh … -t …원격 측에 tty를 할당하는 슬레이브 연결이 제공됩니다. 원격 PID가 마스터 연결에서 이미 알려진 후 원격 측에서 별도의 stdin, stdout, stderr(마스터 연결을 통해) 및 tty(슬레이브 연결을 통해)를 사용할 sshe수 있도록 제공되는 코드를 리디렉션을 설정합니다 . 슬레이브는 원시 stdin 또는 stdout을 사용하지 않고 로컬을 사용합니다 .commandsshsshsshsshe/dev/tty

아이디어는 비슷해요이 답변(이미 질문에 연결되어 있음) 그렇습니다. 연결된 답변의 코드는 추가 설명자를 제공하기 위해 ssh(암시적으로 ) 두 번 실행됩니다. ssh -T내 스크립트가 실행 ssh -T되고 ssh -t표준 설명자와 tty를 제공합니다. 그리고 마스터-슬레이브 기능을 사용하므로 ssh인증(예: 비밀번호 요청)을 수행합니다.

로컬 stdin, stdout 및 stderr이 로컬 tty가 아닌 경우 데이터 흐름 방향은 다음과 같습니다.

로컬 stdin은 master로 이동하며 ssh다른 로컬 프로세스는 스크립트의 stdin에서 읽지 않습니다. (원격으로) 읽어옴으로써 /proc/nnnn/fd/0원격 프로세스는 로컬 표준 입력에 액세스할 수 있습니다. 슬레이브 ssh연결은 원격 측의 셸로 미리 리디렉션되어 표준 입력 command으로 사용됩니다 ./proc/nnnn/fd/0
마찬가지로 원격 측의 쉘이 /proc/nnnn/fd/1표준 출력으로 사용됩니다. 무슨 일이 일어나든 지역 소유자가 나올 것입니다 ssh. 이는 마스터가 ssh실행 중인 (원격) 셸 코드에서 올바른 PID를 검색한 후입니다. PID가 소비되고 모든 후속 데이터는 read백그라운드를 통해 원래 표준 출력으로 전송됩니다.sshecat
마찬가지로 원격 측의 셸은 /proc/nnnn/fd/2stderr을 사용합니다. 이 스트림은 로컬 마스터에서 sshstderr로 직접 전송됩니다 sshe. 스크립트에 의해 생성된 일부 로컬 프로세스는 스크립트의 표준 오류를 표준 오류로 사용하므로 sshe … 2>error.log이렇게 하면 로그에 오류 메시지도 포함됩니다. 특히 기대됩니다 Shared connection to server closed.. 이는 ssh -T … 2>error.log로그가 원격 명령 및 자체에서 메시지를 수집하는 방법 과 유사합니다 ssh. sshe다른 stdout과 연관된 채널을 통해 원격 명령에서 stderr을 전달하는 변형을 만드는 것이 가능하다고 생각합니다. ssh이 경우 원격 stderr과 로컬 도구에서 생성된 진단 메시지를 구별할 수 있습니다. 하지만 스크립트는 그렇게 하지 않습니다.
로컬 tty는 마스터 ssh(비밀번호를 요청해야 하는 경우)에 사용한 다음 슬레이브에 사용할 수 있습니다 ssh. (솔직히 스크립트에서 사용하는 로컬 도구는 local 에 액세스할 수 있지만 /dev/tty사용하지 않습니다.) 슬레이브 장치는 표준 입력 및 표준 출력 ssh -t으로 사용됩니다 . /dev/tty이렇게 하면 /dev/tty다른 리디렉션(예: ssh -t리디렉션 없이 터미널에서 실행)에도 불구하고 로컬 및 원격으로 연결할 수 있습니다. 원격 프로세스에서 읽은 내용은 로컬 슬레이브가 로컬에서 읽은 내용을 /dev/tty가져옵니다 . 원격 프로세스에 의해 쓰기 작업을 수행하면 로컬 슬레이브가 로컬에서 쓰기 작업을 수행하게 됩니다 .ssh/dev/tty/dev/ttyssh/dev/tty

로컬 stdin, stdout 또는 stderr이 로컬 tty인 경우 해당 원격 측( command슬레이브에서 원격으로 실행 중 )은 리디렉션되지 않으며 원격 tty에 대한 연결은 유지됩니다. 어느 쪽이든 현지 터미널에 도착합니다. 요점은 원격 tty를 우회해서는 안 된다는 것입니다. 그 이유는 곧 분명해질 것입니다.ssh/proc/nnnn/fd/N

sshe반드시 작동할 필요가 없는 로컬 및 원격 리디렉션은 거의 없습니다 . 이것은 나의 다른 실험적인 것들 때문입니다. 나는 sshe내가 기억하는 것보다 단독에 더 중요한 경우를 대비해 추가 리디렉션을 유지하기로 결정했습니다 .

장애물과 고려사항

전체 개념은 생각보다 쉽지 않습니다. tty는 사용자가 입력하는 내용을 처리할 수 있습니다(예:번역 ^M하다^J) 및 인쇄될 내용(예: cat터미널에서 *nix 줄 끝으로 파일을 제출하면 각 줄 바꿈은 캐리지_리턴 + 줄 바꿈처럼 작동합니다). 옮기다stty -a많은 설정을 참조하세요.

이것이 임의의 바이너리 데이터를 처리할 때 tty가 필요하지 않은 이유입니다. 그리고 상호 작용할 때 정말 필요합니다.

프로세스는 필요에 맞게 tty를 구성할 수 있습니다. 바라보다날것의그리고요리.

ssh어떻게든 서버에 tty를 할당 하면 그곳의 프로세스는 이를 자신의 tty로 처리합니다. tty를 구성해야 하는 경우 서버에 표시되는 tty를 구성합니다. 로컬 tty를 직접 구성할 수 있는 방법은 없습니다 ssh. 모든(?) "쿠킹"은 원격 tty에서 수행되며 ssh로컬 tty는 방해하지 않도록 구성됩니다.

sshe이것이 궁극적으로 로컬 tty에 연결해야 하는 원격 설명자를 리디렉션할 때 원격 tty를 우회해서는 안 되는 이유입니다. 원격 tty가 우회되면 스트림을 "쿠킹"할 개체가 없습니다. stdin, stdout 또는 stderr을 sshe로컬 tty에 연결하면 해당 항목이 "쿠킹"되기를 원함을 나타냅니다. 이는 모든 표준 스트림이 로컬 tty에 의해 "쿠킹"되는 대화형 셸에서 실행하는 것과 sshe유사합니다 (이것은 로컬 터미널을 "원시" 모드로 설정하지 않는다는 점에 유의 하세요).ssh … commandsshssh -T

그러니 sshe분명히 "요리"하고 싶은 것을 "요리"하세요. 문제는 다음을 수행할 때 발생합니다.

sshe … command | whatever

데이터는 (예상대로) "쿠킹"되지 않고 원격에서 command로컬 로 흐르지만 출력은 로컬에서 "쿠킹"되지 않습니다. 로컬 tty는 "요리"되도록 재구성될 수 있지만 로컬 tty는 해당 tty로 인쇄되는 경우 "요리"해서는 안 됩니다(즉, 설정에 따라 "요리"될 수도 있고 그렇지 않을 수도 있는 원격 tty로 인쇄). .whateverssh … command | whateverwhateversshecommand

sshe문제를 해결하려고 하지 마십시오. 기본적으로 출력이 터미널이 아닌 다른 곳(예: 일반 파일 또는 블록 장치)에서 끝나는 상황을 지원하도록 설계되었습니다. 이 문제에서는 다음 코드가 더 좋습니다.

sshe … command | whatever >some_file

stderr는 whatever"요리"되지 않습니다. 예상되는 진단 메시지바라보다이상한. 파일(또는 "쿠킹"할 다른 로컬 tty)로 리디렉션할 수 있습니다.

입력 측에서는 상황이 더욱 악화됩니다. 다른 로컬 프로세스가 로컬 tty에서 데이터를 읽으려고 하면 원래 데이터를 읽을 뿐만 아니라 sshe입력을 위해 경쟁합니다. 이는 동일한 터미널에서 데이터를 읽는 두 프로세스의 일반적인 문제입니다.

sshe요약하자면: "원시" 출력을 허용할 수 없는 한 로컬 tty에서 인쇄 이외의 도구가 sshe로컬 tty에 인쇄하도록 허용하지 않도록 로컬 명령(파이프)을 작성하십시오 .

나는 sshe이진 데이터를 전달하거나 처리하는 능력을 개발했습니다. 내 경우에는 로컬 tty에서 데이터를 읽거나 쓸 필요가 거의 없습니다. 로컬 도구의 진단 메시지가 충분히 "정교"하지 않은 채로 살아갈 수 있습니다. 그 대가 sshe로 로컬처럼 리모컨을 사용할 수 있습니다 .sudo

예

읽거나 쓰려면 원격 블록 장치에 대한 액세스가 필요합니다 sudo.
- 읽다:
```
sshe user@server 'sudo cat /dev/sdx1' >local_file
# or
sshe user@server 'sudo pv  /dev/sdx1' >local_file
```
- 글쓰기:
```
<local_file sshe user@server 'sudo tee /dev/sdx1 >/dev/null'
```
  내 테스트에서 로컬은 pv로컬 tty가 "원시"라는 사실을 신경 쓰지 않는 것 같습니다. 또는 오히려 그것이 부과하는 구성이 sshe부과하는 구성과 모순되지 않으며 어떤 도구가 로컬 tty를 먼저 구성하는지는 중요하지 않습니다. 그래서 이것은 작동하는 것 같습니다 :
```
pv local_file | sshe user@server 'sudo tee /dev/sdx1 >/dev/null'
```
  설정이 pv중단 되면 sshe리모컨에 비밀번호를 제공하지 못할 수도 있습니다 sudo. 설정이 sshe방해를 pv받으면 pv터미널에 인쇄된 내용이 손상된 것처럼 보일 수 있습니다. 이러한 가정 하에서도 콘텐츠는 local_file원격으로 그대로 전송됩니다 /dev/sdx1.
로컬 sudo과 원격이 sudo함께 제공됩니다.

로컬 sudo에서 비밀번호를 묻는 경우 로컬 과 동시에 로컬 tty에서 읽기 때문에 좋은 생각이 아닙니다 sudo … | sshe … 'sudo …'. 완전 로컬은 잠금 메커니즘이 구현되어 두 로컬이 동시에 동일한 터미널과 상호 작용하지 않기 때문에 작동합니다 . 로컬과 원격이 혼합된 경우에는 작동하지 않습니다 .sshe … 'sudo …' | sudo …sudosshesudo … | sudo …sudosudosudo

당신의 지역을 바랍니다sudo 시간 초과 허용. 그렇다면 sudo -v미리 전화하여 (필요한 경우) 중단 없이 로컬 비밀번호를 제공한 후 다음을 파이프하십시오.
- 원격 장치에서 로컬 장치로 복사:
```
sudo -v   # input local password if needed
sshe user@server 'sudo cat /dev/sdx1' | sudo tee /dev/sdy1 >/dev/null
```
- 로컬 장치에서 원격 장치로 복사:
```
sudo -v   # input local password if needed
sudo cat /dev/sdy1 | sshe user@server 'sudo tee /dev/sdx1 >/dev/null'
```

질문이 요구한 것이 바로 그것입니다.

그리고 sudo:

<binary_input sshe user@server 'sudo tool' >binary_output 2>error.log

또는 더 일반적으로:

<binary_input sshe user@server 'requires-tty' >binary_output 2>error.log

최종 메모

나는 stdin에서 stdin으로, stdout에서 stdout으로, stderr에서 stderr로 터널링하는 것을 생각하곤 했습니다.그리고 /dev/tty하는 /dev/tty것은 사소한 일이다. 나는 왜 이 작업을 수행할 수 있는 ssh옵션( 과 유사)이 없는지 궁금했습니다 . -t이제 나는 그것이 그렇게 간단하지 않다는 것을 알고 있습니다.아마도아직 뭔가가 부족해요.

SSH에는 별도의 stdin, stdout, stderr 및 tty가 있습니다.

질문

연구: 왜

연구: 유효한 명령과의 비교

연구: 비슷한 질문

내 명확한 질문

답변1

스크립트

일반 면책 조항

용법

요구 사항, 이식성 문제

작업

장애물과 고려사항

예

최종 메모

관련 정보