我在 Un*x 方面有 20 多年的经验，并且我一直在使用它scp。
scp通过 SSH 进行，因此我认为它与后者一样安全。现在，在我最近就职的公司，安全官说不scp应该使用它，因为它不安全且过时。sftp应该比它更受青睐（但也比 SSH 更受青睐......）
基于 scp 的基础设施，基于scp在专业社区以及我前公司的其他同事中的受欢迎程度和可信度，我并不立即同意这一点。我不想因为某些 CSO 的言论而改变主意。
- 这就是说，这里有一个主题吗？
- 突然是
scp黑羊吗？ - 难道仅仅是安全专家在更高领域的争论？
- 还是
scp只是好用而已？
答案1
有点“不安全”
它曾是scp -T在 OpenSSH 8.0 中添加之前有点“不安全”，但它仍然是使用时有点“不安全” scp -r。
就像其他答案所说的那样，声称 scp 不安全是因为客户端之前无法验证它是否收到了所请求的内容。 scp 无法验证的原因是因为该请求是使用在服务器环境（具有服务器状态）中运行的 shell 代码发出的。
例如，假设服务器的 shell 设置为带有扩展 glob 的 zsh，并且我将项目目录设置为 zsh 动态命名目录以便快速访问。如果我想从 Rails 项目获取文件富，我可以通过以下方式得到它：
scp server:~foo/config/database.yml .
我的服务器上的 zsh 扩展~foo为~/work-for/client/$client_name/foo.
如果我想获取服务器的 10 个最新的常规文件，我可以这样做：
scp server:'*(.oc[1,10])' .
如果服务器有普通的 bash，我可以这样做：
scp server:'$(ls -t | head -10)' .
如果我想获取内容中包含模式 foo 的文件，我可以这样做：
scp server:'$(grep -l foo *)' .
scp 客户端无法验证这些使用 shell 代码的请求。然而，令人担忧的是，它使恶意服务器能够响应：
scp -r server:foo/ ~
与覆盖.ssh/authorized_keys。在 的眼中scp，foo/服务器 shell 代码将评估谁知道什么。
进入scp -T：
-T禁用严格的文件名检查。默认情况下，当将文件从远程主机复制到本地目录时，scp 会检查接收到的文件名是否与命令行上请求的文件名匹配，以防止远程端发送意外或不需要的文件。由于不同操作系统和 shell 解释文件名通配符的方式存在差异，这些检查可能会导致所需文件被拒绝。此选项禁用这些检查，但代价是完全相信服务器不会发送意外的文件名。
总而言之，以前的默认行为scp已移至-T，现在默认行为是在不执行递归复制时使用提供的参数作为简单模式来检查接收到的内容。我相信它可以识别简单的通配符和转义符（看源码， 它用匹配(3)用于匹配，标志设置为 0)。换句话说，当您不希望利用其通过 shell 代码指定文件的独特功能时，它的行为更加可预测。
所以现在，如果你不使用-T并且不使用-r，覆盖类似内容的唯一方法.bashrc就是明确要求它。如果你想使用 shell 代码，你必须-T以信任服务器为代价来使用：
scp -T server:'*(.oc[1,10])' .
因此，现在您可以在简单的非递归情况下获得安全性，而无需完全放弃scp比其他实用程序（如sftp或 ）更有用的独特功能rsync。
能scp 可以被 sftp 取代吗？
sftp 无法用 shell 代码指定它想要的文件。它只接受实际的文件路径。这样就比较有限了。如果您只需要 scp 来实现简单的文件路径，那么可以。但是，如果您希望能够使用服务器端 shell 代码通过简单命令指定文件（尽管以必须信任您的服务器为代价），那么我认为您唯一的选择是scp.
为什么要引用“不安全”？
这是不安全的，但只有当您不相信服务器不会受到损害时。就我而言，也许对于大多数人来说，我们将 scp 与我们以其他方式完全信任的服务器一起使用。特别是，我用它从笔记本电脑登录到台式机，反之亦然。如果我们不能信任自己的设备，那么我们还能信任什么呢？这就是为什么我认为称其为不安全是夸张的。例如，这与我们所说的 telnet 不安全不同。
不过，我仍然很欣赏对 require 的更改-T。它是更安全。另外，对于那些不需要 启用的功能的人来说-T，使用 scp 相对于 sftp 或 rsync 确实没有太大优势。
答案2
我读它的方式是“视情况而定”。
但是，scp 客户端仅对返回的对象名称执行粗略验证（仅防止目录遍历攻击）。恶意 scp 服务器（或中间人攻击者）可以覆盖 scp 客户端目标目录中的任意文件。如果执行递归操作 (-r)，服务器也可以操作子目录（例如，覆盖 .ssh/authorized_keys 文件）。
因此，如果scp在您的场所（数据中心）的主机之间进行传输，则很可能（但不确定）无法执行 MITM 攻击。
但是，如果您通过万维网从客户/合作伙伴获取业务文件，您应该依赖sftp，或者更好，ftps. （至少，确保scp客户端和ssh服务器有合适的版本）
答案3
我想说，如果你认为 SSH 上可能存在 MITM，那么很多 Unix 命令就会变得不安全。恶意者sudo可能会窃取您的密码，恶意通信客户端可能会读取您的邮件/即时消息等。
至少可以说，在与受感染的服务器交谈时替换scp为会以某种方式纠正这种情况是非常乐观的。sftp无论对本地文件造成什么损害，scp也可以通过二进制文件、shell 脚本、Python 文件、Makefile 等来完成，流氓sftp会很乐意为您提供这些服务。
简而言之，如果你不注意 SSH 到哪些服务器，那么无论你使用哪种工具，你都有很高的风险被搞砸，而使用sftp而不是scp只会边际地更安全。
这并不是说切换到sftp是一个坏主意：如果它是完成手头任务的优质工具，那么您就有充分的理由进行切换，顺便说一句，这与安全性无关。
答案4
男人scp
scp 在网络上的主机之间复制文件。它使用 ssh(1) 进行数据传输，并使用与 ssh(1) 相同的身份验证并提供相同的安全性。与 rcp(1) 不同，如果身份验证需要密码或密码短语，scp 将要求输入密码或密码短语。
你问scp不安全吗？就像其他任何未正确设置和使用的东西一样，它也可能是这样。
中间人 (MITM) 漏洞，您知道第一次 ssh 到某处时会出现初始弹出窗口，您忽略该弹出窗口，然后单击“确定”...
服务器的主机密钥未缓存在注册表中。 您无法保证服务器就是您认为的计算机。 服务器的 ssh 指纹是 blablabla。
这不是 SSH（或 scp）的错。这是你没有正确使用协议的原因。
一旦你建立了 ssh 服务器，你的连接对象就是它应该连接的人，那么这就是一个简单的问题（在我看来）使用 SSH 协议 2 和 AES-256 密码。这是你的大部分安全保障；如果您不定制您的sshd_conf（和客户端 ssh_config）并将其保留为默认值，那么这就是您的责任。
这是 sshd_config 的一个例外，您可以考虑一下
Protocol 2
Ciphers aes256-ctr
MACs hmac-sha2-512,hmac-sha2-256
# MACs hmac-sha1
PermitRootLogin no
AuthorizedKeysFile .ssh/authorized_keys {set this up}
IgnoreRhosts yes
IgnoreUserKnownHosts yes
StrictModes yes
UsePAM yes
根据 CVE-2019-6111
scp 客户端仅对返回的对象名称执行粗略验证（仅防止目录遍历攻击）。恶意 scp 服务器（或中间人攻击者）可以覆盖 scp 客户端目标目录中的任意文件。如果执行递归操作 (-r)，服务器也可以操作子目录（例如，覆盖 .ssh/authorized_keys 文件）。
这是断章取义的。首先不要连接到恶意 ssh 服务器。不要因为有人利用协议设置 ssh 服务器来责怪 SSH覆盖 scp 客户端目标目录中的任意文件。 首先使用服务器/客户端密钥正确建立 SSH 连接，并且不存在 MITM 恶意服务器。
scp，即ssh，是安全的。说 scp 不安全本质上就是说不应该使用 ssh，因为 ssh 不安全，但事实并非如此。
SSH = 安全外壳
scp = 通过 SSH 进行安全复制
ftp = 文件传输协议
sftp = SSH FTP
ftps = 通过 TLS/SSL 的 ftp
scp 应该被 sftp 取代吗？
当您不介意服务器的主机密钥/指纹而只需单击“确定”时，问问自己如何使用 sftp（连接到您无法保证是谁的服务器）。
一旦SSH通信隧道正确地，在两点之间建立通信的语义，无论是安全复制还是文件传输协议，在这一点上都是微不足道的。 scp，即ssh，是安全的。说 scp 不安全本质上就是说不应该使用 ssh，因为 ssh 不安全。但事实并非如此。 如果我打电话给你，而你却导致我遇到不好的事情，那不是电话公司的错。
“scp 协议已经过时、不灵活且不易修复。我们建议使用更现代的协议，例如 sftp 和同步用于文件传输。”
pleeeasssee...rsync 本身不执行加密，并且您会遇到同样的问题，无法保证您连接到的人就是您认为的人。但在这个暗示中，rsync 获得通过了吗？请注意您从何处获取建议。