Azure 新加坡账号 Azure微软云修改SSH端口

微软云Azure / 2026-04-27 23:26:31

前言：SSH 端口这事儿，别跟命运硬刚

如果你用过 Azure 的虚拟机，你大概会经历这种戏剧性场景：你明明在浏览器里看着 VM 信息一切正常，甚至控制台也能进，但你在自己电脑上用 SSH 连过去，却总是“超时/连接被拒绝”。你开始怀疑网络、怀疑人生、怀疑你是不是忘了输入 IP，还怀疑是不是把私钥放错了文件夹。

然后你发现，问题可能不是“SSH 没开”，而是你改了端口，或者你根本想改，却不知道哪里该改。Azure 的安全组、网络安全规则、系统防火墙、sshd 配置，这几样只要少看一步，就会让你以为自己在跟黑洞对话。

这篇文章就聊“Azure 微软云修改 SSH 端口”。我会尽量用人话讲清楚：要把 SSH 从默认的 22 端口改成别的端口（比如 2222），你至少要做哪些配置，以及为什么你可能会失败。

你要改的到底是哪一个“端口”

很多人第一次改端口时，会把四件事混在一起：

Azure 门面上的“网络安全组/安全规则”（控制外网能不能到达你的 VM）。
VM 内操作系统的防火墙（例如 UFW、firewalld 或 iptables）。
sshd 的监听端口（你希望服务到底监听哪个端）。
客户端连接命令（你得用新端口连过去）。

如果你只改了第 3，但没放行第 1，那你改的端口就像在沙漠里设了灯塔，但船票没给你开港口通行证——你当然到不了。

如果你只在 Azure 放行了新端口，但系统还在监听 22，那你就像把快递写成“23 号楼”，但收件人还住在“22 号楼”。

准备工作：先选一个“靠谱”的新端口

你可以把 SSH 端口改成 2222、22022 之类的。原则很简单：

避免使用已经被系统或服务占用的端口。
别用太“离谱”的端口让排查变得困难（比如改成 1 或 65535）。
端口不是“万能安全”，只是减少无脑扫描和日志噪音；真正的安全仍靠密钥、禁用密码登录、限制来源等。

这里我们假设你要把 SSH 从 22 改为 2222。

步骤一：在 Azure 放行新端口（网络安全组）

在 Azure 里，最常见的“我改了但连不上”原因，就是你只改系统端口，却没在安全组里放行。

1）找到对应资源：NIC 或子网的 NSG

你可以从以下任一位置找到网络安全组（NSG）：

虚拟机页面通常能看到网络接口（NIC），然后看 NIC 关联的 NSG。
或者直接到“网络安全组”列表里找到并打开它。

关键点：你放行的规则要作用在你的 VM 实例上。NSG 可能绑定在 NIC，也可能绑定在子网，两者都可能。

Azure 新加坡账号 2）新增入站安全规则（Inbound security rule）

创建规则时通常需要这些信息：

源（Source）：你可以先用“Internet”（宽松），或更安全的做法是填你的公网 IP（推荐）。
目标（Destination）：默认是 VM 的地址段即可（通常跟 NSG 的关联方式有关）。
协议（Protocol）：TCP。
目标端口（Destination port ranges）：填 2222。
操作（Action）：Allow。
优先级（Priority）：给一个合理优先级，确保不会被更高优先级的拒绝规则覆盖。

建议你至少先把你自己 IP 放进去，别一上来就把端口对全世界敞开。你可以把“安全”理解成：请别把家门钥匙贴在门把上，然后希望没人会来开。

3）检查是否已有冲突规则

如果你之前已经有一条允许 22 的规则，而你现在准备改 2222，那么：

可以保留 22 暂时不动，用作“退路”。
但最终建议你根据安全策略禁用不必要的入站规则（比如只允许 2222）。

特别注意优先级：NSG 的规则是按优先级从小到大匹配的。你以为你新增的 Allow 生效了，结果其实更高优先级的 Deny 把你按在地上摩擦。

步骤二：在 VM 内配置 sshd 监听新端口

Azure 的放行只是“让门口的门铃响”，但真正的“门”在你的虚拟机里。

Azure 新加坡账号 1）编辑 sshd 配置文件

不同发行版路径可能不同，但常见的是：

Debian/Ubuntu：/etc/ssh/sshd_config
CentOS/RHEL：/etc/ssh/sshd_config

用你喜欢的方式打开文件（比如 vi）。找到或添加类似下面的配置：

Azure 新加坡账号 Port 2222

如果文件里原本就有 Port 22，那你就把它改成 2222；或者保持多端口（不推荐长期这么干，除非你在过渡期）。

2）可选：禁用密码登录（强烈建议）

端口改了≠安全了。真正的提升通常来自于减少攻击面。

你可以在 sshd_config 里做这些优化：

禁用密码登录：PasswordAuthentication no
开启公钥：确保 PubkeyAuthentication yes（通常默认就是 yes）
限制 root 直登：PermitRootLogin no（或至少不要放开）

注意：改 SSH 配置之前，确保你已经准备好用密钥能登录。如果你把密码登录关了，但你的公钥没配好，那你会收到一条来自宇宙的“权限不足”。

3）检查配置是否有语法错误

改完别急着重启。先跑一下检查命令（不同系统略有差异，但思路一致）：

sudo sshd -t

如果输出没有错误，那你再继续。

4）重启 ssh 服务

重启方式常见有：

sudo systemctl restart ssh
或 sudo systemctl restart sshd

Azure 新加坡账号 有些发行版服务名叫 ssh，有些叫 sshd。你也可以用 systemctl list-units | grep ssh 来看看当前服务名。

5）确认监听端口确实变了

你可以在 VM 上执行类似：

sudo ss -lntp | grep 2222

如果你看到 sshd 在监听 2222，那么恭喜，你至少完成了系统端的一半。

步骤三：如果你有系统防火墙，也要放行新端口

Azure NSG 不等于系统防火墙。很多云主机默认可能没开防火墙，但也可能开着。

1）先判断你用的是什么防火墙

常见：

Ubuntu/Debian：ufw
CentOS/RHEL：firewalld 或 iptables

你可以看一下：

是否存在 ufw：sudo ufw status
是否存在 firewalld：sudo systemctl status firewalld

2）以 ufw 为例：放行 2222

如果你用的是 ufw，常见做法是：

sudo ufw allow 2222/tcp

然后确认规则：

sudo ufw status

3）firewalld 的话：也要放行

如果是 firewalld，一般类似：

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

4）不要忘了你的“退路”

如果你正在远程操作（尤其是用 SSH 登录改配置），建议先不要立刻完全关闭 22。你可以先：

Azure 安全组同时放行 22 和 2222
sshd 也先支持旧端口（或至少你暂时还能连 22）

当你用新端口验证成功后，再逐步关掉 22，减少攻击面。

步骤四：客户端验证新端口是否能连

到这一步，你需要从“客户端”确认路径是否通。

1）使用 SSH 明确指定端口

命令大概是：

ssh -p 2222 用户名@你的公网IP

如果你用了密钥文件：

ssh -i /path/to/key -p 2222 用户名@你的公网IP

2）用更“坦诚”的方式排查：SSH 详细日志

如果还是失败，加 -v 看看发生了什么：

ssh -vvv -p 2222 用户名@你的公网IP

你会看到它是卡在 DNS、卡在端口握手、还是卡在认证阶段。排查的关键不是“它失败了”，而是“它失败在哪一步”。

常见失败原因（以及对应解决办法）

下面这部分，我敢说是很多人改端口时最想看的“生存手册”。你不用全背，抓重点就行。

1）改了 sshd 端口但 Azure NSG 没放行：超时

现象：客户端提示连接超时。一般是包根本没到 VM 或被 NSG 拦了。

解决：

检查 NSG 入站是否允许 TCP 2222。
检查你 VM 关联的 NSG 到底是不是你改的那一个。
检查优先级。

2）Azure 放行了 2222，但 sshd 还监听 22：连接被拒绝

现象：可能是“connection refused”。说明对方 IP 可达，但服务不在该端口上。

解决：

确认 sshd_config 里 Port 是否是 2222。
重启 ssh 服务后确认监听端口。

3）系统防火墙没放行：仍可能超时或拒绝

现象：表现可能跟 NSG 类似，很多情况下也是超时。

解决：

检查 ufw/firewalld/iptables 是否拦了 2222。

4）你关了密码登录，但公钥没配好：认证失败

现象：端口连上了，但提示 Permission denied（密码不可用/密钥不匹配）。

解决：

确保 ~/.ssh/authorized_keys 已写入你的公钥。
Azure 新加坡账号 检查文件权限：目录权限、authorized_keys 权限通常要严格。
必要时先用 22 端口临时验证再收尾。

5）你在新端口验证前就把 22 全关：直接“下线”

现象：你远程彻底没法连了，连控制台都开始怀疑自己。

解决：

建议过渡期同时保留 22 和 2222。
至少在你确认 2222 能连上之前不要删除 22 的规则。

过渡策略：改端口不要像“拆炸弹”一样单次成功

很多配置问题不是技术难，而是流程风险。你要避免“改完就赌命”。建议你采取下面这种稳妥路线：

先在 sshd 配置中加入新端口监听（必要时暂时保留旧端口）。
先在 Azure NSG 放行新端口。
先在客户端用 2222 验证登录。
确认无误后，再逐步收紧：先停用密码登录，再考虑关闭 22。

如果你把这套流程当成“先试水再下锅”，成功率会高很多。

收尾：把 22 关掉前，做一次“最后确认清单”

当你确信新端口可以稳定连接，再做最终收尾。你可以按这个清单走：

客户端：能用 -p 2222 成功登录。
VM：ssh 服务确实监听 2222（ss -lntp 可见）。
Azure NSG：只允许你需要的来源访问 2222。
系统防火墙：放行 2222，且规则正确。
sshd 配置：按安全策略禁用密码登录（可选但推荐）。

最后再考虑禁用 22：

在 NSG 中删除/禁用允许 22 的规则。
在 sshd_config 中只保留 Port 2222。

注意：禁用规则前，先别做“情绪化操作”。就像你不该在确认新牙装好后立刻拔掉旧牙——虽然勇气很重要，但牙齿更重要。

额外安全建议：端口不是终点，才是起点

端口修改对抗自动化扫描有一定效果，但黑客不会只盯着 22。现实世界里扫描会遍历常见端口，甚至直接抓 banner 或探测开放服务。

你可以进一步做这些动作，让你的机器更稳：

只允许你的公网 IP（或少量固定网段）访问 2222。
禁用密码登录，强制使用密钥。
限制登录用户（比如只允许特定账号）。
启用 fail2ban（可选，用于减少爆破攻击）。

如果你只是为了“看起来更安全”而改端口，那你可能会得到一种心理安慰，但安全提升并不会成比例。真正的安全，是多层的。

总结：把 SSH 端口从 22 改到 2222，你要记住三件事

最后用一句话把文章浓缩：SSH 端口要改，得同时改对 Azure、改对 sshd、改对防火墙，并用客户端验证。

Azure：放行新端口（并注意 NSG 绑定位置和优先级）。
系统：sshd 配置设置 Port，并重启后确认监听。
防火墙：如果启用了 ufw/firewalld，也要放行 2222。

照这个流程来，你就不会在“我明明改了怎么还连不上”这场戏剧里反复上演。祝你改端口顺利，祝你登录稳定，祝你少踩坑，当然也祝你少受那种“超时”的折磨。