上传Windows EFS加密文件至Linux时保留元数据及VHDX脚本问询

为什么SCP传输后EFS属性丢失？ #

EFS加密本质依赖NTFS文件系统的扩展元数据（包含加密密钥相关的特殊数据流）来标记文件的加密状态。当你用OpenSSH的SCP在Windows和Linux间传输文件时，SCP只会传输文件的主数据流内容——而Linux的主流文件系统（比如ext4）完全不支持NTFS的扩展数据流，这些关键的EFS元数据会直接丢失。等你把文件从Linux传回Windows时，系统只能识别到普通ZIP的内容，找不到EFS加密的标记信息，自然无法识别为加密文件。

而U盘传输没问题，是因为如果U盘格式化为NTFS，传输过程会完整保留EFS的元数据，系统能正常识别加密属性。

针对SCP传输的修复方案 #

这里有几个适合集成到PowerShell脚本的无感知方案：

• 改用SMB共享传输：如果你的Linux服务器支持SMB（比如安装了Samba服务），可以在脚本中临时挂载Linux的SMB共享目录，用Copy-Item复制EFS加密文件——SMB协议会完整保留NTFS元数据，包括EFS属性。传输完成后自动卸载共享，全程用户无感知。
• 先解密再用跨平台加密传输：脚本中先临时解密EFS文件（用cipher /d命令），再用GPG这类跨平台加密工具加密文件，之后用SCP传输到Linux。取回文件时，先解密GPG包，再重新用EFS加密（cipher /e）。注意要确保解密后的临时文件在脚本执行完后彻底删除，避免数据泄露。
• 用VHDX封装EFS文件：这正好对应你关心的第二个问题，下面详细说明。

VHDX能否纳入无感知脚本？ #

完全可以！而且这是非常可靠的方案——VHDX是完整的磁盘镜像，内部的NTFS分区会完整保留所有EFS元数据。你可以在PowerShell脚本中自动化完成以下步骤，全程对用户无干扰：

1. 创建临时VHDX：用New-VHD创建一个足够容纳目标ZIP的小型动态扩展VHDX，路径放在用户临时目录里：

   $vhdPath = "$env:TEMP\temp_efs_store.vhdx"
   $fileSize = (Get-Item "your_encrypted.zip").Length
   New-VHD -Path $vhdPath -Dynamic -SizeBytes ($fileSize * 1.1)
   

2. 挂载并初始化VHDX：自动挂载镜像，初始化磁盘、格式化为NTFS并分配临时驱动器号：

   $vhdMount = Mount-VHD -Path $vhdPath -PassThru
   $disk = Initialize-Disk -Number $vhdMount.DiskNumber -PassThru
   $partition = New-Partition -DiskNumber $disk.Number -AssignDriveLetter -UseMaximumSize
   Format-Volume -DriveLetter $partition.DriveLetter -FileSystem NTFS -Confirm:$false
   

3. 复制EFS文件到VHDX：把加密ZIP复制到VHDX的NTFS分区，此时EFS元数据会完整保存在镜像内部的NTFS结构中：

   Copy-Item -Path "your_encrypted.zip" -Destination "$($partition.DriveLetter):\"
   

4. 卸载VHDX：安全卸载镜像，此时VHDX文件就是一个包含完整EFS文件的独立镜像：

   Dismount-VHD -Path $vhdPath
   

5. 传输与还原：用SCP把VHDX传到Linux服务器；需要取回时，下载回Windows后，脚本重新挂载镜像、复制出EFS文件，最后删除临时VHDX即可。

整个过程可以在后台执行，脚本能自动处理驱动器号选择、临时文件清理等细节，用户几乎不会察觉到操作。

内容的提问来源于stack exchange，提问作者Andrw