我在两台服务器之间设置了密钥身份验证,并且无需密钥即可 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。
我怀疑其中一件事情正在发生:
- 远程帐户的 .bashrc 或 .bash_profile 中的某些内容导致 shell 提前退出。例如,它可能对会话没有 TTY 的事实很敏感。
scp
远程系统上的程序已损坏或出现故障。- 远程系统上的程序
scp
已被替换为其他无法像 scp 一样工作的程序。例如,有人可能用写得不好的 shell 脚本或“/bin/false”的副本替换了它。 - SSH 软件已配置为阻止人们运行 scp。您正在使用的密钥可能被设置为运行特定命令,或者远程服务器的文件中
authorized_keys
可能有指令。ForceCommand
sshd_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%的问题都解决了。