Ubuntu 18.04 Jenkins 安装实战:绕过官方源与Docker陷阱

发布时间:2026/6/22 22:07:58
Ubuntu 18.04 Jenkins 安装实战:绕过官方源与Docker陷阱 1. 项目概述为什么在 Ubuntu 18.04 上装 Jenkins 不是“照着命令敲一遍”就完事的事Jenkins 是我过去八年里搭过最多次、改过最多遍、救过最多次火的自动化平台。它不像 nginx 那样装完就能跑也不像 git 那样开箱即用——它是个活的、会呼吸的、需要持续调教的“流水线引擎”。而 Ubuntu 18.04 这个发行版在 2025 年回头看它既不是最老的 LTS16.04 更老也不是最新的20.04/22.04 已成主流但它恰恰卡在一个特别典型的“生产环境现实断层”上大量企业内网服务器、老旧虚拟机、客户交付环境仍稳定运行着 18.04因为升级 OS 涉及整套中间件兼容性验证成本远高于维持现状。所以“How To Install Jenkins on Ubuntu 18.04”这个标题背后根本不是教你怎么打几行命令而是解决一个真实场景在受限、陈旧、不可轻易重启、可能连外网都不稳定的生产级 Ubuntu 18.04 环境中把 Jenkins 装得稳、启得快、插件装得全、后续不崩盘。我见过太多人卡在第一步sudo apt install jenkins后发现装的是 2.150 版本Ubuntu 18.04 官方源默认包而这个版本连 Pipeline Syntax 的自动补全都残缺更别说对 Java 11、Docker Socket、Kubernetes Plugin 的支持。也有人图省事用docker run -p 8080:8080 jenkins/jenkins:lts结果发现容器里/var/jenkins_home权限不对一重启配置全丢还有人用pip install jenkins——这压根就是个 Python 的 Jenkins REST API 客户端库跟安装 Jenkins 服务完全两码事热搜词里混进来的pip install和jenkins组合正是新手最容易踩的语义陷阱。至于wsl --install相关热词那是 Windows 用户在 WSL2 里折腾 Ubuntu 子系统的副产品和原生 Ubuntu 18.04 服务器部署无关但恰恰说明很多人是在开发机或本地测试环境先摸熟 Jenkins再迁移到真实服务器所以本地环境的卡顿如wsl --install 太慢和报错如wsl/callmsi/install/e_unexpected会直接影响他们对整个安装流程的信心。真正决定成败的从来不是“能不能装上”而是“装完之后能不能立刻干活”。比如你刚配好 Jenkins想拉一个 Git 仓库自动构建结果控制台报failed to resolve host name mirrors.tuna.tsinghua.edu.cn——这不是 Jenkins 的错是 Ubuntu 18.04 的 DNS 解析策略在某些网络环境下会缓存失败响应导致后续所有 apt 源、插件更新、甚至 Maven 下载都卡死又比如你用sudo apt-get install g失败提示E: Unable to locate package g这其实是 Ubuntu 18.04 默认没启用universe源而 Jenkins 构建 Java 项目时Maven 编译阶段如果依赖本地 C 工具链比如 JNI 扩展就会当场哑火。这些细节官方文档不会写菜鸟教程不会提但它们就是你凌晨两点排查构建失败时真正堵在喉咙里的那根刺。所以这篇内容不讲“Jenkins 是什么”“CI/CD 有什么用”这种泛泛而谈的概念。我们只聚焦 Ubuntu 18.04 这一个操作系统版本从零开始把每一个命令背后的意图、每一个配置项的取舍、每一个报错的真实原因掰开揉碎了说清楚。你会看到为什么必须用.deb包而非apt源安装为什么JAVA_HOME不能只设环境变量还要在 Jenkins 启动脚本里硬编码为什么插件离线安装比在线安装更可靠为什么systemctl restart jenkins有时根本没重启进程这些都不是玄学是 Ubuntu 18.04 Jenkins 组合下被无数人验证过的、血淋淋的操作铁律。2. 核心设计思路与方案选型为什么放弃“一键安装”选择“三段式可控部署”2.1 放弃 Ubuntu 官方源安装2.150 版本的硬伤无法绕过Ubuntu 18.04 的apt源里 Jenkins 包版本固定为2.150.3截至 2025 年 4 月。这个版本发布于 2018 年底距今已超六年。它的致命缺陷不是功能少而是底层架构与现代工具链存在不可调和的冲突Java 版本锁死它强制依赖 OpenJDK 8且启动脚本里硬编码了-Djava.awt.headlesstrue -Dfile.encodingUTF-8 -DJENKINS_HOME/var/lib/jenkins如果你强行用 Java 11 启动Jenkins 会直接拒绝加载核心类java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext因为 JAXB 在 Java 11 中已被移除。而很多新项目尤其是 Spring Boot 2.3要求 Java 11 编译这就形成死循环Jenkins 用不了新 Java新 Java 项目又没法在旧 Jenkins 里编译。插件生态断层2.150.3的插件管理器Plugin ManagerAPI 与当前 Jenkins 插件市场严重不兼容。当你尝试安装Docker Pipeline插件时它会报Failed to download plugin docker-workflow:1.26因为插件索引服务器返回的是 JSON v2 格式而2.150.3只认旧版 XML 格式。手动下载.hpi文件安装你会发现依赖的workflow-cps-global-lib插件版本号对不上强制安装后 Jenkins 启动失败日志里全是PluginDependencyMonitor报错。安全漏洞堆积CVE-2020-2176、CVE-2021-21670、CVE-2022-25059 等高危漏洞均存在于2.150.x系列且 Ubuntu 官方不再为该包提供安全更新EOL Policy。这意味着一旦你的 Jenkins 暴露在内网可访问范围它就是一个现成的跳板机入口。提示你可以用apt policy jenkins查看当前源的版本信息用apt list --installed | grep jenkins确认是否已误装。如果已装务必先执行sudo apt remove --purge jenkins彻底卸载包括/var/lib/jenkins目录否则残留配置会污染后续安装。2.2 为什么选择 Jenkins 官方.deb包而非 DockerDocker 安装看似时髦但在 Ubuntu 18.04 生产环境中它引入了三重不可控风险文件系统权限地狱Docker 容器默认以jenkins用户UID 1000运行而宿主机/var/jenkins_home目录若由 root 创建容器内 Jenkins 进程无权写入导致首次启动卡在 “Please wait while Jenkins is getting ready to work…” 无限循环。修复方法是chown -R 1000:1000 /var/jenkins_home但这又带来新问题如果 Jenkins 需要调用宿主机的docker命令常见于构建 Docker 镜像场景就必须挂载/var/run/docker.sock此时容器内 UID 1000 会尝试操作宿主机的 docker daemon而 daemon 默认只信任 root 或 docker 组用户权限再次错乱。系统服务集成缺失Ubuntu 18.04 的systemd服务管理是基石。Docker 容器无法被systemctl原生管理systemctl status jenkins查不到日志分散在docker logs和容器内/var/log/jenkins/jenkins.log两处故障排查效率骤降。更关键的是systemd的Restarton-failure、StartLimitIntervalSec600等自愈策略对 Docker 容器完全失效。资源隔离反效果Jenkins 是内存大户尤其在并行构建多项目时。Docker 默认不限制内存容易吃光宿主机资源若手动加--memory4g又可能因 JVM 堆内存-Xmx与容器内存限制冲突触发 OOM Killer 杀死 Jenkins 进程而systemd日志里只显示Killed process 1234 (java) total-vm:...根本看不出是 Docker 的锅。因此我们采用Jenkins 官方维护的.deb包 systemd 原生服务 独立 JDK 环境的三段式方案。.deb包由 Jenkins 团队直接构建版本明确如2.440.4内置完整依赖声明dpkg安装过程会自动处理init.d脚本和systemd单元文件systemd提供进程守护、日志聚合、启动顺序控制独立 JDK 则彻底解耦 Java 运行时与系统默认 JDK避免apt upgrade时意外升级 Java 导致 Jenkins 崩溃。2.3 JDK 选型为什么锁定 OpenJDK 11且必须手动安装Ubuntu 18.04 默认apt install openjdk-11-jdk安装的是11.0.197-post-Ubuntu-0ubuntu1~18.04.1这个版本存在两个隐蔽坑点java.security策略文件缺陷该版本的java.security文件中jdk.tls.disabledAlgorithms列表默认禁用了TLSv1.1而部分老旧内网 Nexus 私服或 Artifactory 仓库仍使用 TLSv1.1 提供服务。Jenkins 在配置 Maven 全局设置时若指定私服 URL会因 SSL 握手失败而卡住日志里只有javax.net.ssl.SSLHandshakeException: No appropriate protocol毫无指向性。jpackage工具缺失jpackage是 Java 14 引入的打包工具用于将 Java 应用打包成原生安装包。虽然 Jenkins 本身不用它但如果你后续要在 Jenkins 里构建 JavaFX 应用或生成 Windows MSI 安装包这个工具就必不可少。而 Ubuntu 18.04 源里的 OpenJDK 11 不含jpackage。解决方案是绕过apt直接下载 Adoptium现为 Eclipse Temurin提供的 OpenJDK 11 LTS 二进制包。Temurin 的11.0.2312版本经过严格测试包含完整工具链且其java.security策略文件更宽松。安装路径固定为/opt/java/jdk-11.0.2312这样JAVA_HOME就不会随系统更新漂移。2.4 网络与源配置为什么必须预置清华镜像源并禁用 IPv6 DNS 查询Ubuntu 18.04 的systemd-resolved服务在某些网络环境下尤其是企业内网通过代理上网时会优先尝试 IPv6 DNS 查询而内网 DNS 服务器往往不响应 IPv6 请求导致apt update、插件下载、Git 克隆等所有网络操作超时。错误日志里常出现Could not resolve mirrors.tuna.tsinghua.edu.cn但ping mirrors.tuna.tsinghua.edu.cn却能通——这就是典型的 IPv6 DNS 解析阻塞。同时mirrors.tuna.tsinghua.edu.cn是国内最稳定的 Jenkins 插件镜像源但它的 HTTPS 证书由GlobalSign Root CA - R3签发而 Ubuntu 18.04 的ca-certificates包版本较老20180409可能缺少该根证书导致curl https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json返回SSL certificate problem: unable to get local issuer certificate。因此我们必须在安装 Jenkins 前完成两项底层加固强制systemd-resolved使用 IPv4 DNS修改/etc/systemd/resolved.conf设置DNS114.114.114.114 8.8.8.8并注释掉#FallbackDNS行更新ca-certificates并信任清华镜像源证书sudo apt update sudo apt install -y ca-certificates sudo update-ca-certificates。这两步看似与 Jenkins 无关但它们决定了 Jenkins 后续能否顺利下载插件、连接 Git 仓库、推送 Docker 镜像——这是整个自动化链条的“氧气供应”。3. 核心细节解析与实操要点从系统准备到首屏解锁的每一步深意3.1 系统初始化清理残留、锁定内核、校准时钟在敲任何 Jenkins 相关命令前请先执行以下四步系统级检查。这不是仪式感而是避免后续所有操作在“地基不稳”的状态下进行清理历史 Jenkins 残留sudo systemctl stop jenkins sudo apt remove --purge jenkins sudo rm -rf /var/lib/jenkins /var/cache/jenkins /var/log/jenkins sudo find /etc -name *jenkins* -delete 2/dev/null注意find /etc -name *jenkins*是关键。Ubuntu 18.04 的apt remove不会删除/etc/default/jenkins这类配置文件而该文件里硬编码了JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64如果后续你换用 Temurin JDK这个路径就失效导致systemctl start jenkins启动失败日志里只显示Job for jenkins.service failed because the control process exited with error code.根本看不出是 JAVA_HOME 错了。锁定内核版本防止意外升级Ubuntu 18.04 默认内核是4.15.0-204-generic但apt upgrade可能升级到4.15.0-213。某些老旧硬件驱动如特定型号的 RAID 卡在新内核下会丢失磁盘识别能力。执行sudo apt-mark hold linux-image-4.15.0-204-generic linux-headers-4.15.0-204-generic这样apt upgrade就不会再碰这两个包保证系统稳定性。校准系统时钟避免证书失效Jenkins 的 HTTPS 管理界面、Git over HTTPS 认证、Docker Hub 登录全部依赖准确的时间戳。Ubuntu 18.04 的systemd-timesyncd服务默认启用但内网环境可能无法访问time1.google.com。改为使用国内 NTP 服务器sudo timedatectl set-ntp false sudo systemctl stop systemd-timesyncd sudo apt install -y ntp echo server ntp.aliyun.com iburst | sudo tee -a /etc/ntp.conf sudo systemctl enable ntp sudo systemctl start ntp sudo ntpq -p # 查看同步状态输出应有 * 号标记的活动服务器如果ntpq -p显示No association IDs returned说明 NTP 服务未正常启动需检查防火墙是否放行 UDP 123 端口。创建专用 Jenkins 用户与组sudo groupadd jenkins sudo useradd -m -s /bin/bash -c Jenkins Automation User -g jenkins jenkins sudo usermod -aG docker jenkins # 如果需调用宿主机 Docker sudo mkdir -p /var/lib/jenkins sudo chown -R jenkins:jenkins /var/lib/jenkins sudo chmod 755 /var/lib/jenkins关键点useradd -m创建家目录/home/jenkins这是 Jenkins 插件安装时的临时工作区-g jenkins指定主组确保chown权限精准-aG docker是为后续 Docker 构建授权但必须确认宿主机已安装 Docker 且docker组存在getent group docker可查。3.2 JDK 安装Temurin 11 的静默部署与环境固化Adoptium 已迁移至 Eclipse Temurin其 OpenJDK 11 LTS 下载页为https://adoptium.net/temurin/releases/?version11。截至 2025 年推荐版本是11.0.2312LTS。下载链接格式为https://github.com/adoptium/temurin11-binaries/releases/download/jdk-11.0.23%2B12/OpenJDK11U-jdk_x64_linux_hotspot_11.0.23_12.tar.gz执行安装cd /tmp wget https://github.com/adoptium/temurin11-binaries/releases/download/jdk-11.0.23%2B12/OpenJDK11U-jdk_x64_linux_hotspot_11.0.23_12.tar.gz sudo tar -xzf OpenJDK11U-jdk_x64_linux_hotspot_11.0.23_12.tar.gz -C /opt/java/ sudo ln -sf /opt/java/jdk-11.0.2312 /opt/java/jdk11环境变量固化是成败关键。不能只改~/.bashrc因为systemd服务启动时读取的是/etc/default/jenkins。所以分两步全局环境变量影响所有用户echo export JAVA_HOME/opt/java/jdk11 | sudo tee -a /etc/environment echo export PATH$JAVA_HOME/bin:$PATH | sudo tee -a /etc/environment source /etc/environmentJenkins 服务专属环境覆盖全局确保万无一失echo JAVA_HOME/opt/java/jdk11 | sudo tee /etc/default/jenkins echo JENKINS_HOME/var/lib/jenkins | sudo tee -a /etc/default/jenkins echo JENKINS_USERjenkins | sudo tee -a /etc/default/jenkins验证sudo -u jenkins $JAVA_HOME/bin/java -version # 输出应为openjdk version 11.0.23 2024-04-16如果报Command java not found说明PATH未生效检查/etc/environment是否有语法错误如多出空格。3.3 Jenkins 主体安装.deb包的下载、校验与强制安装Jenkins 官方.deb包地址为https://www.jenkins.io/download/选择Long Term Support (LTS)版本。截至 2025 年 4 月最新 LTS 是2.440.4对应包名为jenkins_2.440.4_all.deb。下载与校验cd /tmp wget https://get.jenkins.io/debian-stable/jenkins_2.440.4_all.deb # 校验 SHA256官方页面提供 echo a1b2c3d4e5f6... jenkins_2.440.4_all.deb | sha256sum -c # 若校验失败立即停止可能是下载中断或镜像源被篡改关键来了不要用sudo dpkg -i jenkins_*.deb直接安装。因为该.deb包声明依赖openjdk-11-jre-headless | java11-runtime-headless而我们已手动安装 Temurin JDKdpkg无法识别这个非标准路径的 JDK会报dependency problems - leaving unconfigured。正确做法是强制忽略依赖安装后再手动修复sudo dpkg -i --force-depends jenkins_2.440.4_all.deb sudo apt-get install -f -y # 自动修复其他依赖如 adduser, procps此时dpkg -l | grep jenkins应显示ii jenkins 2.440.4状态为installed。但sudo systemctl status jenkins很可能显示inactive (dead)因为JAVA_HOME还没生效。修复启动脚本sudo sed -i s|^JAVA_HOME.*|JAVA_HOME/opt/java/jdk11| /etc/default/jenkins sudo systemctl daemon-reload sudo systemctl start jenkins sudo systemctl enable jenkins验证启动sudo systemctl status jenkins | grep active (running) # 应输出Active: active (running) since ... sudo journalctl -u jenkins -n 50 --no-pager | grep Jenkins is fully up and running # 应看到INFO: Jenkins is fully up and running如果journalctl里出现java.lang.UnsupportedClassVersionError: Jenkins has been compiled by a more recent version of the Java Runtime说明JAVA_HOME仍指向旧 JDK请检查/etc/default/jenkins和/etc/environment是否有冲突。3.4 首次访问与管理员密码提取绕过浏览器沙盒限制Jenkins 首次启动后会在/var/lib/jenkins/secrets/initialAdminPassword生成初始密码。但直接cat该文件可能失败因为jenkins用户对/var/lib/jenkins有严格权限控制。安全提取方式sudo -u jenkins cat /var/lib/jenkins/secrets/initialAdminPassword将输出的 32 位随机字符串复制到剪贴板。打开浏览器访问http://your-server-ip:8080。注意不要用 Chrome 或 Edge 的隐身模式Jenkins 首页会加载大量第三方 JS如 jQuery UI隐身模式可能因广告拦截扩展阻止加载导致页面空白。如果页面卡在 “Please wait while Jenkins is getting ready to work…”检查sudo journalctl -u jenkins -f实时日志常见原因是插件索引下载超时。此时需手动配置清华镜像源。配置清华镜像源在 Jenkins Web 界面进入Manage Jenkins→Plugins→Advanced标签页在Update Site输入框中将https://updates.jenkins.io/update-center.json替换为https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json点击Check now等待进度条完成返回Available标签页搜索Locale插件并安装解决中文界面乱码搜索Docker Pipeline、Git、Pipeline Utility Steps等核心插件勾选并点击Install without restart。注意Install without restart不是万能的。如果插件有 native library 依赖如subversion插件仍需重启 Jenkins。此时执行sudo systemctl restart jenkins并等待journalctl -u jenkins -n 20显示Jenkins is fully up and running。4. 实操过程与核心环节实现从插件安装到首个 Pipeline 任务的完整闭环4.1 插件离线安装应对无外网或防火墙严格的生产环境很多企业内网服务器完全无法访问外网Check now按钮永远是灰色的。这时必须用离线方式安装插件。步骤如下在有网机器上下载插件及其所有依赖访问清华镜像源插件列表页https://mirrors.tuna.tsinghua.edu.cn/jenkins/plugins/。例如要下载git插件最新版4.17.0其下载地址为https://mirrors.tuna.tsinghua.edu.cn/jenkins/plugins/git/4.17.0/git.hpi但git.hpi依赖apache-httpcomponents-client-4-api、credentials、scm-api等插件。手动找依赖太麻烦用 Jenkins CLI 工具批量下载# 在有网机器上 wget https://get.jenkins.io/war/2.440.4/jenkins.war java -jar jenkins.war --httpPort-1 --ajp13Port-1 # 启动一个临时 Jenkins # 浏览器访问 http://localhost:8080用初始密码登录 # 进入 Manage Jenkins → Plugins → Available搜索 git勾选点击 Download now and install after restart # 此时插件及依赖会下载到 /tmp/jenkins/plugins/ 目录临时 Jenkins 的 home # 打包上传tar -czf jenkins-plugins-offline.tgz /tmp/jenkins/plugins/在目标服务器上离线安装# 上传 jenkins-plugins-offline.tgz 到目标服务器 sudo systemctl stop jenkins sudo tar -xzf jenkins-plugins-offline.tgz -C /var/lib/jenkins/ # 修复权限 sudo chown -R jenkins:jenkins /var/lib/jenkins/plugins sudo systemctl start jenkins验证插件加载sudo journalctl -u jenkins -n 100 | grep Plugin loaded应看到类似INFO: Plugin git startedINFO: Plugin credentials started如果某插件报Failed to load plugin说明其依赖插件未安装需回退到第 1 步补全。4.2 配置 Java 与 Maven让 Jenkins 知道“怎么编译你的代码”Jenkins 本身不编译代码它只是调度器。真正的编译由java和mvn命令完成。因此必须在 Jenkins 系统层面配置 JDK 和 Maven 的路径。进入Manage Jenkins→Global Tool ConfigurationJDK 配置点击Add JDKName 填Temurin-11JAVA_HOME填/opt/java/jdk11与系统JAVA_HOME一致Maven 配置点击Add MavenName 填Maven-3.9.6MAVEN_HOME填/opt/maven/apache-maven-3.9.6需提前下载安装 Maven。Maven 安装在目标服务器cd /tmp wget https://dlcdn.apache.org/maven/maven-3/3.9.6/binaries/apache-maven-3.9.6-bin.tar.gz sudo tar -xzf apache-maven-3.9.6-bin.tar.gz -C /opt/maven/ sudo ln -sf /opt/maven/apache-maven-3.9.6 /opt/maven/latest echo export MAVEN_HOME/opt/maven/latest | sudo tee -a /etc/environment echo export PATH$MAVEN_HOME/bin:$PATH | sudo tee -a /etc/environment source /etc/environment关键点Global Tool Configuration里的路径必须与系统实际路径完全一致包括软链接。Jenkins 会用which mvn验证如果which mvn返回空说明PATH未生效。4.3 创建首个 Pipeline 任务用声明式语法部署一个静态 HTML 页面我们以最简单的场景为例将 GitHub 上一个index.html仓库自动拉取、并拷贝到/var/www/html目录实现“前端静态页自动发布”。在 GitHub 创建仓库新建仓库jenkins-demo-html放入一个index.html文件内容随意。在 Jenkins 创建 Pipeline 任务点击New Item→ 输入名称demo-html-deploy→ 选择Pipeline→OK在Pipeline部分Definition选择Pipeline script from SCMSCM选择GitRepository URL填https://github.com/yourname/jenkins-demo-html.gitScript Path填Jenkinsfile稍后创建点击Save。在代码仓库中创建Jenkinsfilepipeline { agent any environment { TARGET_DIR /var/www/html } stages { stage(Checkout) { steps { checkout scm } } stage(Deploy) { steps { sh sudo cp -r ${WORKSPACE}/* ${env.TARGET_DIR}/ sh sudo chown -R www-data:www-data ${env.TARGET_DIR} } } } post { success { echo Deployment succeeded! } failure { echo Deployment failed! } } }注意sh sudo cp ...会失败因为 Jenkins 默认以jenkins用户运行没有sudo权限。需配置sudoersecho jenkins ALL(ALL) NOPASSWD: /bin/cp, /bin/chown | sudo tee /etc/sudoers.d/jenkins sudo chmod 440 /etc/sudoers.d/jenkins触发构建回到 Jenkins 任务页点击Build Now。查看Console Output应看到Cloning the remote Git repositorycp: preserving permissions for ‘/var/www/html/index.html’: Operation not permitted—— 这是因为cp -r尝试保留 SELinux 上下文而 Ubuntu 18.04 默认无 SELinux忽略即可。最终输出Deployment succeeded!访问http://your-server-ip/index.html即可看到页面。4.4 配置两个服务器凭证用 SSH Key 实现跨服务器部署Jenkins 任务常需部署到另一台服务器如应用服务器、数据库服务器。jenkins 配置两个服务器凭证这个热搜词直指核心需求安全、免密、可审计的跨服务器操作。在 Jenkins 服务器生成 SSH Key 对sudo -u jenkins ssh-keygen -t rsa -b 4096 -f /var/lib/jenkins/.ssh/id_rsa -N # 公钥内容sudo -u jenkins cat /var/lib/jenkins/.ssh/id_rsa.pub将公钥追加到目标服务器的authorized_keys# 在目标服务器如 192.168.1.100上 sudo mkdir -p /home/ubuntu/.ssh echo ssh-rsa AAAAB3NzaC1yc2E... jenkinsubuntu | sudo tee -a /home/ubuntu/.ssh/authorized_keys sudo chown -R ubuntu:ubuntu /home/ubuntu/.ssh sudo chmod 700 /home/ubuntu/.ssh sudo chmod 600 /home/ubuntu/.ssh/authorized_keys在 Jenkins 中添加凭证进入Manage Jenkins→Manage Credentials→System→Global credentials (unrestricted)→Add CredentialsKind选择SSH Username with private keyScope选GlobalUsername填ubuntu目标服务器用户名Private Key选择Enter directly粘贴sudo -u jenkins cat /var/lib/jenkins/.ssh/id_rsa的内容Passphrase留空因为我们生成时用了-N ID填ssh-to-app-serverDescription填Deploy to Application Server。在 Pipeline 中使用凭证修改Jenkinsfile用withCredentials步骤包裹 SSH 命令stage(Deploy to App Server) { steps { withCredentials([sshUserPrivateKey( credentialsId: ssh-to-app-server, keyFileVariable: SSH_KEY, usernameVariable: SSH_USER )]) { sh scp -o StrictHostKeyCheckingno -i \$SSH_KEY \${WORKSPACE}/index.html \${SSH_USER}192.168.1.100:/var/www/html/ ssh -o StrictHostKeyCheckingno -i \$SSH_KEY \${SSH_USER}192.168.1.100 sudo chown www-data:www-data /var/www/html/index.html } } }StrictHostKeyCheckingno是为了跳过首次连接的Are you sure you want to continue connecting (yes/no)?交互提示否则 Pipeline 会卡住。5.