sz命令详解：SSH会话中用ZModem协议快速下载服务器文件

远程连着服务器排查问题的时候想从上面拿一个日志文件回本地这事有多常见多让人头疼一开始我也习惯性用scp但很快就遇到了麻烦本地这台电脑没有公网IP又没有和服务器互通的路由scp根本找不到回来的路。后来发现其实压根不用绕那么大一圈——在远程终端里敲一行sz 文件名弹窗就出现了文件直接落到你面前。这个命令救了我不止一次命值得好好讲讲。sz其实是lrzsz这个软件包提供的命令和rz是一对rz负责把本地文件上传到服务器sz负责把服务器上的文件推到本地。它基于ZModem协议最妙的是它就搭在你当前这根SSH会话里跑不需要额外开端口、不需要知道本机IP、不需要配什么服务端。只要你能正常连上服务器就能用它拿文件。这篇我把自己用sz的完整经验和各种坑梳理一遍从安装、参数、实战到问题排查都覆盖到新手看完能直接上手老手也可以对照看看有没有漏掉什么细节。1. sz到底是个什么工具1.1 为什么从服务器拿文件这种小事会卡住很多人先讲个我踩过的真实场景。有一次在客户现场排查服务异常服务器在一个专网里我只能通过一个跳板机登录上去。想把这个异常时刻的日志拷贝回本地分析结果发现本地电脑和跳板机之间不在一个网段scp传不了sftp服务没有对外开放我们连的完全是一个临时隧道。我当时急得想把日志直接复制到屏幕上。后来旁边一位同事看不下去敲了一句sz -y /var/log/app/error.log几秒钟后弹窗就出现了日志稳稳落进了本地的下载目录。这个经历给了我一个很重要的认知很多人想当然地认为传文件就必须靠scp/ftp/sftp但实际上只要你的SSH终端还开着sz是最后一道保底方案。它不依赖公网地址、不需要额外开放任何端口数据走的还是当前这条已经建立好的安全通道。这种特性让它在跳板机、堡垒机、内网隔离这些场景里特别吃香。1.2 sz与rz、lrzsz、ZModem之间的关系sz不是Linux内核自带的命令它来自一个叫lrzsz的软件包。这个包里最重要的两条命令就是rz和szrzreceive表示我当前这台服务器要接收从本地客户端发来的文件作用是把文件从你的电脑上传到服务器。szsend表示我当前这台服务器要发送文件到本地客户端作用是把服务器上的文件下载到你的电脑。这两条命令搭配使用的场景非常多。比如你在本地写好了一个部署脚本用rz上传上去跑完之后想拿回一份日志再用sz拉下来。整个过程完全不需要切换工具。ZModem则是它们底层的传输协议。这个协议最早被设计出来就是为了串口和调制解调器时代的高效文件传输后来被SSH终端软件集成支持。它有几个挺明显的优点传输时自带CRC校验出错会重传支持一批文件连续传输可以通过转义机制适应不可靠信道。几十年过去了这套协议依然又稳又轻这也是sz至今没有被淘汰的重要原因。1.3 sz的工作方式一次看似简单实则精巧的握手我刚开始用sz的时候心里一直有个疑问我是在终端里输入的命令它怎么就能不把文件内容哗啦啦地显示在屏幕上而是精准确认地交给终端软件去保存后来了解之后才明白sz运行时和本地终端软件之间有一次协议握手。大概过程是这样服务器端的sz命令发起一个ZModem的接收请求向客户端比如Xshell、SecureCRT这类软件发出一个特定的起始标识。如果这个软件支持ZModem它就会自动进入接收模式弹出保存窗口然后按照协议逐个接收数据包。整个传输过程中原始字节不会直接打印在你的终端屏幕上而是被客户端软件截获并写入磁盘。这也是为什么纯命令行终端比如Windows自带的cmd窗口、某些不含ZModem支持的SSH工具会卡住——因为没有人响应这个协议请求。好用之处就在于这个手写识别过程对用户几乎是透明的。你只需要记住在服务器上敲sz 文件然后等弹窗选个保存目录完事。2. 装好sz安装、终端配置与验证2.1 主流发行版的安装命令安装lrzsz非常简单大多数Linux发行版都有现成的软件包。Debian/Ubuntu系列sudo apt update sudo apt install -y lrzszCentOS/RHEL系列sudo yum install -y lrzsz新一点的CentOS/RHEL版本用sudo dnf install -y lrzsz如果服务器没有root权限也没关系可以下载源码包手动编译安装但这种情况相对少见。大多数场景下只要你拥有sudo权限一行命令就搞定了。安装完成后可以确认一下命令是否就位which sz sz -h我自己的习惯是先跑一下sz -h它会把所有支持的参数列出来这比查文档直观得多。只要能正常列出帮助信息说明安装没问题。2.2 装好了却不能用才是最常见的坑很多人装完lrzsz兴冲冲地敲了一条sz file.txt然后发现终端跟死了一样光标闪半天没反应。这里要重点提醒sz能不能用其实取决于你本地用的终端软件是否支持ZModem协议而不是服务器端装没装好。我实测过下面这几类终端软件是支持的Xshell默认支持传输时会弹出接收/发送文件的对话框用起来很顺手。SecureCRT支持需要在会话选项里确认开启了ZModem还可以自定义本地接收目录。MobaXterm支持自带文件传输按钮和sz/rz配合很丝滑。FinalShell内置了rz/zmodem支持很多运维朋友在用。不支持的也很明显Windows自带的PowerShell或cmd窗口。纯Putty除非配合配套工具否则本身不带ZModem。macOS自带的Terminal直接ssh也不支持。如果你平时用的是这些不支持的终端那么服务器上sz装得再完美也没用敲下去自然就卡着不动。解决办法很简单换一个支持ZModem的终端软件登录再敲sz试试。2.3 三分钟确认环境可用分享一个我每次都会用的验证流程。在一台装好lrzsz的服务器上先随便生成一个测试文件echo sz test content /tmp/sz_test.txt sz -y /tmp/sz_test.txt如果终端软件弹出保存窗口保存之后查看内容能看到上面那行字就说明整条链路——服务器lrzsz、SSH连接、本地终端协议支持——全部打通了。这样后面正式传文件才不会被为什么卡住这种问题干扰判断。3. sz命令参数详解常用选项与背后的取舍3.1 最基础用法sz file最基础的用法就是sz 文件路径。比如sz /var/log/nginx/access.log命令执行后本地终端会弹出一个文件保存对话框选好位置文件就传过来了。默认情况下如果本地已经有同名文件终端软件通常会问你是覆盖还是忽略不同软件交互方式不一样。这里有个细节sz支持同时传多个文件直接把文件名罗列在后面就行sz /var/log/nginx/access.log /var/log/nginx/error.log /tmp/a.txt传多个文件时ZModem协议会按顺序一个一个来终端软件一般会在一个对话框里批量接收或者逐个提示。我建议如果你要传的文件比较多、且都在同一个目录下先cd到那个目录再用相对路径传命令看起来更干净也不容易拼错绝对路径。3.2 参数对比表与逐个说明sz的命令参数不算多但有几个在实际工作中很有价值。我整理了一个常用参数表参数作用我常用的场景-y同名文件自动覆盖不再提问批量传输、脚本里自动执行-b强制二进制模式传输压缩包、可执行文件、图片等-aASCII模式传输纯文本日志会把换行符做转换-e转义所有控制字符网络不稳定、卡片式连接时更稳-k跳过本地已经存在的同名文件批量传文件时不想覆盖已有文件-q安静模式减少提示输出传文件时不想看一堆状态信息-v详细输出模式排查问题时看传输过程-d传输完成后删除服务器上的源文件清理临时文件时很实用-E接收端重命名文件避免覆盖文件已经存在于本地且不想覆盖-h查看帮助任何时候需要查参数这里需要特别强调一下-y和-k的区别。-y是本地只要有同名文件就直接覆盖适合你明确知道就是要用最新文件替换本地旧文件的情况。-k恰恰相反是本地只要已有同名文件就自动跳过适合你只是想补齐缺失文件、不想动已有文件的情况。两个命令都用过之后我建议你在不确定的时候宁可先用-k多传一次也不至于弄丢本地已有的东西。-d这个参数很多人可能没注意过。它的效果是文件传输成功后服务器端的源文件会被删掉。有一次我在服务器上打包了一个临时目录准备拉到本地后清掉服务器上的压缩包直接把-d加上省了一条rm命令。不过使用前要非常确定文件确实传成功了毕竟删除操作不可逆。3.3 参数组合实例一条带参命令的完整解读再分享一条我平时用得最多的命令sz -bye /var/log/nginx/access.log拆开看-b表示二进制传输不管这是什么类型的文件都原样发-y表示本地已有同名文件就直接覆盖不用弹窗问我-e表示对传输内容做转义提高在长连接、弱网环境下的成功率。三者合在一起基本就是快速、省事、尽量稳的组合。为什么不建议每次都手动敲这三个参数因为确实比较容易记混。我自己更常用的方式是在Shell里配置一个别名比如alias szbsz -bye之后想传文件就敲szb 文件名既省事又不容易漏参数。这种小技巧用顺了会相当顺手。还要提醒一点-a和-b不要混着用。-a适合纯文本它会对换行符做处理如果用它传二进制文件文件内容很有可能会被改坏。反过来-b传纯文本也能用只是本地保存的换行符样式可能和你预期的不同。所以通用原则是只要是压缩包、可执行文件、图片、视频一律用-b。4. 实战案例从日志下载到批量打包4.1 案例一把单个日志文件拉回本地先说最常见的场景服务器上某个应用日志已经好几百兆了我想把它拉到本地仔细搜。常规做法是分两步走。第一步先看看文件在哪、有多大ls -lh /var/log/myapp/app.log第二步直接传cd /var/log/myapp sz -bye app.log终端弹出保存窗口后选一个本地目录比如D:\logs文件就会开始传。传完以后我看一眼本地文件大小和服务器上对比一致就说明传输完整。为什么先cd到日志目录再传因为sz支持相对路径这样命令更简洁而且可以避免不小心拼错一长串绝对路径的问题。4.2 案例二整个目录传输前先打包很多人第一次用sz传目录会问sz能直接传文件夹吗答案是不能。sz只传文件不传目录结构。所以如果需要把一个目录完整搬回本地正确做法是先打包再传。我跑过一次模拟项目X的配置备份迁移整个目录几十个小文件直接逐个传太啰嗦。我的操作是cd /opt/myapp tar czf myapp_backup.tar.gz config/ scripts/ static/ ls -lh myapp_backup.tar.gz sz -bye myapp_backup.tar.gz传完之后在本地解压tar xzf myapp_backup.tar.gz这样目录结构、文件权限都保留下来了。打包这一步还能顺便做一下压缩几十兆的文件压到几兆传输时间明显缩短。我建议打包的时候尽量在目标目录的父目录里操作这样生成的压缩包里不会带一串无用的绝对路径本地解压时也更干净。4.3 案例三批量文件传输与自动覆盖还有一种很常见的情况服务器上有一个目录里存着最近几天的业务报表文件名有规律比如report_20250101.csv、report_20250102.csv。我想把这几个文件一起传到本地。先看一下目录内容确认文件名ls /data/reports/然后一次性传cd /data/reports sz -bye report_20250101.csv report_20250102.csv report_20250103.csv终端会依次接收三个文件。加了-y的好处是如果本地之前已经存过同名文件不会再弹窗反复问直接覆盖整个流程非常连贯。如果某天你只是想把缺失的报表补上已经下载过的不想再重复拉一遍这时候把-y换成-k更合适本地已有的会跳过只传缺失的。4.4 案例四全流程梳理最后分享一个把sz放进完整工作流的例子。某次需要从线上服务器提取一批数据处理结果过程是这样的先进入结果目录查看文件大小和数量cd /data/output du -sh * | sort -h发现结果文件有7个总计约120MB。因为数据结果比较大我决定先打包再传tar czf result_all.tar.gz result_*.csv sz -bye result_all.tar.gz传到本地后先做一下校验确认文件没缺没坏ls -l result_all.tar.gz tar tzf result_all.tar.gz | head再解压使用。这个过程看起来平平无奇但我实际体验下来非常省心尤其是不用等scp去建连接也不用担心端口不通的问题整个流程一气呵成。5. 常见问题与排查技巧实录5.1 sz敲下去没反应、终端卡住这是我被问过最多的问题也是我最初自己卡住过的坑。原因我在前面已经讲过了本地终端软件不支持ZModem协议。排查顺序是这样你先确认sz命令本身没问题——直接看命令是否存在于系统里which sz如果命令存在但你敲完sz 文件名之后终端没有任何反馈试试按CtrlC取消然后检查本地终端是不是Xshell、SecureCRT、MobaXterm等支持ZModem的软件。如果是纯命令行SSH客户端比如用Windows Terminal直接ssh、或者Putty那基本可以确定就是不支持ZModem。解决方式很粗暴换一个终端软件重连一下再敲一次。还有一种情况比较隐蔽——终端软件支持ZModem但相关设置被关掉了。SecureCRT里需要确认会话选项中有没有启用ZModemXshell里可以看看协议过滤器设置。一般默认都是开着的但如果你之前改过配置确实可能被关掉。5.2 文件传下来打不开、内容变乱码乱码分两种情况文件名乱码和文件内容乱码。文件名乱码通常是编码不一致引起的。服务器上的文件名是UTF-8编码的中文传到Windows本地后如果终端软件不支持或者配置不对显示出来就是一堆乱码。这个我试过内容本身一般没有问题纯粹是显示层的问题。解决办法是要么改文件名成英文再传要么在终端软件的编码设置里统一调整。文件内容乱码或者文件直接打不开最常见的原因就是传输模式选错了。如果你用了-a传二进制文件比如zip包、可执行程序传输过程中换行符被转换了文件结构也就破坏了。解决方式就是老老实实用-b二进制模式重新传一次。另外一个可能的坑是传输过程中网络异常导致文件不完整这时需要重新传或者用-v打开详细输出看看有没有报错。5.3 传了一半断了怎么办ZModem协议本身有CRC校验和错误重传机制但在网络抖动特别厉害的环境下传输中断仍然可能发生。我遇到这种情况的处理方式很务实如果传的是大文件先想清楚能不能拆小再传或者先压缩再传把传输时长降下来中断概率自然就小了。如果文件已经传到一半断了本地通常只会留下一个不完整的文件这时候我一般直接删掉本地这个残次品重新传一遍完整的。因为ZModem虽然理论上支持续传但终端软件的支持程度参差不齐与其在续传配置上折腾不如重传一遍来得稳。另外长连接如果经常断建议先检查SSH连接本身是否稳定。我实际用过-e参数后在不太稳定的链路上传输成功率确实高了一些原理是它会转义控制字符避免一些误触发。5.4 文件保存到哪里去了找文件的痛点很多人第一次用sz成功弹窗保存后第二次就找不到文件存哪里了。这是因为终端软件的默认保存目录各不相同Xshell一般会弹窗让你选择SecureCRT可以在全局设置里指定ZModem接收文件目录MobaXterm通常会在会话设定里指定下载目录。我的建议是用哪个终端软件就先把它的ZModem下载目录固定下来。比如我在SecureCRT里就把接收目录设置成固定的D:\downloads\zmodem以后不管在哪个会话里点接收文件都会稳稳地落进这个目录再也不会出现文件传哪里去了的尴尬。这个设置就在全局选项 → 传输/文件传输 → ZModem 相关的配置里不同版本位置略有差异。5.5 安全顾虑sz传输是不是明文有过一个同学问过我sz传文件是不是像老式ftp那样明文裸奔中间会不会被人截获这个问题要分两层看。sz本身跑在你当前已经建立的SSH连接里只要你的SSH是加密的那么ZModem传输的数据也是通过这个加密通道走的并不会像ftp那样以明文形式暴露在网络上。从我实际使用经历来说sz传文件的安全性取决于你的SSH会话安全性。比起ftp它要好得多。但要注意另一个安全细节如果你通过一台不安全的跳板机在使用sz文件内容会以明文形式出现在跳板机所在环境里因为sz是在服务器侧发起协议交互的。所以涉及敏感数据时不要只依赖sz是否加密还要考虑你的登录链路是否全程可信。另外传输结束后记得检查一下命令历史不要留下明显的文件路径痕迹有些服务器被人翻history也是麻烦事。6. sz与scp、ftp、sftp的选型思考6.1 一张表看完区别用了这么久我自己的体会是sz不是万能的它只是众多文件传输工具里的一把好手。为了帮大家做一个更明智的选型我把自己常用的几个方式放在一起对比工具依赖条件方向突出优点明显短板sz/rzSSH会话 终端支持ZModem服务器 ↔ 本机免开端口交互自然协议校验强不适合脚本化海量传输依赖终端软件scpSSH服务端支持服务器 ↔ 本机/服务器命令简单自动化友好需要一条可直达的网络路径sftpSSH服务端支持服务器 ↔ 本机/服务器可浏览目录适合交互操作依赖SSH子系统支持rsync两端安装rsync本机 ↔ 服务器增量传输、断点续传、同步目录配置稍微复杂需要路径可达ftp/tftp专门的FTP服务服务器 ↔ 本机老设备支持多明文传输端口多安全性差我平时选型的逻辑是这样的如果是临时拉一个文件下来用sz最顺手如果是要做一个自动化的同步任务rsync是第一选择如果只是想偶尔看看服务器上有哪些文件再决定拿哪个sftp浏览目录比sz盲猜文件名舒服得多。6.2 什么时候我应该用sz什么时候别用sz适合用sz的场景我总结下来有四个SSH已经连接上了但网络路径不是很直接比如通过跳板机登录scp根本通不了sz是保底方案。文件量不大就是几十上百MB以内sz交互式传一下很轻快。目标设备是网络设备、嵌入式系统不支持sftp子系统但装了lrzsz。你要反复在服务器和本地之间传配置、传日志sz 终端软件弹窗的模式效率很高。不适合用sz的场景也有几个要传几个GB的大文件而且网络很一般建议用rsync支持断点续传。要把一个目录树原封不动搬过去tarscp或rsync更靠谱sz没法直接带目录结构。自动化脚本里需要稳定传输sz有时候会弹窗等人操作不如scp/rsync安静执行。本地终端不支持ZModem那就别在sz上较劲直接用scp或其他工具。为什么我强调要基于场景选型因为有一次我为了省事在自动化脚本里用了sz结果每次都要在终端弹个窗出来手工确认脚本等于白写。后来改成rsync整晚无人值守跑完体验天差地别。工具本身没有绝对的好坏用对场景才顺手。最后再补一个小技巧如果你偶尔需要在服务器上快速发个文件给别人又不想暴露服务器路径可以考虑把文件放到一个临时目录改个简单文件名用sz下发之后顺手加上-d参数删掉源文件。这样既方便了协作也减少文件散落在服务器上的风险。这套玩法我用了很长一段时间一直很顺手。