尽管 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 程序无法找到或不可执行,则退出代码将为 126 或 127,而不是 1。

我怀疑其中一件事情正在发生:

  1. 远程帐户的 .bashrc 或 .bash_profile 中的某些内容导致 shell 提前退出。例如,它可能对会话没有 TTY 的事实很敏感。
  2. scp远程系统上的程序已损坏或出现故障。
  3. 远程系统上的程序scp已被替换为其他无法像 scp 一样工作的程序。例如,有人可能用写得不好的 shell 脚本或“/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%的问题都解决了。

相关内容