scp自动填充密码脚本：expect与sshpass双方案详解

不知道你有没有过这种经历：每天上班第一件事，就是对着一排服务器轮流scp拉日志、推配置。正常流程是敲命令、等密码提示、手输密码、回车，密码复杂点带上大小写和特殊符号，输错一次重新来。一天下来，光输密码就浪费不少时间，输到后来人都是麻的。我之前有段时间被这事烦透了，才下定决心写一个 scp 自动填充密码的 shell 脚本，把这套重复劳动彻底自动化。

这个脚本解决的核心问题很明确：scp 本身不允许在命令行直接传密码，它要求交互输入，于是自动化就没法直接写。但只要用对工具，完全可以做一个“传文件、自动填密码、收结果”的一键脚本。文章的路线对运维、后端开发、经常拉取服务器数据的同学都有参考价值，新手也能照着抄作业。我接下来会把原理、两种主流实现方案、脚本健壮化细节和常见坑一次性讲透。

1. 先搞清楚根因：为什么scp不能直接带密码

1.1 scp与SSH的密码“死结”

要动手写自动填充密码的脚本，先得明白一个底层规则：scp是基于 SSH 协议的文件传输工具，它的认证过程和ssh完全一致。SSH 协议在设计上刻意不支持“在命令行里直接传密码”这种用法，很多刚接触的人会下意识试scp -p '123456'或者scp --password '123456'，然后发现根本没有这个参数。

SSH 之所以这么做，不只是因为交互习惯，更是出于安全考虑。Linux 下任意用户执行ps aux就能看到所有进程的完整命令行参数，如果允许scp -p '明文密码'，那么任何有权限看进程列表的人都能直接读到密码。此外 shell 历史记录、脚本日志、监控系统的命令采集都可能把明文密码留下来。所以 SSH 把这个口子焊死了。

那我们想要自动填密码，本质上是绕过“交互输入”这一环节，而不是绕过“密码认证”。目前主流做法有两条路：一是用expect模拟人去看终端输出、识别密码提示符、然后像人一样输入密码；二是用sshpass这类专用工具，在 SSH 底层要密码时直接通过伪终端喂给它。两条路各有侧重。

1.2 自动化填密码的两条主流路线

我实际用下来，两条路线谈不上谁绝对取代谁，更像是面对不同场景的选择。

从我的个人习惯来说，如果只是“拉文件、推文件”，我推荐先试sshpass，代码量最少；如果你要打交道的目标机器经常出现首次连接确认、登录后还要二次验证之类的交互，那expect更可控，因为它能像人一样“看着办”。

2. expect方案：最正统的“模拟人工输入”

2.1 expect的核心机制

expect最早是作为 Tcl 的扩展出现的，后来发展成独立工具。它的能力听起来其实很朴素：启动一个子进程，然后定期去看子进程的输出内容，如果匹配到你预设的字符串，就发送你预设的内容到子进程的输入里。

这里的底层有个关键概念：伪终端（pty）。expect调用spawn启动scp时，会为这个进程分配一个伪终端，让scp以为自己是在真实终端里运行，所以它才会正常输出密码提示、正常工作。你也可以把 expect 理解成“脚本化的人肉按键员”——它替你盯着屏幕，屏幕出现什么再由你预设的规则回应。

expect的三个核心子命令就是它的全部骨架：

• spawn：启动一个新进程，一般就是 scp 命令本身。
• expect：等待进程输出的特定字符串，比如password:。
• send：向进程发送字符串，比如把密码发过去再补一个回车。

2.2 写一个能跑的expect脚本

我们先写一个最精简的版本，能完成任务，后续再慢慢加固。

#!/usr/bin/expect set timeout 30 set host [lindex $argv 0] set user [lindex $argv 1] set pass [lindex $argv 2] set src [lindex $argv 3] set dst [lindex $argv 4] spawn scp -o StrictHostKeyChecking=no "$src" $user@$host:"$dst" expect { -re "(?i)password:" { send "$pass\r" } timeout { puts "连接超时，退出"; exit 1 } } expect { "100%" { } "No such file or directory" { puts "源文件不存在"; exit 2 } timeout { puts "传输结果未知，请人工确认"; exit 3 } } expect eof

逐行说几个细节：

第一，set timeout 30是 expect 自己的超时时间，单位秒。如果 30 秒内没等到密码提示符，就走timeout分支。这个值不要设太小，毕竟服务器响应慢、网络抖动都很常见。

第二，spawn scp -o StrictHostKeyChecking=no这段里我加了-o StrictHostKeyChecking=no，目的是避免首次连接目标机器时出现Are you sure you want to continue connecting (yes/no)?的询问。这里有一个安全取舍，后面专门说，先跑通再说。

第三，expect后面的-re "(?i)password:"用了正则匹配，(?i)表示忽略大小写。原因是不同系统的 SSH 提示符可能不同，有的是password:，有的是Password:，还有带空格、带换行的，用忽略大小写匹配能提高命中率。

第四，发送密码后要接一个\r，也就是回车键。很多新手只发密码不发回车，然后脚本就卡死了。

最后那个expect eof是等 scp 进程结束。这里的语感是“等你把退出了我再收工”，避免脚本提前退出导致子进程行为异常。

2.3 处理首次连接的host key确认

上面为了跑通直接用了StrictHostKeyChecking=no，但它确实有安全代价。它等于把“首次连接时确认主机指纹”这个安全检查跳过了。如果目标服务器 IP 被劫持，或中间人攻击的时候，客户端不会校验指纹就直接继续，这有风险。

我的建议是这样：如果这些服务器是你们自己内网的固定资产，你可以在第一次连接时人工执行一次ssh并确认指纹，让公钥写进本机的known_hosts，之后脚本里不再需要禁用校验。如果跑批量的机器列表经常变，或者你不在乎这个等级的安全，那再用StrictHostKeyChecking=no，但心里要清楚这个取舍。

如果确实想保留校验，同时又不想脚本因确认提示而卡住，可以用一个分支去处理：

expect { -re "(?i)yes/no" { send "yes\r"; exp_continue } -re "(?i)password:" { send "$pass\r" } }

exp_continue的作用是匹配到某个模式后不退出 expect，而是继续等待下一个模式。这里体现在：如果先出现了 yes/no 确认，就回一个 yes，然后继续等密码提示符；如果直接就是密码提示符，就发密码。

2.4 特殊字符密码的转义与传参

这是 expect 方案里新手最容易翻车的地方。如果你的密码里有$、!、[、]、\这些特殊字符，直接按普通字符串传进去，expect 会自动做变量展开和字符解析，密码就变样了。

比如密码是P@ss$w0rd，如果你在脚本里写send "P@ss$w0rd\r"，$w0rd会被当成 Tcl 变量（值通常为空），实际发送出去的密码就变成P@ss，自然认证失败。

处理办法很简单：用花括号包裹字符串，让 expect 不要展开变量。写成：

set pass {P@ss$w0rd} send "$pass\r"

或者用反斜杠转义\$。更稳妥的做法是：不要在脚本里写密码，而是从外部环境变量读进来，比如set pass $env(SCP_PASS)，这样既避免特殊字符解析问题，也不容易把密码硬编码进文件。

3. sshpass方案：更轻量的“一键传密码”

3.1 sshpass是什么，怎么安装

如果说expect是模拟人工交互的“重量级选手”，那sshpass就是专门为“非交互式 SSH/SCP 密码输入”打造的小工具。它的思路比 expect 直接得多：既然 SSH 不允许在命令行直接给密码，那我就给 SSH 制造一个“类似终端”的输入环境，然后在关键时刻把密码送进去。

对用户来说，体验就是一行命令：

sshpass -p '你的密码' scp /data/logs/app.log user@192.168.x.x:/data/backup/

安装方式各个平台略有区别：

• Debian/Ubuntu：apt install sshpass
• CentOS/RHEL 7+：默认源没有，需要先装 EPEL 源再装；如果内网环境允许，可以用yum install epel-release，随后yum install sshpass
• macOS：官方源里没有，一般需要额外仓库来安装，整体不如 Linux 上顺手
• Windows 的话，多数人不会直接在 Windows 本机跑这种脚本，一般是在 WSL 里用 Linux 方式装

3.2 sshpass的三种密码传入方式

sshpass -p直传密码是最直观的写法，但它有一个和前文提到的相同问题：进程命令行会暴露密码。比如你写进 cron 定时任务，监控系统抓命令参数时也会抓到密码。

我建议优先用下面两种方式。

第一种是环境变量方式：

export SSHPASS='你的密码' sshpass -e scp /data/app.log user@192.168.x.x:/data/backup/

脚本里不出现明文密码，进程列表里也只显示SSHPASS这个变量名，密码只存在于环境变量里。

第二种是密码文件方式：

sshpass -f /path/to/passfile scp /data/app.log user@192.168.x.x:/data/backup/

密码文件尽量放在只有自己或指定脚本用户能读的位置，并设置权限 600。

如果只是在本地临时手动跑一次，用-p也不是不行，但千万别把带-p明文密码的脚本提交到仓库里，这是最容易被刷库扫到的一类泄漏。

3.3 把sshpass封装成通用shell脚本

sshpass虽然命令简洁，但如果每次都要敲一遍，那只是从“输密码的痛”变成“敲长命令的痛”。我把它包成一个带参数解析的 bash 脚本，使用体验会舒服很多。

#!/bin/bash # 用法: ./scp_auto.sh -u user -h host -p pass -s /local/path -d /remote/path set -euo pipefail trap 'echo "脚本执行出错，退出码: $?" >&2' ERR usage() { echo "Usage: $0 -u <user> -h <host> -p <password> -s <source> -d <dest>" exit 1 } while getopts "u:h:p:s:d:" opt; do case "$opt" in u) USER="$OPTARG" ;; h) HOST="$OPTARG" ;; p) PASS="$OPTARG" ;; s) SRC="$OPTARG" ;; d) DEST="$OPTARG" ;; *) usage ;; esac done if [[ -z "${USER:-}" || -z "${HOST:-}" || -z "${PASS:-}" || -z "${SRC:-}" || -z "${DEST:-}" ]]; then usage fi sshpass -p "$PASS" scp -o StrictHostKeyChecking=no "$SRC" "$USER@$HOST:$DEST"

这个脚本有几个值得注意的写法：

set -euo pipefail是 bash 严格模式，让它“出错就停、变量没定义就报错、管道失败也报错”。对于脚本化文件传输，我希望它干脆利落地失败，不要勉强往下执行。

getopts负责解析命名参数。这样你调用的时候是./scp_auto.sh -u admin -h 192.168.x.x -p '密码' -s ./app.log -d /data/backup/，参数顺序不再容易弄错。

最后一行是核心传输命令。之所以还保留-o StrictHostKeyChecking=no，是因为很多服务端第一跳都是陌生主机，实际使用中如果不加，首次连接会有交互卡在 yes/no 上；你可以在跑通后根据内网安全策略决定要不要去掉。

4. 从能用到好用：脚本健壮化细节

真正在工作中跑脚本，最怕的不是脚本不做事，而是脚本“明里暗里坏掉但没人知道”。把脚本从“能跑”打磨到“稳定跑”，靠的是几个细节。

4.1 参数解析与默认值

前面 getopts 的方法适合命令行调用。如果脚本是固定的某个业务场景，比如每天早上从定时任务里拉某台机器的日志，那可以进一步把参数写进脚本配置区，并给默认值：

SRC="/var/log/app/$(date +%Y%m%d).log" DEST="/data/backup/" HOST="192.168.x.x" USER="backupuser"

这样 crontab 里只需要一行./scp_daily.sh就够了，缺失的参数由脚本内部兜底。好的设计不是功能越多越好，而是“默认能跑，参数可选”。

4.2 超时控制与重试逻辑

文件传输最怕的是网络不稳，scp 一直挂起。在命令行里人看到卡住可以 Ctrl+C，脚本里没人看着就麻烦。所以要让脚本有超时意识。

在 expect 里是set timeout 30，在 sshpass 的 bash 封装里就是scp -o ConnectTimeout=15 -o ServerAliveInterval=15。前者控制连接建立的超时时间，后者表示如果 15 秒内没收到服务端响应就发送探测包，判断连接是否还活着。这两个参数对避免脚本长时间挂死很有用。

再加一层重试逻辑，覆盖“偶尔抽风”的情况：

retry=0 until sshpass -p "$PASS" scp -o ConnectTimeout=15 -o ServerAliveInterval=15 "$SRC" "$USER@$HOST:$DEST"; do retry=$((retry + 1)) if [[ $retry -ge 3 ]]; then echo "已重试3次仍然失败，停止" exit 1 fi echo "传输失败，3秒后重试（第${retry}次）" sleep 3 done

注意把重试次数上限控制住，不然网络长期故障时脚本会无限循环，日志文件会越来越大。

4.3 日志与退出码设计

脚本输出不能一片空白。至少要有“开始传输、传输成功、传输失败+原因”这三类日志。我习惯把日志同时打到屏幕和文件，举个例子：

LOG_FILE="/var/log/scp_auto.log" log_info() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] [INFO] $*" | tee -a "$LOG_FILE" } log_err() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] [ERROR] $*" | tee -a "$LOG_FILE" >&2 }

退出码设计也很重要。如果你把脚本接进告警系统或者编排系统，它需要区分“连接失败”“文件不存在”“密码错误”等情况。建议在关键分支里用不同的退出码，比如 1 表示基础配置错误、2 表示源文件不存在、3 表示网络超时、4 表示认证失败。这样下游系统拿到退出码就知道问题类别。

4.4 安全底线：密码怎么管理

自动填密码脚本的硬伤就是“密码不能永远裸奔”。我的经验是按优先级选：

• 能用 SSH 密钥认证就不用密码认证，自动化脚本优先上密钥。
• 必须用密码的场景，优先通过环境变量传入，脚本内部从$SSHPASS读取。
• 其次使用权限 600 的密码文件，文件名和路径尽量不起眼。
• 最不建议把明文密码写死在脚本里，尤其不要把脚本提交到 git 仓库。

如果你管理多台服务器且密码不同，可以考虑用 profile 文件的方式，把每个 host 对应的 user、password 集中存到.scp_profiles里，设置 600 权限，脚本从 profile 里按 host 名取参数。这样既不散落密码，又便于统一轮换。

5. 常见问题排查实录

自动填密码的脚本看着简单，但实际部署时会遇到各种“环境特色”问题。我把踩过的坑整理成速查表，希望能帮你少走弯路。

5.1 expect匹配不上密码提示符

现象：expect 脚本启动后一直不发送密码，最终 timeout。

原因分几种：目标机器的密码提示符不是标准格式，可能带颜色转义字符；用户本身用的不是默认 SSH 端口，提示符出现位置不同；或者密码提示符出现在 expect 还没开始监听的窗口期。

排查方法：先用普通 ssh 手动连一次，仔细看提示符到底长什么样；然后在 expect 里改成-re "(?i)password[:：]"，把可能的中英文冒号都覆盖进去。如果还是不行，在 expect 里加log_user 1把子进程输出打到屏幕上，基本一眼就能看到发生了什么。

5.2 host key校验失败

现象：脚本第一次运行到目标机器时报错，提示REMOTE HOST IDENTIFICATION HAS CHANGED，或者停在 yes/no 确认。

原因：目标机器重装系统或SSH服务重启后，主机指纹变了；本机 known_hosts 里还留着旧指纹。如果确定目标机器是可信的，最直接的办法是清理旧记录：

ssh-keygen -R 192.168.x.x

然后重新将新指纹加入 known_hosts。如果不想清理，也可以在 scp 命令里临时加-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null，但前者是跳过检查，后者是让脚本不读旧的 known_hosts，两个都是临时绕过方案，生产环境慎用。

5.3 密码带$或者!传参就错

现象：密码明明正确，但 sshpass 或 expect 传过去以后认证失败。

原因：shell 展开与工具自身解析双重作用。bash 里如果你写sshpass -p "$PASS"，而PASS的值里有$，调用脚本时如果不小心用了双引号字符串./scp_auto.sh -p 'P@ss$w0rd'，shell 自己就会把$w0rd当变量展开。

处理方式明确一下：命令行传参时密码用单引号包住；脚本内部读取后不要再做二次解析；如果是 expect，统一用花括号包密码字符串；如果是 sshpass 优先建议-e环境变量方式，从根源避开转义问题。

5.4 scp到一半卡住或不显示进度

现象：小文件秒传没问题，大文件传着传着就像卡死了，进度条也不动。

原因：网络带宽被占满或 SSH 连接被中间设备掐断。scp默认没有主动检测连接是否活着的机制，普通情况下它要等 TCP 超时，可能要等很久。

解决方式是在 scp 参数里加-o ServerAliveInterval=15 -o ServerAliveCountMax=4，让客户端每 15 秒发一次 keepalive，连续 4 次没有响应就断开重来。配合脚本里的重试逻辑，大文件传输的稳定性会好很多。

5.5 想要断点续传和限速怎么办

这个坑在于很多人想当然地以为 scp 能断点续传，实际上原生scp没有这个能力。如果你传输大文件且经常中断，建议用rsync配合密码方案，rsync 天然支持断点续传，传输文件列表之前还会做增量比对，效率也更高。

sshpass -p "$PASS" rsync -avz --partial --progress "$SRC" "$USER@$HOST:$DEST"

其中--partial表示传输中断时保留已传输的部分，下次继续传。限速方面，scp 可以用-l参数限制带宽，单位是 Kbit/s，不是 KByte/s，例如scp -l 8192约等于 1MB/s；rsync 用--bwlimit=1024，单位是 KB/s，意思对应得更直接。

最后分享一个我自己的实践取舍

写自动填充密码的脚本，技术上并不复杂，难的是在便利与安全之间拿捏分寸。我个人这两年的实际用法是：临时手动操作时用 sshpass 加单引号密码，图省事；批量任务、定时任务里一律优先走 SSH 密钥；如果某些老系统确实只允许密码认证，再用环境变量 + 密码文件的方案，绝不把密码硬编码进仓库。如果你也准备在团队里推广这类脚本，建议先从一个低频场景跑起来，观察稳定性和安全影响，再逐步扩大到批量任务。毕竟越自动化，越要把出错的出口想清楚。