☰

SSH는 제대로 작동하지만 SCP 풀을 수행할 수 없습니다.

tag-icon • tag-icon linux ssh scp
SSH는 제대로 작동하지만 SCP 풀을 수행할 수 없습니다.

두 서버 간에 키 인증을 설정했으며 키 없이 SSH로 연결할 수 있습니다. 예를 들면 다음과 같습니다.

ssh backup@hostname

이것은 잘 작동하고 로그인됩니다. 하지만 SCP를 사용하여 파일을 추출하려고 하면 파일이 수신되지 않습니다.

대상 파일은 chmod 777문제 해결을 위해 해당 파일을 처리했지만 복사할 파일이 있음에도 불구하고 찾지 못하는 것 같습니다.

이것은 ip의 (난독화된) 출력입니다.

scp -vvv backup@hostname:/var/stuff/backups/*.tgz /data/backups/

검증부터 시작하세요.

debug1: Authentication succeeded (publickey).    
Authenticated to xxx.xxx.xxx.xxx ([xxx.xxx.xxx.xxx]:22).
debug2: fd 4 setting O_NONBLOCK    
debug2: fd 5 setting O_NONBLOCK    
debug2: fd 6 setting O_NONBLOCK    
debug1: channel 0: new [client-session]    
debug3: ssh_session2_open: channel_new: 0    
debug2: channel 0: send open    
debug1: Entering interactive session.    
debug2: callback start   
debug2: fd 3 setting TCP_NODELAY    
debug3: packet_set_tos: set IP_TOS 0x08    
debug2: client_session2_setup: id 0    
debug1: Sending environment.    
debug3: Ignored env XDG_SESSION_ID    
debug3: Ignored env TERM    
debug3: Ignored env SHELL    
debug3: Ignored env SSH_CLIENT    
debug3: Ignored env SSH_TTY    
debug3: Ignored env http_proxy    
debug3: Ignored env USER    
debug3: Ignored env LS_COLORS    
debug3: Ignored env MAIL    
debug3: Ignored env PATH   
debug3: Ignored env QT_QPA_PLATFORMTHEME    
debug3: Ignored env PWD    
debug1: Sending env LANG = en_AU.UTF-8    
debug2: channel 0: request env confirm 0    
debug3: Ignored env SHLVL    
debug3: Ignored env HOME    
debug3: Ignored env LANGUAGE    
debug3: Ignored env LOGNAME    
debug3: Ignored env SSH_CONNECTION    
debug3: Ignored env LESSOPEN    
debug3: Ignored env XDG_RUNTIME_DIR    
debug3: Ignored env LESSCLOSE    
debug3: Ignored env _    
debug3: Ignored env OLDPWD    
debug1: Sending command: scp -v -f /var/stuff/backups/*.tgz    
debug2: channel 0: request exec confirm 1    
debug2: callback done    
debug2: channel 0: open confirm rwindow 0 rmax 32768    
debug2: channel 0: rcvd adjust 131072    
debug2: channel_input_status_confirm: type 99 id 0    
debug2: exec request accepted on channel 0    
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0    
debug2: channel 0: rcvd eof    
debug2: channel 0: output open -> drain    
debug2: channel 0: obuf empty    
debug2: channel 0: close_write    
debug2: channel 0: output drain -> closed    
debug2: channel 0: rcvd close    
debug2: channel 0: close_read    
debug2: channel 0: input open -> closed    
debug3: channel 0: will not send data after close    
debug2: channel 0: almost dead    
debug2: channel 0: gc: notify user    
debug2: channel 0: gc: user detached    
debug2: channel 0: send close    
debug2: channel 0: is dead    
debug2: channel 0: garbage collecting    
debug1: channel 0: free: client-session, nchannels 1   
debug3: channel 0: status: The following connections are open:    
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)
debug1: fd 0 clearing O_NONBLOCK   
debug1: fd 1 clearing O_NONBLOCK    
debug1: fd 2 clearing O_NONBLOCK    
Transferred: sent 3736, received 2280 bytes, in 0.0 seconds    
Bytes per second: sent 764498.2, received 466556.7    
debug1: Exit status 1    
backup@ar-secubn03:/var/scripts$

답변1

이 시도:

scp -vvv 'backup@hostname:/var/stuff/backups/*.tgz' /data/backups/

그래도 문제가 해결되지 않으면 다음을 시도해 보세요.

scp -vvv 'backup@hostname:/var/stuff/backups/\*.tgz' /data/backups/

답변2

비슷한 문제가 있었는데 ssh명령을 실행할 수는 있었지만 scp명령은 실행할 수 없었습니다. Kenster의 훌륭한 디버깅 기술을 살펴봤지만 여전히 아무런 도움도 얻지 못했지만 매우 편리했습니다! 마침내 문제가 echo내 스크립트의 명령에 있다는 것을 알아냈습니다 .bashrc(다른 명령을 삽입한 후). echo스크립트의 모든 명령을 주석 처리한 후에는 scp명령을 성공적으로 실행할 수 있었습니다.

답변3

debug1: Sending command: scp -v -f /var/stuff/backups/*.tgz    
debug2: channel 0: request exec confirm 1    
debug2: callback done    
debug2: channel 0: open confirm rwindow 0 rmax 32768    
debug2: channel 0: rcvd adjust 131072    
debug2: channel_input_status_confirm: type 99 id 0    
debug2: exec request accepted on channel 0    
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
...
debug1: Exit status 1

이 줄은 로컬 scp 인스턴스가 scp원격 시스템에서 예상되는 명령을 실행하도록 요청했으며 원격 서버가 요청에 대한 응답으로 프로세스를 시작했음을 나타냅니다. 그러나 원격 프로세스는 상태 코드 1로 거의 즉시 종료되고 출력을 내보내지 않습니다.

원격 scp 인스턴스가 복사할 파일을 읽을 수 없거나 파일이 존재하지 않는 경우 오류 메시지가 표시됩니다. 원격 scp 프로그램을 찾을 수 없거나 실행할 수 없는 경우 종료 코드는 1 대신 126 또는 127이 됩니다.

나는 다음 중 하나가 일어나고 있다고 생각합니다.

  1. 원격 계정의 .bashrc 또는 .bash_profile에 있는 문제로 인해 셸이 일찍 종료되었습니다. 예를 들어 세션에 TTY가 없다는 사실에 민감할 수 있습니다.
  2. scp원격 시스템의 프로그램이 손상되었거나 제대로 작동하지 않습니다.
  3. 원격 시스템의 프로그램이 scpscp처럼 작동하지 않는 다른 프로그램으로 대체되었습니다. 예를 들어, 누군가가 이를 잘못 작성된 쉘 스크립트나 "/bin/false" 사본으로 대체했을 수 있습니다.
  4. SSH 소프트웨어는 사람들이 scp를 실행하지 못하도록 구성되었습니다. 사용 중인 키는 특정 명령을 실행하도록 설정되었거나 authorized_keys원격 서버의 파일에 지침이 있을 수 있습니다.ForceCommandsshd_config

이를 확인하는 가장 쉬운 방법은 원격 시스템 관리자에게 문의하거나 원격 시스템에 로그인하여 scp 실행 파일을 확인하는 것입니다. scp -h예를 들어 실행하면 scp 관련 사용법 메시지가 인쇄됩니다.

이 문제를 원격으로 해결해야 한다면 다음에 시도해 볼 방법은 다음과 같습니다.

$ ssh -T backup@hostname cat /etc/group

그러면 원격 시스템의 그룹 파일이 터미널에 기록됩니다. 이는 원격 시스템에서 임의의 명령을 실행할 수 있음을 증명합니다.

$ ssh -T backup@hostname scp -v -f /etc/group < /dev/zero

이는 세션의 원격 부분을 시뮬레이션합니다 scp. 원격 scp 프로그램이 실행 중이면 다음과 같은 출력이 표시됩니다.

C0644 674 group
root:x:0:
daemon:x:1:
[...]
devuser:x:1001:
Sending file modes: C0644 674 group
$

scp이 모든 것이 작동한다면 "/var/stuff/backups/*.tgz"에서는 실패하지만 "/etc/group"에서는 작동하는 이유에 대한 질문이 됩니다 . 이것을 실행하여 작동하는지 확인할 수 있습니다.

ssh -T backup@hostname 'scp -v -f /var/stuff/backups/*.tgz' < /dev/zero

그래도 실패할 경우 핵심 옵션은 원격 세션을 실행하도록 예약 strace하고 각 프로그램이 수행하는 작업을 정확히 확인하는 것입니다.

답변4

공간을 사용하지 않도록 백업 *.tgz를 변경하기 위해 첫 번째 백업 /*.tgz를 수행하는 것으로 생각됩니다. 어쩌면 99%의 문제가 해결될 수도 있습니다.

관련 정보