亚马逊云返点 AWS亚马逊云远程登录指南

亚马逊aws / 2026-04-27 13:27:48

前言：远程登录这件事，本质上是“带通行证去敲门”

很多人第一次接触 AWS（亚马逊云）远程登录时，脑子里会出现两种经典画面：一是“我有服务器，我能进”；二是“为什么它要求密钥、还要安全组、还要权限？我只想 ssh 一下啊！”

别慌。AWS 的远程登录并不是故意为难你，它只是把“安全”这件事做成了“强约束”。你想象一下：你要进入机房（EC2 实例），AWS 不让你直接用“门口喊密码”的方式（用户名+口令），而是让你用“特制钥匙”（密钥对）去开门，并且还要保证门卫（安全组）允许你这个 IP 站在门外。

本文会用一种比较人话的方式，带你把 AWS 远程登录这条链路从头跑通：从准备密钥到连接实例，再到常见错误排查，最后讲讲如何把安全性做得更稳。

你需要先搞清楚的三件事：实例、密钥对、安全组

1. EC2 实例：你要登录的“目标机器”

AWS 远程登录的对象通常是 EC2（Elastic Compute Cloud）实例。它可以是 Linux，也可以是 Windows。本文主要以 Linux 的 SSH 远程登录为主，因为那是 AWS 最常见、也最容易遇到“密钥/端口/权限”的组合拳。

2. 密钥对（Key Pair）：你的通行证

AWS 的 SSH 连接，通常要求你使用密钥对。密钥对由一对文件构成：你本地保存私钥（.pem），AWS 会存储对应的公钥（你在创建实例时完成绑定）。你把私钥拿出来“签名”，AWS 才会相信你是你。

你可能会问：那用户名呢？用户名是实例镜像决定的，比如 Amazon Linux 常见用户是 ec2-user，Ubuntu 常见是 ubuntu，CentOS 也可能是 ec2-user。用户名不对也会导致连接失败。

3. 安全组（Security Group）：门卫的“放行规则”

即使你有正确的密钥对、用户名，安全组不放行，你依然进不去。安全组要允许入站到实例的 SSH 端口（通常 22）。同时还要允许你的源 IP（你的电脑公网 IP）能访问。

因此，远程登录的排查思路常常是：连没连上网络？端口有没有放行？账号对不对？密钥对不对？权限够不够？

准备阶段：在开始敲命令之前，你应该准备什么

1. 先确认：实例的登录方式

在 AWS 控制台，你创建实例时会选择 AMI（镜像），然后会选择密钥对。你需要明确：这个实例是 Linux 走 SSH，还是 Windows 走 RDP。

本文重点讲 SSH（Linux）。如果你确实是 Windows，我也建议你至少先把端口和安全组确认清楚：Windows 的 RDP 常用端口是 3389。

2. 准备本地客户端

你不需要装什么“神秘软件”。

Windows：推荐用 Windows 自带的 PowerShell + OpenSSH（一般系统自带或可安装），或者用 MobaXterm / VS Code Remote - SSH（更舒服）。
macOS：终端自带 ssh。
Linux：基本也自带 ssh。

关键点不是“你用什么软件”，而是你能正常运行 ssh 命令，并能正确使用私钥文件。

3. 私钥文件：.pem 的正确姿势

私钥通常是 .pem 文件。你需要注意它的权限。许多失败都来自一个很朴素的原因：你的私钥文件权限太开放，ssh 会直接拒绝。

在 macOS/Linux 上，一般执行：

chmod 400 your-key.pem

Windows 上也要确保私钥不会被某些工具乱改权限。你如果用 VS Code 或某些客户端，按照它的提示导入密钥即可。

在 AWS 控制台创建或确认：密钥对与安全组

1. 创建密钥对（Key Pair）

在 AWS 控制台，找到 EC2 相关页面，然后进入“密钥对（Key pairs）”。创建时会让你下载一个 .pem 文件。

注意一个容易翻车的点：密钥创建后 AWS 不会再让你下载原始私钥。你下载一次就得保管好，不然以后你会发现自己拥有“公钥的回忆”，没有“私钥的钥匙”。

因此下载之后，立刻保存到一个安全、路径清晰的位置，比如：

放在你项目目录的 keys/ 文件夹下
文件名不要太花，避免空格、中文路径

2. 配置安全组：放行 22 端口（或你使用的 SSH 端口）

亚马逊云返点 安全组的入站规则至少要允许：

协议：TCP
端口：22（SSH 默认）
来源：你的公网 IP（强烈建议）

很多新手会把来源设置成全开放（0.0.0.0/0），这是能连上但不够安全。更稳的做法是把来源限制为你当前的公网 IP。等调试完成后，如果你不需要长期远程，也可以关掉规则或把访问限制缩小。

3. 获取实例的公网地址（Public IPv4）

要远程登录，你的电脑必须能连到实例。通常你需要：

实例有公网 IPv4（或弹性公网 IP EIP）
安全组允许入站 SSH

如果你的实例没有公网地址，你会需要使用跳板机（bastion）或 VPN/内网方式。你也可以通过 AWS Systems Manager（SSM）做无密钥登录，但那是另一套流程。

正式远程登录：一步步把 SSH 跑通

1. 找到用户名：看 AMI 或控制台提示

不同镜像的默认用户名不同。你可以在创建实例时记一下，或者参考 AMI 文档。常见示例：

Amazon Linux：ec2-user
Ubuntu：ubuntu
Debian：admin 或 debian（视镜像而定）

如果你输错用户名，你会收到类似“Permission denied (publickey)”或“无法建立连接”的变种报错，但通常还会伴随更明确的日志。

2. 获取实例公网 IP：它长什么样不重要，你只要能复制它

在 EC2 实例详情里找“Public IPv4 address”。例如：

1.2.3.4

然后你就把它用在 ssh 命令里。

3. 执行 SSH 连接命令

典型命令如下：

ssh -i your-key.pem username@your-public-ip

例如（假设用户名为 ec2-user）：

ssh -i my-key.pem [email protected]

第一次连接时，系统可能会提示你“是否信任该主机”。你可以确认指纹（或者至少接受提示）。之后就应该能进入终端。

4. 如果端口不是 22：加上 -p

有些环境会把 SSH 端口改成其他值（比如 2222），那么 ssh 命令需要：

ssh -p 2222 -i your-key.pem username@your-public-ip

当然，这个端口也要在安全组里对应放行，否则你仍会“能看见门但进不去”。

常见失败场景与排查：不要慌，先对号入座

场景一：ssh 提示超时 / No route to host

这通常意味着网络层到不了实例。

排查顺序建议：

确认实例是否真的有 Public IPv4 或可达的地址
检查安全组是否入站放行了你的 IP 的 22 端口
确认实例状态是 running，没有卡在启动失败

如果你在公司网络里，公网 IP 可能会变；你以为“安全组给了你”，但源 IP 实际不是你想的那个。

亚马逊云返点场景二：Permission denied (publickey)

这几乎是“钥匙不对”或“私钥权限不对”的老朋友。

你可以按下面顺序检查：

用户名是否正确（ec2-user/ubuntu/admin 等）
亚马逊云返点 私钥是否就是创建该实例时下载的那把（不要用错 key pair）
私钥权限是否过宽：执行 chmod 400 your-key.pem
确认你没有把 .pem 转成奇怪格式或丢失内容

如果你愿意更细致一点，可以在 ssh 命令加上调试参数：

ssh -v -i your-key.pem username@your-public-ip

输出里通常会告诉你它加载了哪些密钥、尝试了哪些认证方式。

场景三：Host key verification failed

这通常表示：你之前连接过这个 IP（或主机），但现在的主机密钥不同了。可能原因包括：

你用的是同一 IP 但实例被重新创建
你做了镜像替换或重装导致主机密钥变化

亚马逊云返点 处理方式一般是更新 known_hosts 中的旧记录。具体命令因系统不同而不同，但核心思路就是：清掉旧的 host key 记录，让 ssh 接受新的指纹（前提是你确认确实是正确的实例）。

场景四：Connection refused

连接被拒绝通常意味着实例端的 ssh 服务没起来，或监听端口不对。

你可以检查：

实例上是否 sshd 服务运行（如果你能通过其他方式登录）
安全组是否确实放行了正确端口
你实例里是否改过 ssh 配置的监听端口

对于只能靠远程登录的人来说，可以先用 AWS 控制台的串行控制台（如果启用）或结合 Systems Manager（SSM）做排查。

场景五：你就是连不上，但你觉得都对了

这时候建议你“用系统思维”把问题缩小范围：

从你的电脑到实例 IP 的 22 端口是否可达（可以用网络工具测试）
安全组是否真的生效（有时你改了规则，但改的是另一个安全组）
实例是否挂到正确的网络（VPC、子网）
是否被网络 ACL 或路由策略拦截（更少见，但不是没有）

别把所有锅都甩给密钥。AWS 环境的复杂度不在 ssh 命令里，而在网络层。

安全性最佳实践：让“能连上”变成“连得久且更稳”

1. 最小权限：安全组尽量限制源 IP

调试阶段你可以暂时放开，但上线后尽量收紧到你的公网 IP。公网 IP 会变的话也可以用固定出口（比如家里宽带固定、公司固定出口）或改用 VPN/堡垒机。

2. 不要长期把 0.0.0.0/0 开着

把 SSH 暴露在公网并不等于世界末日，但风险会明显增加。再直白一点：你把门开到最大，然后祈祷没人来敲。祈祷没问题，安全工程师要的是确定性。

3. 建议使用 SSM（如果你不需要公网 SSH）

AWS Systems Manager 可以让你不通过公网直接登录实例（取决于你的实例配置和 IAM）。这样你就能把安全组的 SSH 暴露面收得更小。

SSM 的具体部署也有前置条件（角色、权限、代理等），但它能解决“公网 SSH 不安全”的核心问题。

4. 定期轮换密钥与访问策略

密钥泄露就像水管漏水：你不修它，它会一直漏。即使你现在能连上，也建议你在组织层面做密钥轮换、访问审计。

进阶体验：把远程登录变得更顺手

1. VS Code 远程 SSH：让你不只是在黑窗里敲命令

如果你喜欢写代码，VS Code 的 Remote - SSH 能把开发环境“搬到远端”。你依然使用密钥对，只是体验更像在本地写。

你要做的事本质上还是：配置 SSH 配置文件、填入用户名、私钥路径、主机地址。

2. SSH 配置文件：别每次都手动输入那么长的命令

你可以在本地创建或编辑 ~/.ssh/config，类似：

Host my-ec2
  HostName 1.2.3.4
  User ec2-user
  IdentityFile ~/.ssh/my-key.pem
  Port 22

然后你就可以用：

ssh my-ec2

少输入一次长串，快乐多一些。

一份“照着做就能成功”的流程清单

如果你不想阅读全文只想开干，那么你可以按这份清单操作：

在 AWS 创建 EC2 实例时选择并下载密钥对（确保你保存了 .pem 私钥）
在安全组入站规则中允许 TCP 22（或你的 SSH 端口）来自你的公网 IP
确认实例有 Public IPv4（或你能通过网络方式到达它）
在本地设置私钥权限（macOS/Linux：chmod 400 your-key.pem）
使用命令：ssh -i your-key.pem username@public-ip
失败时先看报错类型：超时多半是网络/安全组，publickey 多半是用户名/密钥/权限

结语：远程登录不是玄学，是一条可复现的链路

AWS 的远程登录，给人的第一印象通常是“门槛高”。但当你把实例、安全组、密钥对这三件事串起来，你会发现：它不是在跟你对抗，它在给你搭建一个安全、可控、可审计的访问方式。

你要做的只是：让你的钥匙对得上、门卫放得进、你站在允许的来源上。剩下的报错也都不是“随机惩罚”，而是各自指向网络、权限或认证环节。

下次当你再次遇到连接失败时，别急着怀疑人生。你只需要回到本文的排查顺序：先网络，再端口，再用户名，再密钥，再权限。相信我，你会更快找到问题，而且会越来越熟练。