企业官网建设流程全解析

简介：面向无网络连接或网络受限环境中的Ubuntu 20.04桌面版用户，这份离线资源包解决了系统默认未预装SSH服务组件的问题，为需要远程登录管理、自动化运维或学习SSH协议原理的读者提供了一套开箱即用的本地部署方案，应用场景覆盖企业内网隔离机房、个人虚拟机调试环境以及各类应急响应与故障修复场合，使用者无需配置在线软件源即可完成全部安装过程。资源包整体包含四个文件，压缩后大小约为1.05MB，其中有三个标准安装包和一个自动化安装脚本；三个安装包分别覆盖SSH客户端、服务端守护进程及SFTP文件传输功能，脚本则封装了依赖检测、安装顺序、服务启动等关键步骤，用户只需执行一条命令即可完成部署，免去逐条处理安装包的繁琐操作。截至目前，该资源已有一千二百四十三人学习使用，尤其适合负责系统初始化配置的运维工程师与正在练习远程服务搭建的入门学习者。借助这份资源，使用者能够一次性获得完整组件、安装脚本与清晰部署逻辑，无需临时查找零散资料即可快速启用SSH服务，建立安全可靠的远程登录与文件传输通道；同时也可将其作为剖析SSH软件包构成与离线安装机制的学习样例，在此基础上进一步实施更换监听端口、启用公钥认证等安全加固策略。安装完成后，系统即可接受来自客户端的连接请求，满足日常远程维护、脚本执行与自动化任务调度的实际需要。 先说一下这次分享的来由。最近在客户现场遇到一台 Ubuntu 20.04 服务器，内网环境，物理隔离，没法直接apt install openssh-server，但远程运维又必须先把 SSH 服务拉起来。我当时的做法是：找一台同样架构、同样系统版本、能联网的机器，把 sshd 相关的 deb 包全部拉下来，用 U 盘拷进内网，然后dpkg离线装好。整个过程不难，但里面有几个坑很容易把人卡住，尤其是依赖包缺失、libssl 版本冲突这类问题。这篇文章就围绕“Ubuntu 20.04 sshd 离线安装包”这件事，把我踩过的坑和验证过的完整流程整理出来，给同样受困于内网环境的朋友做个参考。

1. 什么场景下必须离线装 sshd

1.1 网络受限环境的经典痛点

先说场景。大多数时候我们拿到一台 Ubuntu 服务器，第一件事就是apt update && apt install openssh-server，一条命令搞定。可一旦系统处于下面几种环境，这条命令就废了：

• 纯内网机房，物理隔离，没有互联网出口；
• 代理网络，需要认证，APT 源根本访问不到；
• 安全加固后的服务器，主动禁用了外网 DNS 和 HTTP 访问；
• 现场设备预装了 Ubuntu 20.04，但部署时光盘/U 盘里只有系统镜像，没有软件包仓库。

这时候你就面临一个很尴尬的局面：SSH 没装，人在机器前只能插显示器键盘操作，可后续所有远程操作都依赖 SSH。所以离线准备好 sshd 安装包，本质上解决的是“在没有互联网的机器上，把远程运维通道打通”这个核心问题。

1.2 离线方案的核心思路

离线安装的核心思路其实就一句话：在另一台相同系统版本、相同 CPU 架构的联网机器上，把目标软件及其依赖全部拉下来，然后搬运到目标机器上安装。

为什么强调“相同系统版本”和“相同架构”？因为 Ubuntu 的 deb 包和系统库版本强相关。比如 Ubuntu 20.04 对应 focal 仓库，如果你拿 Ubuntu 22.04（jammy）的 openssh-server 包去装，依赖的 libssl1.1 版本、libc6 版本很可能对不上，装到一半就报依赖错误。架构就更不用说了，x86_64 的包无法在 arm64 系统上安装。所以离线准备的第一步，就是确认目标机器是 Ubuntu 20.04 x86_64（或者 aarch64、armhf），然后找一台完全一致的机器来下载。

提示：如果你手头只有一台联网机器，但系统版本不是 20.04，也可以用 Docker 临时跑一个 ubuntu:20.04 容器用来下载依赖包，效果一样，后面会讲。

2. 离线安装包准备：在联网机器上把料备齐

2.1 apt download 基本用法

最笨也最稳妥的方法，就是用apt download逐个下载 deb 包。在联网的 Ubuntu 20.04 机器上执行：

mkdir -p ~/sshd_offline cd ~/sshd_offline apt download openssh-server

执行完后当前目录会多出一个openssh-server_1:8.2p1-4ubuntu0.11_amd64.deb这样的文件。但注意，这只下载了 openssh-server 本体，它的依赖包一个都不会下载。直接把这个 deb 拷到内网机器上安装，几乎必然报错，因为缺依赖。

2.2 一步拉全依赖的实用命令

一条命令把 openssh-server 及其所有依赖全部拉下来，是这段操作的关键。使用apt-cache depends递归解析依赖，再用apt download批量下载：

cd ~/sshd_offline apt download $(apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances openssh-server | grep "^\w" | sort -u)

拆开解释一下这个命令干了什么：

• apt-cache depends列出 openssh-server 的依赖关系；
• --recurse递归解析每一层依赖，把“依赖的依赖”也找出来；
• --no-recommends --no-suggests排除推荐和建议安装的包，只保留硬依赖，减少包数量和体积；
• grep "^\w"把输出中的依赖包名称行筛出来，过滤掉带<、|等描述符号的行；
• sort -u去重；
• $(...)把结果作为参数传给apt download批量下载。

执行完后，目录下会得到十几个 deb 文件。对于 openssh-server 来说，通常包括这几个关键成员：

下载完成后，可以用ls -lh *.deb检查文件大小和数量。这块有两个常见问题：

第一，命令执行后如果报 “Unable to locate package”，说明当前机器没有更新软件源缓存，先执行apt update。第二，如果某些包提示“已经是最新版本”而不下载，可能是因为这些包已经从缓存中安装了。这不会影响后续离线安装，但为了保险起见，建议在下载前先apt clean清一下缓存，避免漏包。

2.3 使用 Docker 快速准备下载环境

如果你只有一台联网的 Windows 机器或 Mac，也可以借助 Docker 快速创建一个 Ubuntu 20.04 下载环境：

docker run -it --rm -v ~/sshd_offline:/packages ubuntu:20.04 bash

进入容器后先更新源：

apt update apt download $(apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances openssh-server | grep "^\w" | sort -u)

因为容器内部的/packages目录已经映射到宿主机，下载好的 deb 文件会直接出现在宿主机~/sshd_offline里。这个方式尤其适合你手头没有 Ubuntu 实体机、但需要快速准备离线包的情况。

2.4 把包搬运到目标机

deb 文件准备好之后，传输方式根据现场条件来定：

• 最快最稳的是 U 盘拷贝，用完记得sync再拔，避免文件丢失；
• 如果内网已经有一台可访问的机器，可以用scp传到那台机器，再内部转发；
• 如果目标机器网卡可用，只是没有互联网，还可以临时搭一个局域网 HTTP 服务，让它远程拉取。

我个人在实际项目里用得最多的还是 U 盘。因为内网安全要求高，插拔式拷贝最不容易被审计发现，也最可靠。

3. 目标机器离线安装与 sshd 部署

3.1 安装前的系统检查

在目标 Ubuntu 20.04 机器上执行离线安装之前，一定要先做三轮检查，避免白折腾：

第一，确认系统版本：

cat /etc/os-release lsb_release -a

确认是Ubuntu 20.04.x。如果系统是 20.04 没错，但内核版本被做进了定制化内核，也不影响 sshd 安装，因为 sshd 依赖的是用户态库，不绑定内核版本。

第二，确认架构：

dpkg --print-architecture uname -m

dpkg --print-architecture如果输出amd64，那下载的 deb 包也必须是amd64。如果你误拿了 arm64 的包，dpkg -i会直接报 architecture 错误。

第三，确认目标机器上是否已经有部分依赖包：

dpkg -l | grep libssl dpkg -l | grep libpam0g

如果某些系统自带依赖已经存在，安装时 dpkg 会自动跳过。另外有一个重要的细节——Ubuntu 20.04 默认自带openssh-client，所以下载依赖时可能没有重复下载它，但目标机器上如果被精简掉了，也要一并准备。

3.2 dpkg 安装操作与依赖处理

把所有 deb 文件拷贝到目标机器的同一个目录，比如/tmp/sshd_offline：

cd /tmp/sshd_offline sudo dpkg -i *.deb

dpkg -i会逐个安装当前目录下的所有 deb 包。正常情况下，输出应该显示每个包都成功安装，最后没有 error 信息。

如果某一步报依赖缺失，比如：

dpkg: dependency problems prevent configuration of openssh-server: openssh-server depends on libssl1.1 (>= 1.1.1); however: Package libssl1.1 is not installed.

这说明 libssl1.1 没有下载或者没有被正确安装。排查顺序如下：

# 查看当前目录所有 deb 包 ls -l *.deb # 查看指定依赖是否被打包进来 ls -l | grep libssl1.1

如果确实没有这个包，回到联网机器补下载：

apt download libssl1.1

这里有一个容易踩坑的点：Ubuntu 20.04 原生自带 libssl1.1，但如果你的目标机器装过 Python 3.10 或者其他第三方软件，可能系统里已经存在 libssl3（OpenSSL 3.x），而 libssl1.1 被替换或部分移除。这种情况下你在离线包目录里额外准备一个 libssl1.1 的 deb 是明智的。有些教程会让你直接apt --fix-broken install来修复依赖，但那是联网环境下的做法，离线环境根本没有源，执行了也没用，只能手动补齐依赖包。

安装完成后，验证核心包版本：

dpkg -l | grep openssh

输出应该包含openssh-server、openssh-client、openssh-sftp-server，状态都是ii（installed ok installed）。

3.3 启动服务与开机自启

把服务启动起来，这一步在 Ubuntu 上有几个小细节需要注意。

Ubuntu 的 SSH 服务单元名和 RHEL 系不一样，是ssh.service而不是sshd.service。网上很多教程写systemctl start sshd，那是 CentOS 的写法，在 Ubuntu 上直接执行会报 Unit not found。

正确的操作是：

sudo systemctl enable --now ssh

这条命令把开机自启和立即启动一起完成了。然后确认状态：

sudo systemctl status ssh

如果看到active (running)，说明服务已经跑起来了。再检查端口监听情况：

ss -tlnp | grep 22

输出里应该能看到sshd进程监听在 0.0.0.0:22。

有一个容易被忽略的坑是：系统里已经有一个 sshd 进程占用了 22 端口，但那个进程不是来自 systemd 的 ssh.service，而是之前用./sshd手动拉起的老残留。这种情况systemctl start ssh会报端口被占用。解决办法是先把老进程杀掉再启动 service：

pkill sshd systemctl restart ssh

4. 配置与常见问题排查

4.1 改端口、root 登录等常用配置

sshd 装好后，默认配置基本可用，但内网环境通常要做几项调整。配置文件在/etc/ssh/sshd_config，修改后执行sudo systemctl restart ssh生效。

第一项是允许 root 远程登录。Ubuntu 20.04 默认配置PermitRootLogin prohibit-password，意思是禁止密码登录 root，但允许密钥登录。如果现场环境确实需要直接 root 密码登录，改：

PermitRootLogin yes

但这里我建议你先想清楚安全问题。内网环境如果没人审计，root 密码登录倒还好；一旦这台机器会接入更大的网络，建议保持prohibit-password，只放公钥。

第二项是修改监听端口。默认 22 端口容易被扫描，改成比如 2222：

Port 2222

改完之后，注意测试时不要断开当前连接，而是新开一个窗口测试，确认能连上再关旧连接。不然端口写错，你把自己锁在门外就尴尬了。

第三项是检查防火墙。Ubuntu 20.04 默认可能没装 ufw，但如果装了：

sudo ufw status sudo ufw allow 22/tcp

还有 selinux 的问题，Ubuntu 默认没有启用 selinux，但如果你手动装过 apparmor 的额外配置，也要留意。

4.2 常见故障排查速查表

离线安装 sshd 最容易遇到的问题，我整理成一个速查表：

这里重点说两个实战多发的坑。

第一个是sshd: no hostkeys available。装好 openssh-server 后，如果系统没有自动生成主机密钥，sshd 启动时会直接退出。执行sudo ssh-keygen -A重新生成全部主机密钥，再systemctl restart ssh即可。这个命令在第一次启动 sshd 前执行更稳妥。

第二个坑是/var/empty/sshd权限问题。如果启动时看到：

/var/empty/sshd must be owned by root and not group or world-writable.

这是因为/var/empty/sshd目录的权限被改过。解决方式：

sudo chown root:root /var/empty/sshd sudo chmod 755 /var/empty/sshd

这个小问题在离线环境里碰到的人不少，因为很多内网机器会批量部署脚本，顺手就把权限改了。记一下这个命令，能省去不少排查时间。

4.3 验证客户端连接

安装和配置都完成后，从客户端验证一下：

ssh user@目标IP -p 22

如果连不上，先看 sshd 的状态，然后看防火墙，再看端口监听。三步走下来，绝大多数问题都能定位。

另外，如果你在一台全新的 Ubuntu 20.04 上离线安装了 sshd，但发现ssh localhost都连不上，优先检查/etc/hosts.allow和/etc/hosts.deny。有些安全加固过的系统会在这些文件里限制 sshd 的访问来源。

5. 最后再分享几个实操体会

离线装 sshd 这件事，看着简单，但真正在现场踩过坑之后，我对它的理解是：方案的核心不是那一条dpkg -i命令，而是前面准备依赖包的那几步。

我个人的习惯是这样的：准备离线包时，除了 openssh-server 本身，还会顺手多下载几个与 ssh 强相关的工具包，比如openssh-client、net-tools、rsync。前者是很多运维脚本的底层依赖，后者在做内网日志同步时经常用到。一次多准备一些，免得到现场发现缺包再折返。

还有一个小技巧：把下载好的 deb 包在联网机器上先解压验证一下完整性。用dpkg -c 包名.deb可以提前检查 deb 包结构是否完整，而不是等到现场装到一半才发现文件损坏。对 U 盘拷贝这种离线传输方式，这一步尤其值得做。

如果你负责维护多台离线机器，还可以把打包好的 deb 目录直接做成一个简易的本地仓库。网上有不少教程教你用dpkg-scanpackages生成 Packages 索引，然后配合apt使用。这样一来，内网其他机器要装什么软件，只要把这个仓库地址配进 sources.list，就能像联网一样apt install了。这个扩展方向很实用，但前提是那台放软件包的机器要先有一台“离线软件仓库机”，而仓库机的第一个软件往往就是通过今天这套 U 盘搬运装的 sshd。

最后再说一次：离线的核心不是“没有包”，而是“没有找到正确的包”。把依赖准备好，把架构看清，把服务名记住，Ubuntu 20.04 离线装 sshd 就是一次很顺畅的操作。希望这篇分享能帮你在现场少踩几个坑。

本文还有配套的精品资源，点击获取