为什么 SCP 可以工作而 SSH 可以工作?

为什么 SCP 可以工作而 SSH 可以工作?

如果我想通过 scp 发送一些内容到服务器:

scp file server:
                   _____  _____  _____

然后打印了三行,文件没有被复制。但是我可以通过 ssh 毫无问题地连接到服务器:

ssh server

如何使 scp 工作?

答案1

造成这种行为的一个可能原因是任何在服务器登录过程中打印出的消息。scp 依赖 ssh 在客户端和服务器之间提供完全透明的加密隧道。

检查服务器上的所有登录脚本,并尝试使用不同的用户。另一种识别错误来源的方法是在命令中使用 -v,以跟踪事务的进度,并查看失败的位置。如有必要,您可以使用最多 -vvv 来增加详细程度。检查 scp 的各种形式也可能很有启发性,如 InChargeOfIT 的帖子中所述。

scp 在底层使用 ssh 设置隧道,然后通过该隧道传输文件,并在远端使用 ssh 命令捕获文件。下面使用 tar 和 ssh 复制目录结构并保留所有权和创建时间,以说明这一点,命令如下:

tar czf - ./* | ssh [email protected] tar xzf - -C ~/saved_tree

发送过去,

ssh [email protected] "tar czf - ~/saved_tree" | tar xzvf - -C ./

把它拿回来。

答案2

检查目标用户.bashrc或等效文件。~/.bashrc用于非交互式登录。

如果有回声或输出任何内容的命令,它将破坏 SCP 协议。

答案3

您确定在 scp 命令中输入了有效路径吗?例如:

scp test.txt [email protected]

将会失败(事实上,它只会像您看到的那样打印出命令)。在这种情况下,您需要提供到远程服务器的有效路径。例如,scp test.txt [email protected]:~/

使用示例:

发送文件:

scp /path/to/local/file [email protected]:/path/to/remote/directory

获取文件:

scp [email protected]:/path/to/remote/file /path/to/local/directory

例子:

将文件从我的桌面发送到远程服务器上的主文件夹:

scp ~/Desktop/myfile.txt [email protected]:~/

请记住,这~是您的主目录的快捷方式...例如,/home/

发送文件到 webroot:

scp ~/Documents/working/index.html [email protected]:/var/www/index.html

在此示例中,用户 john_doe 需要对远程 /var/www 目录具有写权限。

答案4

如果您刚刚升级了客户端,您可能需要检查该-O选项是否相关。我刚刚升级了我的 Cygwin,scp 客户端默认改为使用较新的 SFTP 协议,这通常可以正常工作,但对于我们仍在运行的旧服务器之一,它却严重失败:

    -O    Use the legacy SCP protocol for file transfers instead of the SFTP
          protocol. Forcing the use of the SCP protocol may be necessary for 
          servers that do not implement SFTP, for backwards-compatibility for 
          particular filename wildcard patterns and for expanding paths with 
          a '~' prefix for older SFTP servers.

即使详细的调试也没有告诉我任何有用的信息,除了没有明显的错误,但添加-O到命令行可以解决问题:

scp -O [email protected]:file\* .

详细输出(如下)可能表明某处,但我对协议的了解还不足以解释数据包:)

    bash$ scp -vvvv [email protected]:file\* .
    Executing: program /usr/bin/ssh host host.net, user user, command sftp
    OpenSSH_9.0p1, OpenSSL 1.1.1p  21 Jun 2022
        ...
    debug1: Authentications that can continue: publickey,keyboard-interactive,password
    debug3: userauth_kbdint: disable: no info_req_seen
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup password
    debug3: remaining preferred:
    debug3: authmethod_is_enabled password
    debug1: Next authentication method: password
    [email protected]'s password:
    debug3: send packet: type 50
    debug2: we sent a password packet, wait for reply
    debug3: receive packet: type 52
    Authenticated to host.net ([192.168.1.32]:22) using "password".
    debug1: channel 0: new [client-session]
    debug3: ssh_session2_open: channel_new: 0
    debug2: channel 0: send open
    debug3: send packet: type 90
    debug1: Entering interactive session.
    debug1: pledge: filesystem
    debug3: receive packet: type 91
    debug2: channel_input_open_confirmation: channel 0: callback start
    debug2: fd 4 setting TCP_NODELAY
    debug3: set_sock_tos: set socket 4 IP_TOS 0x20
    debug2: client_session2_setup: id 0
    debug1: Sending subsystem: sftp
    debug2: channel 0: request subsystem confirm 1
    debug3: send packet: type 98
    debug2: channel_input_open_confirmation: channel 0: callback done
    debug2: channel 0: open confirm rwindow 0 rmax 16384
    debug2: channel 0: rcvd adjust 32768
    debug3: receive packet: type 99
    debug2: channel_input_status_confirm: type 99 id 0
    debug2: subsystem request accepted on channel 0
    debug3: receive packet: type 98
    debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
    debug3: receive packet: type 96
    debug2: channel 0: rcvd eof
    debug2: channel 0: output open -> drain
    debug2: channel 0: obuf empty
    debug2: chan_shutdown_write: channel 0: (i0 o1 sock -1 wfd 6 efd 7 [write])
    debug2: channel 0: output drain -> closed
    debug3: receive packet: type 97
    debug2: channel 0: rcvd close
    debug2: chan_shutdown_read: channel 0: (i0 o3 sock -1 wfd 5 efd 7 [write])
    scp: Connection closed
    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
    debug3: send packet: type 97
    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 e[write]/0 fd -1/-1/7 sock -1 cc -1 io 0x00/0x00)

    debug3: send packet: type 1
    Transferred: sent 1960, received 1512 bytes, in 0.2 seconds
    Bytes per second: sent 11090.3, received 8555.4
    debug1: Exit status 1
    bash$ 

相关内容