说个最近实际碰到的事。公司内网的一批 CentOS 7.9 机器被安全策略隔离在专网里没有外网权限也不允许随意插拔U盘。这批机器要做 SSH 公钥批量分发跑 ssh-copy-id 时每台机器都要手动输密码验证几十台下来手都快废了。这时候我第一个想到的就是 sshpass一个专门用来给 SSH 非交互式登录提供密码的工具。但麻烦点在于机器上一台都没装而且没有外网yum install 直接卡死在仓库连接上。这就是典型的 CentOS 离线安装场景核心需求其实不复杂难的是把安装包和依赖一起搬运进去。下面我把这类隔离网络环境下反复验证过的离线安装方法完整梳理一遍。包括 RPM 包方案、源码编译方案以及装完以后怎么快速验证、怎么在批量运维脚本里正确使用。不管目标是 CentOS 7.9 还是 CentOS 8/9只要系统架构一致下面的方法基本都能直接套用。正在做内网运维、堡垒机前置部署或者批量主机初始化的同学可以直接照着操作。1. sshpass解决什么问题以及离线安装为什么会有坑1.1 先搞懂sshpass的定位sshpass 的作用非常直白给 OpenSSH 的非交互式调用提供密码输入通道。平时我们执行 ssh userhost系统会从终端读取密码这个过程没法直接在一条命令里预先输入。而 sshpass 通过伪终端或环境变量的方式把密码“喂”给 ssh 进程从而实现一条命令完成带密码的 SSH/SCP 登录特别适合在脚本里批量操作。最常见的几个用法sshpass -p password ssh userhostsshpass -p password scp file userhost:/path/sshpass -p password ssh-copy-id userhost其中第三个是我用得最多的场景。ssh-copy-id 本身需要交互式输入密码配合 sshpass 后就能在批量初始化服务器时把公钥一次性推过去。第一次接触这个工具的人可能会问为什么不直接用 expectexpect 也做得到但要写 spawn/expect/send 的交互逻辑脚本冗长不说调试也麻烦。sshpass 的存在就是把“给 ssh 进程喂密码”这件事专门抽象出来做成了一个小而精的命令行工具。1.2 离线安装的坑点“离线安装”这四个字真正操作起来卡点通常在两个地方。第一没有 yum 源。在线环境下 yum install sshpass 一行命令搞定顶多等几秒下载。内网环境下yum 仓库地址不可达dnf/yum 会长时间超时甚至直接报错。报错信息看着吓人其实本质就是“找不到仓库”。第二依赖链不透明。很多人以为下载一个 rpm 包拷过去 rpm -ivh 就行结果发现机器上缺某个依赖库安装直接失败。sshpass 本身依赖很轻但在不同的 CentOS 大版本上镜像源里的 rpm 包版本和依赖声明并不完全一样得提前看清楚。所以离线安装的本质是两件事把“安装包”准备好把“依赖关系”前置解决掉。后面讲到的几种方案本质上都是围绕这两件事展开的。另外还要注意一点离线环境往往也是版本冻结的很多时候你没法临时升级系统组件所以安装包的选择必须匹配当前的系统版本。2. 离线安装前的准备工作版本确认与依赖梳理2.1 第一步是确认系统版本和架构不要一上来就找安装包。先登录目标机器看清系统版本和 CPU 架构。最简单的方式cat /etc/redhat-release uname -m输出结果会类似CentOS Linux release 7.9.2009 (Core)和x86_64。这两个信息决定了你要下载哪个版本的 rpm以及后续编译时要用的工具链。x86_64 是最常见的但公司里难免有 aarch64 的 ARM 机器千万不要拿 x86_64 的 rpm 去装 ARM 机器否则会报wrong ELF class之类的错误看起来一脸懵其实就是架构不匹配。还有一点容易被忽略CentOS 7 的 rpm 包不能直接用在 CentOS 8 上反过来也一样。el7、el8、el9 这些标记就是用来区分大版本的。下载安装包时一定要看清楚包名里是 el7、el8 还是 el9。2.2 sshpass 到底依赖什么我在不同机器上验证过sshpass 的依赖非常轻。以 CentOS 7 EPEL 里的 sshpass 1.06 为例用 rpm -qpR 查看依赖rpm -qpR sshpass-1.06-1.el7.x86_64.rpm输出基本只有 glibc 相关项比如/bin/sh、libc.so.6(GLIBC_2.14)(64bit)等。这些在正常安装的 CentOS 上基本都是现成的。而源码编译方式下依赖的是 gcc、make 和 libc 开发库。所以如果你选 RPM 方案大概率不需要额外处理依赖如果选源码方案需要先确认机器上有编译工具链。这里补充一点背景知识sshpass 早期版本是通过调用 forkpty 来分配一个伪终端然后把密码写入这个终端从而骗过 ssh 的密码读取逻辑。这个机制本身依赖的是 linux 的标准库和终端接口所以它的运行依赖非常少这也是为什么它能在各种精简版系统上跑起来。2.3 先规划好安装包的传递路径离线环境中安装包怎么送到目标机器也是一个容易被忽略的环节。常见的几种方式我列在下面传递方式适用场景注意事项scp/sftp网络可达的局域网若目标机器没有安装 openssh-clients反而要先解决基础问题内网 HTTP/FTP批量分发搭一个临时文件服务wget 即可U盘/移动硬盘物理隔离环境注意文件系统兼容性优先用 ext4/vfat内网 NFS 共享已有存储服务器直接挂载读取适合大量机器同时安装我个人的习惯是如果目标机器能通过局域网访问到一台跳板机就先用 scp 把安装包传到跳板机再在目标机器上拉取。这个过程中也方便对比文件 MD5防止传输损坏。文件传输这块很多人会栽在“文件明明传过去了但 rpm 就是报错”的问题上多半就是文件在传输中被损坏了。3. 方案一RPM包离线安装首选3.1 在联网机器上下载 RPM在能上外网的机器上先启用 EPEL 源然后下载 sshpass 的 rpm 包。CentOS 7 默认 base 源里没有 sshpassEPEL 里才有。一条命令就能把包拉到本地目录而不实际安装yum install --downloadonly --downloaddir/root/sshpass_rpm sshpass如果提示没有找到包先确认 EPEL 是否已安装yum install epel-release # 再次尝试下载 yum install --downloadonly --downloaddir/root/sshpass_rpm sshpass不想用 EPEL 或者没有外网但可以通过浏览器下载的也可以直接去 EPEL 镜像站或者 rpmfind.net 搜索对应版本。这里要特别注意一定要选对 CentOS 大版本。CentOS 7 对应 el7 的包CentOS 8 对应 el8CentOS 9 对应 el9混用很容易出现 GLIBC 版本不满足的问题。下载完之后在当前目录下应该能看到类似sshpass-1.06-1.el7.x86_64.rpm的文件。用 rpm -K 验证一下包完整性rpm -K sshpass-1.06-1.el7.x86_64.rpm返回OK说明签名校验通过。这一步在安全要求高的内网环境尤其重要防止安装包被篡改。之前有些同事图省事随便从一个第三方网站下载 rpm结果安装后系统出现异常。尽量从官方 EPEL 镜像或者有 GPG 签名的源下载。3.2 传输到目标机器并校验然后就是把 rpm 包传到目标机器。我习惯先放到/root/pkgs目录下mkdir -p /root/pkgs scp sshpass-1.06-1.el7.x86_64.rpm root目标IP:/root/pkgs/如果网络环境不允许直接 scp用前面提到的 HTTP 或U盘方式也行。传完之后在目标机器上核对一下 MD5md5sum sshpass-1.06-1.el7.x86_64.rpm和源机器上一对比完全一致再继续避免传输包损坏导致的诡异报错。这里多说一句我遇到过 rpm 安装时报package already installed但实际上又不是同一个版本的情况后来发现是之前有人手动拷贝过旧包目录里多个 rpm 文件混在一起导致操作时用错了安装包。所以在目标机器上尽量把待安装的包单独放一个干净目录。3.3 目标机器上安装接下来的安装就很简单了在目标机器上执行rpm -ivh sshpass-1.06-1.el7.x86_64.rpm正常情况下会输出类似Preparing... ################################# [100%]然后Updating / installing...的信息说明安装成功。装完之后直接在命令行输入sshpass -V能看到版本号就说明一切正常。如果出现依赖报错比如提示缺少某个库不要急着加--nodeps强制安装。先看缺什么缺的库是不是机器上真的没有。通常来说 sshpass 的依赖在基础系统里都有一旦报缺依赖更多时候是系统本身被裁剪过比如某些精简版镜像。这种情况下可以先用yum localinstall安装它会尝试从本地及已配置的源里解析依赖yum localinstall -y sshpass-1.06-1.el7.x86_64.rpm3.4 RPM 方案为什么是首选从实际运维角度看RPM 方案比源码编译有太多优势不需要目标机器上有 gcc/make安装过程秒级完成卸载也干净rpm -e 一条命令即可。离线环境里能少装一个编译器就少一个风险点这是我在批量部署时始终坚持的原则。另外RPM 方式还有一个隐性好处它是可追踪的。rpm -qa 能看到包完整列表出问题方便审计。源码编译方式安装后如果不小心忘了安装路径排查起来比较麻烦。对于公司内部的资产管理RPM 方案显然是更规范的选择。4. 方案二源码编译离线安装准通用方案4.1 为什么仍然需要源码方案RPM 方案虽然好但有一个前提你能找到匹配目标系统版本的 rpm 包。如果目标机器是 CentOS Stream、或者是一个特殊的 aarch64 变体、又或者公司安全策略禁止使用来源不明的 rpm那么源码编译就是更稳妥的兜底方案。源码编译的本质是跨发行版通用的只要有编译器和基础的 libc 开发库就能把 sshpass 从源码构建成可执行文件。我在实际工作中也遇到过一个场景目标机器是一个特殊定制的 Linux 系统内核和文件系统都被深度裁剪过普通的 el7 rpm 装不上但又确实需要 sshpass 来做自动化。这个时候源码编译几乎是唯一选择。4.2 准备源码包与编译工具先在联网机器上下载 sshpass 源码包wget https://sourceforge.net/projects/sshpass/files/sshpass/1.10/sshpass-1.10.tar.gz下载后同样传到目标机器然后确认编译工具是否齐备which gcc which make gcc --version如果离线机器上没有 gcc这会是一个比较大的问题。要么想办法从系统安装镜像的 packages 目录里找到 gcc 及其依赖 rpm 离线安装要么直接放弃源码方案改走 RPM。我遇到过几台机器没有 gcc最终是在系统 ISO 镜像包里找到 rpm 包再用 rpm -ivh 按依赖顺序装上过程比较繁琐。这里补充一个排查技巧如果系统连 yum 都没有但保留着本地 rpm 目录可以用rpm -qa | grep gcc快速判断 gcc 是否已装。另外即使没有 gcc有些精简系统也会带 ccC 编译器的一个别名可以先用which cc碰碰运气。4.3 编译安装过程在目标机器上解压并编译tar -zxf sshpass-1.10.tar.gz cd sshpass-1.10 ./configure --prefix/usr/local make make install./configure阶段会检查系统是否有 ssh 命令、是否有可用的编译器。如果报错configure: error: no acceptable C compiler found in $PATH那就是 gcc 没装。如果报错configure: error: SSH client is required说明系统里没有 openssh-clients这个在标准 CentOS 上很少见但精简镜像里确实可能碰上。编译完成后默认安装路径是/usr/local/bin/sshpass。检查一下/usr/local/bin/sshpass -Vsshpass 的源码包很小编译时间通常几秒钟就完成远比编译其他大型项目轻松。4.4 动态库与路径问题源码编译还有一个容易被忽略的细节如果你编译时使用了某些额外的动态库安装后运行可能报error while loading shared libraries。不过 sshpass 本身几乎不依赖额外动态库所以这个概率很低。真要遇到用 ldd 查一下ldd /usr/local/bin/sshpass确认缺失项后把相关库的位置写进/etc/ld.so.conf.d/下的配置文件再执行ldconfig即可。这个操作步骤虽然简单但你真在批量部署时遇到过一次就会理解为什么我总说离线环境最怕的就是“隐藏依赖”。另外./configure --prefix/usr/local只是指定了安装前缀并不影响运行时动态库的搜索路径。如果你在编译时通过CFLAGS指到了自定义的库路径记得在ld.so.conf里也加上对应路径否则会出现“编译能过、运行找不到”的尴尬情况。4.5 源码方案的可复制性源码编译的好处是只要源码包和编译器具备几乎不挑发行版CentOS 7、8、9、Stream 都能用同一个 tar 包编译。缺点也很明显编译时间稍长sshpass 很小其实也就几秒、需要开发工具链、后续 rpm -e 无法干净卸载。所以它是 RPM 方案的补充而不是替代。有一个折中思路也值得考虑在一台联网的机器上用源码方式编译然后把编好的二进制文件直接拷贝到其他相同架构、相同系统的机器上。前提是 glibc 和系统库版本保持一致否则二进制文件可能因为找不到匹配的库而无法运行。这个方式我在 CentOS 7 的同版本机器间测试过是可以跑的但只在确实没法装 rpm 的情况下才推荐。5. 安装后的验证与批量运维实战5.1 验证安装是否成功无论用哪种方式安装装完都要做一次功能验证。最保险的验证方式是先测试一次本地 SSH 免交互登录sshpass -p 你的密码 ssh -o StrictHostKeyCheckingno root127.0.0.1 hostname这里加-o StrictHostKeyCheckingno是为了避免首次连接时的公钥指纹确认交互。正常情况下这条命令会直接返回 hostname而不需要手动输入密码。如果返回的是密码错误或认证失败先确认密码是否正确、目标机的 sshd 是否允许对应认证方式。如果系统开启了堡垒机或者 PAM 模块测试的时候还要注意某些环境会对 root 的密码登录做额外限制导致Permission denied这时不是 sshpass 的问题而是系统策略的问题。5.2 批量分发 SSH 公钥实战离线安装 sshpass 的最终目的通常是规模化运维。我分享一个常用的批量初始化脚本思路#!/bin/bash SERVER_LIST/root/servers.txt PASSWORDTemporaryInitPass123 while read ip; do sshpass -p $PASSWORD ssh-copy-id -o StrictHostKeyCheckingno root$ip done $SERVER_LISTservers.txt 里每行一个 IP。这个脚本会把当前机器的公钥推送到所有目标机器上推送完成后后续的批量操作就不需要再输入密码直接用 ssh rootip 命令 就能执行。我在五十台机器的批量初始化时就这么干效果很稳定。注意如果机器数量多建议在循环里加超时控制避免某台机器无法连通导致脚本卡死。一种简单做法timeout 15 sshpass -p $PASSWORD ssh -o StrictHostKeyCheckingno -o ConnectTimeout5 root$ip hostnametimeout 15是命令级超时ConnectTimeout5是 SSH 连接超时。两者配合批量脚本的健壮性能提升不少。5.3 几个使用注意事项这里必须强调一下安全习惯。sshpass 把密码放在命令行里意味着通过 ps 查看进程参数就能看到明文密码。所以生产环境不要长期使用 sshpass -p 方式建议用它完成公钥分发后立刻改为密钥认证。如果一定要用密码方式优先使用-f从文件读取密码并把文件权限设为 600。脚本里的临时密码用完以后及时改掉。另外SSH 客户端默认对 known_hosts 有严格检查批量场景下一定要配合-o StrictHostKeyCheckingno并做好 known_hosts 的管理否则首次连接会被指纹确认打断脚本直接卡在那里。在真正的重要环境里我建议反过来处理在跳板机上预先维护好可信的 known_hosts批量连接时不关闭指纹校验这样安全性更高但要花精力维护主机清单。6. 常见问题与排查技巧6.1 rpm 安装报依赖错误报错信息类似libc.so.6(GLIBC_2.14)(64bit) is needed by sshpass-1.06-1.el7.x86_64。这种一般是因为系统里的 glibc 版本过低或者系统被过度精简。先检查ldd --version如果 glibc 版本确实不够说明目标系统不适合装这个版本的 sshpass需要找对应旧版本的包或者改用源码编译。千万不要直接rpm -ivh --nodeps硬装那样即使装上运行的时候也会出问题。比如 sshpass 内部调用了某个 glibc 新接口老版本库上跑起来直接段错误排查起来更痛苦。顺带说一句如果你在公司内部维护了一套基线镜像建议把 sshpass 直接做进镜像里这样每次新机器交付就少一步离线安装这也是从根源上规避依赖问题的方法。6.2 编译报错 gcc 缺失源码编译时最常见的就是no acceptable C compiler found in $PATH。解决办法有两个方向一是从系统 ISO 镜像里提取 gcc、gcc-c、make 及其依赖 rpm按顺序 rpm -ivh 安装二是如果公司内网有可以临时开放的 yum 源把 iso 挂载进去临时用一下。相比起来直接找对应版本的 RPM 包安装仍然是最省事的路线。这里要提醒一下从 ISO 里提取 gcc 不是只装 gcc 一个包它有一堆依赖包括 cpp、glibc-devel、libgcc、binutils 等。建议在联网机器上先跑一遍yum install --downloadonly gcc make把所有依赖 rpm 一次性拉下来再按顺序拷过去安装这样比在 ISO 里一个一个找要高效得多。6.3 sshpass 命令找不到RPM 安装后sshpass 默认在/usr/bin/sshpass源码编译在/usr/local/bin/sshpass。如果执行时提示 command not found检查 PATH 是否包含对应目录。如果不想改 PATH直接用绝对路径或者做个软链接ln -s /usr/local/bin/sshpass /usr/bin/sshpass另外还有一种情况你明明装了 sshpass但用 sudo 执行时却说找不到这是 sudo 的环境变量 PATH 被重置了。可以用sudo visudo在 secure_path 里加上/usr/local/bin或者直接用sudo /usr/local/bin/sshpass来规避。6.4 权限与认证被拒绝安装成功后 sshpass 执行报Permission denied, please try again.这种基本和 sshpass 本身无关而是目标机器的 sshd 配置限制了密码认证。检查目标机器/etc/ssh/sshd_config里PasswordAuthentication是否为 yes以及用户是否在AllowUsers之类的白名单里。改完配置后记得systemctl restart sshd。另外如果密码中包含$、!、等特殊字符在双引号内会被 shell 解释导致密码错误。建议优先用单引号包裹或者用-f从文件读取密码能从根本上避免转义问题。我实际遇到过一次密码里有个!在 bash 历史扩展的极端场景下甚至会触发奇怪的错误当时排查了很久才发现是特殊字符的问题。6.5 批量脚本里反复卡住的坑使用 sshpass 做批量循环时我踩过最典型的坑就是 known_hosts 累积。机器第一次连接会提示确认公钥指纹第二次 IP 被重装系统后又会提示指纹变更这两种情况都会让脚本卡在 yes/no 询问上。解决方式是在 ssh 参数里固定加-o StrictHostKeyCheckingno -o UserKnownHostsFile/dev/null尤其是在批量初始化或测试环境里宁可不记录指纹也不要让脚本被卡住。还有个和 sshpass 无关但很常见的坑批量执行远程命令时如果命令里包含重定向符或者管道符比如ssh roothost echo xxx /tmp/a在脚本里嵌套多层引号后很容易出问题。建议把要执行的命令写成一个单独的脚本文件传到目标机器上再通过 ssh 执行能明显减少转义错误。最后再分享一个小经验。因为离线环境的网络和仓库千差万别与其每次现找安装包不如在公司内部搭一个简单的离线软件仓库把常用的 rpm 和源码包都归档进去包括 sshpass、常用编译工具、Python 运行时这类高频离线组件。平时用的时候直接 scp 或挂 NFS省下的时间和踩坑成本绝对不是一点半点。我这边现在所有内网机器初始化都会先执行一个标准离线包拷贝脚本把包括 sshpass 在内的几个核心工具一次装好后续批量操作就很顺了。