SSH 连接远程服务器：从入门到 Ubuntu 24.04/26.04 安全配置

SSH（Secure Shell）是远程登录 Linux 服务器的标准方式。它提供加密连接，适合日常运维、部署、排障和远程执行命令。

最常见的连接方式只有一条命令：

ssh username@server_ip

首次连接时，需要确认主机指纹；之后再通过密码或 SSH 密钥完成认证。实际生产环境里，密码登录只适合临时测试，长期使用应切换到密钥认证，并关闭密码登录。

本文覆盖这些核心问题：

• 如何用 SSH 连到远程服务器
• 如何在 Ubuntu 24.04 和 26.04 上启用 OpenSSH
• 如何配置 sshd
• 如何使用 ~/.ssh/config 管理多台机器
• 如何生成并部署 SSH 密钥
• 如何排查常见 SSH 连接错误
• 如何关闭密码登录并提升 SSH 安全性

本文侧重 Ubuntu 24.04 / 26.04 上的安装与安全配置。如果你想要一篇不限定发行版的 SSH 通用入门，可以先读《SSH 连接远程服务器：从入门到实践（全指南）》。

SSH 最短路径怎么走通？

结论很简单：先确认客户端有 ssh 命令，再确认服务端 sshd 正常运行、22 端口放通，然后执行 ssh user@host 即可。适用于大多数 Linux、macOS、Windows 环境。

5 步完成一次 SSH 登录

1. 打开终端

   • Linux / macOS：直接使用 Terminal
   • Windows：使用 PowerShell、WSL 或 Git Bash

2. 执行连接命令

ssh username@your_server_ip

3. 首次连接时，检查并接受主机指纹

4. 输入密码，或使用 SSH 密钥认证

5. 退出连接

exit

如果只是要快速进入一台已经配置好的服务器，到这里就够了。

Ubuntu 24.04 / 26.04 上如何启用 SSH 服务？

结论：在服务端安装 openssh-server，启动 ssh.service，再检查防火墙。适用于 Ubuntu Desktop 和未预装 SSH 的系统；很多云服务器镜像通常已经预装并在创建实例时注入了公钥。

安装并启动 OpenSSH Server

在要被远程连接的那台机器上执行：

sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh

检查服务状态和监听端口：

sudo systemctl status ssh
ss -tlnp | grep ':22'

正常情况下应看到：

• 服务状态为 active (running)
• 22 端口处于 LISTEN

如果服务没起来，也可以直接启动：

sudo systemctl start ssh

防火墙开启时要不要额外放行？

要。结论是：如果 UFW 已启用，必须先放行 SSH，否则服务已启动也连不进来。

sudo ufw allow OpenSSH
sudo ufw status

OpenSSH 这个应用配置默认映射到 22 端口。如果改了 SSH 端口，就需要显式放行对应端口。

Ubuntu 22.04、24.04、26.04 有哪些差异？

核心差异不大，但配置习惯有变化。24.04 和 26.04 更推荐把自定义规则写进 sshd_config.d。

SSH 最基础的命令格式是什么？

结论：大多数场景只需要掌握三种写法：连主机、带用户名连接、退出会话。适用于所有标准 OpenSSH 客户端。

基础连接

ssh remote_host

这里的 remote_host 可以是 IP 地址，也可以是域名。

如果远程用户名和本地用户名不同，显式指定用户名：

ssh remote_username@remote_host

退出当前 SSH 会话：

exit

Windows、Linux、macOS 是否都能直接用？

可以，但前提略有不同：

• Windows：当前版本的 Windows 10/11 通常内置 OpenSSH，也可以用 WSL 或 Git Bash
• macOS / Linux：终端默认一般已经有 ssh

SSH 连接到底是怎么工作的？

结论：SSH 是客户端 ssh 和服务端 sshd 之间的加密通信。只要服务端在运行且网络可达，就能建立远程 shell。适用范围是标准 OpenSSH 场景，不涉及跳板机、代理和更复杂的企业认证链路。

服务端安装 openssh-server 后，sshd 通常会自动启动。客户端发起连接时：

1. 连接到目标主机和端口
2. 校验主机身份（host key）
3. 进行认证
4. 建立加密会话

如果网络层就不通，或者 SSH 配错把自己锁在门外，常规 SSH 无法修复。这种情况下需要依赖云厂商提供的带外控制台（web Console / 控制台终端）进入系统修复配置。它的价值很直接：当 SSH 密钥、sshd_config 或防火墙规则导致远程登录失败时，仍然有一条救援通道。

Ubuntu 上应该怎么改 SSH 配置才稳妥？

结论：优先使用 /etc/ssh/sshd_config.d/ 下的 drop-in 配置文件，不要直接改主配置文件；修改后先用 sshd -t 校验，再 reload。适用于 Ubuntu 24.04 和 26.04，22.04 也支持类似方式。

配置文件位置与规则优先级

主配置文件是：

/etc/ssh/sshd_config

在 Ubuntu 24.04 和 26.04 上，通常第一行会包含：

Include /etc/ssh/sshd_config.d/*.conf

OpenSSH 对大多数指令采用“先匹配到的值生效”的规则。因此自定义配置建议新建高编号文件，例如：

/etc/ssh/sshd_config.d/99-custom.conf

这样更便于维护，也更不容易在包升级时被覆盖。

修改前先备份

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)

哪些配置项最值得检查？

1. 端口

Port 22

默认保持 22 即可。改成非默认端口只能减少自动扫描噪音，不能代替密钥认证和防火墙。

2. Root 登录

PermitRootLogin prohibit-password

当前 Ubuntu LTS 常见默认行为是：禁止 root 用密码登录，但允许 root 使用密钥登录。

生产环境更稳妥的做法是：先确认有可用的 sudo 用户和密钥登录，再设置为：

PermitRootLogin no

3. 认证方式

PubkeyAuthentication yes
PasswordAuthentication yes
KbdInteractiveAuthentication no

需要注意的是，旧资料里常见的 ChallengeResponseAuthentication，在 OpenSSH 8.4+ 环境里通常应看 KbdInteractiveAuthentication。

4. 日志级别

LogLevel INFO

排查认证问题时可以临时改成 DEBUG，问题解决后再恢复，避免产生过多日志。

修改配置后为什么一定要先测试？

因为 SSH 配错最直接的结果就是把自己锁在服务器外面。正确流程是：

sudo sshd -t
sudo systemctl reload ssh

建议在修改时保留一个已登录的 SSH 会话不要关闭，确认新配置可用后再断开旧会话。

管理多台服务器时，~/.ssh/config 值不值得配？

结论：值得。只要同时管理多台服务器、多个用户名、多个端口或多把密钥，就应该用 ~/.ssh/config。适用于本地客户端侧配置，不会影响远端服务器。

示例配置：

Host dev-server
    HostName 192.168.1.10
    User devuser
    Port 2222
    IdentityFile ~/.ssh/dev_key

保存后，连接时就不必再写完整命令：

ssh dev-server

这个方式尤其适合下面几类情况：

• 同一台电脑连接开发、测试、生产多套环境
• 不同主机使用不同端口
• 不同主机使用不同私钥
• 想减少命令输入错误

SSH 密钥登录怎么配置，为什么推荐 Ed25519？

结论：新环境优先用 Ed25519；只有兼容旧系统时再用 4096 位 RSA。密钥认证比密码登录更快，也更抗暴力破解。适用于绝大多数现代 Linux 服务器。

密钥认证的基本原理

SSH 密钥是一对：

• 私钥：保留在本地，不上传
• 公钥：放到服务器的 ~/.ssh/authorized_keys

服务端通过挑战-响应机制验证客户端是否持有与公钥匹配的私钥，而不是直接传输私钥本身。

在本地生成 Ed25519 密钥

在发起连接的机器上执行：

ssh-keygen -t ed25519

按 Enter 接受默认路径：

~/.ssh/id_ed25519

可以选择为私钥设置 passphrase。

什么时候还需要 RSA？

只有在旧系统不支持 Ed25519 时，再使用 RSA：

ssh-keygen -t rsa -b 4096

权限为什么经常导致认证失败？

因为 OpenSSH 对 .ssh 目录和密钥文件权限要求严格。先检查：

ls -l ~/.ssh/

通常应满足：

• 私钥权限：600
• 服务端 authorized_keys：600
• 服务端 .ssh 目录：700

如何把公钥复制到服务器？

如果服务器当前仍允许密码登录，最方便的是：

ssh-copy-id username@remote_host

部署完成后，再尝试重新登录，确认已经走密钥认证。

客户端还有哪些实用选项？

结论：至少应该掌握 -p、-i、-X、-vvv 和“远程执行单条命令”这几种用法。适用于运维、自动化脚本和日常排障。

使用非默认端口

ssh -p port_number remote_username@remote_host

前提是服务端 sshd_config 中的 Port 与之匹配。

指定私钥

虽然上面的摘要主要强调了 -i 选项，这里直接给出最常见形式：

ssh -i ~/.ssh/id_ed25519 remote_username@remote_host

当本地有多把私钥时，这个选项很有用。

只执行一条远程命令

ssh remote_host "command_to_run"

适合自动化场景，比如快速看远端版本、磁盘使用率或服务状态。

X11 转发

ssh -X remote_host

前提是客户端和服务端都已正确启用 X11 forwarding。

打开详细调试日志

ssh -vvv remote_username@remote_host

认证失败、找不到密钥、主机名解析异常时，这个选项非常有用。

SSH 报错时该先查什么？

结论：先分清是“服务没启动”“网络不通”“认证失败”还是“主机指纹问题”。大多数 SSH 故障都能归到这四类。适用于日常运维排障。

常见错误与处理方式

还有哪些进阶故障？

服务端实时日志怎么查看？

sudo journalctl -fu ssh

这条命令在排查认证失败时很关键。客户端看到的是“结果”，服务端日志通常能告诉你“为什么失败”。

为什么很多人配完密钥后还是在输密码？

结论：通常不是 SSH 没生效，而是客户端没有用到预期私钥、服务端公钥没装对、或者权限不满足要求。适用于“看起来配置过密钥，但登录行为没变化”的场景。

这种时候，优先执行：

ssh -vv remote_username@remote_host

如果调试输出里出现类似内容：

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/user/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply

说明客户端确实在尝试公钥认证。接下来要判断的是：

• 服务端是否接受了这把公钥
• 公钥是否真的写入了正确用户的 authorized_keys
• 目录和文件权限是否正确
• 是否连接到了错误的用户、错误的主机或错误的端口

如果公钥尝试后又回退到密码认证，往往说明服务端没有接受这把密钥。

密钥可用后，怎么关闭密码登录？

结论：先验证密钥登录完全正常，再关闭密码登录；不要反过来。适用于生产服务器，但前提是已经有可用的密钥登录和可恢复的控制台入口。

在 Ubuntu 24.04 / 26.04 中使用 drop-in 配置关闭密码认证

新建或编辑配置文件：

sudo nano /etc/ssh/sshd_config.d/99-disable-password.conf

写入：

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

校验并重载：

sudo sshd -t
sudo systemctl reload ssh

务必从一个新的终端窗口重新测试登录，确认无误后，再关闭当前会话。

同时建议确认：

• 公钥已经存在于 ~/.ssh/authorized_keys
• 当前服务器还有可用的控制台救援方式
• 不要在唯一 SSH 会话里直接切换到不可回退状态

SSH 的安全基线应该怎么设？

结论：真正有效的基线只有几条：使用密钥、禁 root 直登、及时升级、收紧防火墙。改端口只能减噪，不能当安全方案。适用于所有暴露到公网的 Linux 服务器。

建议配置如下：

• 使用 Ed25519 或 4096 位 RSA 密钥
• 公网服务器避免只开密码登录
• 创建 sudo 用户后设置：

PermitRootLogin no

• 及时更新 openssh-server

sudo apt upgrade openssh-server

• 通过 UFW 或云防火墙限制来源 IP
• 需要额外防暴力破解时，可使用 fail2ban
• 文件传输优先走 SSH 体系内的 SFTP / SCP

Windows、Linux、macOS 上的 SSH 用法有区别吗？

结论：命令基本一致，差异主要在工具入口。只要使用的是 OpenSSH 客户端，命令行行为几乎一样。

Windows

可选环境：

• PowerShell
• WSL
• Git Bash

常用命令同样是：

ssh user@server_ip

生成密钥：

ssh-keygen -t ed25519

macOS / Linux

直接使用系统自带终端即可，命令保持一致。

几个高频问题，直接给结论

在 Ubuntu 终端里怎么用 SSH？

打开 Terminal，执行：

ssh username@server_ip

把 username 替换为远程主机用户，把 server_ip 替换为公网 IP 或主机名。首次连接时输入 yes 确认主机指纹，然后输入密码或使用密钥。

Ubuntu 上怎么安装并启用 SSH？

在服务端执行：

sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh

如果启用了 UFW，再执行：

sudo ufw allow OpenSSH

客户端可生成密钥并安装公钥：

ssh-keygen -t ed25519
ssh-copy-id user@server_ip

怎么确认 Ubuntu 已启用 SSH？

检查服务：

sudo systemctl status ssh

查看是否为 active (running)。

再检查端口：

ss -tlnp | grep ':22'

如果要从另一台机器验证，可以用：

ssh -v user@host

或：

nc -zv host 22

Ubuntu 上 SSH 不通最常见的原因是什么？

优先排查这五项：

1. 没装 openssh-server
2. sshd 没启动
3. 防火墙挡住了 22 端口
4. IP、用户名或密钥写错
5. sshd_config 配置有误

对应检查命令：

sudo systemctl start ssh
sudo ufw allow OpenSSH
sudo sshd -t
ssh -vvv user@host

如果 SSH 已经失效但虚拟机还在运行，就改用云控制台登录修复。

一份适合生产环境的最小操作清单

如果目标是把一台 Ubuntu 服务器以相对稳妥的方式开放 SSH，顺序建议如下：

1. 安装并启动 OpenSSH Server

sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh

2. 放行防火墙

sudo ufw allow OpenSSH
sudo ufw status

3. 在本地生成密钥

ssh-keygen -t ed25519

4. 拷贝公钥到服务器

ssh-copy-id username@remote_host

5. 验证密钥登录可用

ssh username@remote_host

6. 使用 drop-in 配置关闭密码登录

sudo nano /etc/ssh/sshd_config.d/99-disable-password.conf

写入：

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

7. 校验配置并重载服务

sudo sshd -t
sudo systemctl reload ssh

8. 新开一个终端再次验证登录成功

如果还要再加一层基线，就把 root 直登关掉，并限制 SSH 来源 IP。

关于

关注我获取更多资讯

📢 公众号

💬 个人号