ssh安全登陆小白文

很多新手拿到一台 Linux Server 后，第一件事往往是直接开始装环境、跑服务，但更稳妥的做法是先把登录方式收拾好。因为一台刚装好的服务器，如果长期允许 root 直接密码登录、继续使用默认 SSH 端口、一直开着密码认证，风险会比较高。

这篇文章按一个适合新手的顺序，带你完成 Linux 初始设置中的 SSH 安全加固。示例系统为 Ubuntu Server。整套流程的目标很明确：

  1. 新建一个普通管理用户，例如 test
  2. 禁止 root 使用密码直接登录
  3. 修改 SSH 默认端口，例如改为 22222
  4. 为 test 配置密钥登录
  5. 确认密钥登录没问题后，彻底关闭密码登录

整篇文章尽量写得浅显，但操作逻辑会按运维的标准来，确保你既能看懂，也能尽量少踩坑。

一、开始前先了解两条原则

原则 1：不要一上来就把所有门都关死

很多教程会一口气改端口、关 root、关密码登录。如果你是第一次操作，强烈建议按步骤来，每改完一项就测试一次。这样即使出问题，也知道是在哪一步出的问题。

原则 2：操作 SSH 配置时，始终保留当前已登录会话

假设你现在已经通过终端连上了服务器，那么在新配置验证成功之前，不要关闭当前这个 SSH 窗口。正确做法是：

  • 保留当前连接不动
  • 新开一个终端窗口测试新配置
  • 确认新方式能登录后，再关闭旧窗口

这是非常重要的习惯，可以避免把自己锁在服务器外面。

二、先更新系统软件包

登录系统后，先把软件包索引和已安装软件更新一下：

sudo apt update
sudo apt upgrade -y

如果你当前登录的就是 root，那么可以直接运行：

apt update
apt upgrade -y

这一步不是 SSH 加固本身，但它是很常见的初始操作，建议先做。

三、新建普通用户 test

1. 创建用户

执行下面的命令：

adduser test

系统会提示你设置该用户的密码，并填写一些用户信息。除了密码，其他信息直接回车也可以。

2. 把 test 加入 sudo 组

为了让 test 以后也能执行管理命令，需要把它加入 sudo 组：

usermod -aG sudo test

Ubuntu Server 默认使用 sudo 组授予管理员权限，这样做比一直使用 root 更安全，也更符合日常运维习惯。

3. 测试 test 是否可用

可以先切换到新用户试一下：

su - test

再测试是否具备 sudo 权限：

sudo whoami

如果输出是 root，说明 sudo 权限正常。

测试完成后，如需回到原账户：

exit

四、关闭 root 密码登录权限

这一项的目标不是“删除 root”，而是不允许 root 通过 SSH 远程密码登录。

1. 编辑 SSH 配置文件

Ubuntu Server 的 SSH 服务配置文件通常是：

sudo nano /etc/ssh/sshd_config

如果你当前是 root：

nano /etc/ssh/sshd_config

找到这一项：

PermitRootLogin

把它改成：

PermitRootLogin no

说明：

  • PermitRootLogin no 表示禁止 root 通过 SSH 登录
  • 对新手来说，这是最省事、也最安全的做法
  • 后续远程管理统一使用普通用户 test，再配合 sudo

2. 检查配置是否重复

很多配置文件里，某个参数可能出现多次。最终生效的通常是后面那一项。所以你要确保文件里关于 PermitRootLogin 的设置清晰明确，避免前后冲突。

3. 先不要急着重启连接

改完先保存文件，但先别关闭当前 SSH 会话。后面我们会统一检查并重启 SSH 服务。

五、修改 SSH 登录端口

SSH 默认端口是 22。修改端口不能替代真正的安全措施，但能减少大量针对默认端口的自动扫描和暴力尝试。

1. 在 sshd_config 中修改端口

继续编辑：

sudo nano /etc/ssh/sshd_config

找到：

#Port 22

把它改成：

Port 22222

说明：

  • 这里用 22222 只是示例，你也可以换成别的未占用端口
  • 端口范围通常建议使用大于 1024 的端口
  • 修改后，以后 SSH 登录要显式指定这个端口

2. 如果开了防火墙，要放行新端口

如果服务器启用了 ufw，需要先放行新端口：

sudo ufw allow 22222/tcp

如果你还没有放行新端口，就贸然重启 SSH，可能会导致无法连接。

如果你想确认 ufw 状态：

sudo ufw status

3. 重启 SSH 服务前先做配置检查

在正式重启前，先检查 SSH 配置有没有写错：

sudo sshd -t

如果没有任何输出，通常表示语法正常。

4. 重启 SSH 服务

Ubuntu Server 一般执行：

sudo systemctl restart ssh

然后查看服务状态：

sudo systemctl status ssh

如果状态正常，就可以开始测试新端口。

5. 先测试新端口能否登录

在你自己的电脑上，新开一个终端窗口，使用新端口测试：

ssh -p 22222 test@你的服务器IP

请注意：

  • 一定要新开窗口测试
  • 原来的 SSH 窗口先不要关
  • 如果能登录成功，说明新端口配置正确

六、为 test 配置 SSH 密钥登录

这一部分是整套流程里最关键的内容之一。相比密码登录，SSH 密钥登录更安全，也更适合长期使用。

1. 在服务器上创建 .ssh 目录

先切换到 test 用户，或者直接以 test 登录后执行：

mkdir -p /home/test/.ssh
chmod 700 /home/test/.ssh
chown test:test /home/test/.ssh

这三条命令的作用分别是：

  • 创建 .ssh 目录
  • 把目录权限设置为只有用户自己可读写执行
  • 确保目录归属者是 test

.ssh 权限不正确时，SSH 可能会拒绝使用密钥，这一点非常常见。

2. 在本地电脑创建密钥对

这一步是在你自己的电脑上执行，不是在服务器上执行。

如果你使用的是 Linux、macOS，或者 Windows 的 PowerShell/OpenSSH 环境，可以执行：

ssh-keygen -t ed25519 -C "test@ubuntu-server"

说明：

  • ed25519 是目前非常常用、也很推荐的密钥类型
  • -C 后面的内容只是备注，便于你以后识别这把密钥

执行后会提示你输入保存路径，通常直接回车即可，默认会保存到：

~/.ssh/id_ed25519

随后会提示你是否为私钥设置口令：

  • 设口令更安全
  • 不设口令更方便
  • 从安全角度看，建议设置一个你自己记得住的私钥口令

生成完成后，你本地一般会得到两个文件：

  • 私钥：~/.ssh/id_ed25519
  • 公钥：~/.ssh/id_ed25519.pub

其中：

  • 私钥绝对不要发给别人，也不要上传到服务器公开目录
  • 服务器上需要放的是公钥

3. 把公钥导入服务器的 authorized_keys

方法一：使用 ssh-copy-id，这是最省事的方法。

在本地电脑执行：

ssh-copy-id -p 22222 test@你的服务器IP

如果本机没有 ssh-copy-id，也可以手动导入。

先在本地查看公钥内容：

cat ~/.ssh/id_ed25519.pub

复制输出的整行内容，然后在服务器上执行：

echo "这里替换成你的公钥整行内容" >> /home/test/.ssh/authorized_keys
chmod 600 /home/test/.ssh/authorized_keys
chown test:test /home/test/.ssh/authorized_keys

说明：

  • authorized_keys 用于保存允许登录该用户的公钥
  • 权限建议设为 600
  • 文件归属者必须是 test

4. 再次确认 .ssh 相关权限

建议最终检查一下：

ls -ld /home/test/.ssh
ls -l /home/test/.ssh/authorized_keys

一个比较稳妥的结果通常是：

  • /home/test/.ssh 权限为 700
  • /home/test/.ssh/authorized_keys 权限为 600
  • 两者所有者都是 test:test

七、测试是否可以免密码 SSH 登录

现在开始进行最关键的验证。

在你的本地电脑上，新开终端执行：

ssh -p 22222 test@你的服务器IP

理想情况：

  • 如果你的私钥没有设置口令，会直接登录成功
  • 如果你的私钥设置了口令，会提示输入私钥口令，而不是服务器用户密码

这里要区分两种“密码”：

  • 服务器账号密码：以后我们准备关闭它的 SSH 登录用途
  • 私钥口令：这是保护你本地私钥文件的密码，可以保留

如果登录成功，可以继续执行：

whoami

应该输出：

test

再测试 sudo：

sudo whoami

如果输出 root，说明后续远程管理已经具备条件。

八、确认没问题后，关闭 SSH 密码登录

这一步一定要放在密钥登录确认成功之后进行。

1. 修改 SSH 配置

编辑配置文件：

sudo nano /etc/ssh/sshd_config

找到下面这些参数，建议设置为：

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
PubkeyAuthentication yes

重点说明：

  • PasswordAuthentication no：关闭 SSH 密码认证
  • PubkeyAuthentication yes：启用公钥认证
  • UsePAM yes：Ubuntu 默认一般保留开启即可

有些系统里没有 ChallengeResponseAuthentication，也可能看到 KbdInteractiveAuthentication。如果存在交互式认证相关项，也建议关闭，例如：

KbdInteractiveAuthentication no

2. 再次检查 SSH 配置

sudo sshd -t

如果没有报错，再重启 SSH：

sudo systemctl restart ssh

3. 最终验证

在本地新开终端，重新连接：

ssh -p 22222 test@你的服务器IP

然后再故意测试一次密码方式是否已失效。一个简单判断方法是：

  • 如果系统不再提示输入服务器账户密码
  • 或者在没有正确私钥的情况下直接拒绝登录

就说明密码登录已经被关闭，服务器只接受密钥登录。

到这里，你的 SSH 登录方式就已经比初始状态安全很多了。

九、推荐你顺手再做两件事

虽然这篇文章的重点是 SSH 初始安全设置，但从运维角度看，下面两项也非常建议一起做。

1. 配置防火墙，只放行必要端口

例如只放行 SSH 新端口：

sudo ufw allow 22222/tcp
sudo ufw enable
sudo ufw status

如果你的服务器还要跑网站，再按需放行 80、443。

2. 安装 fail2ban

它可以在有人频繁尝试暴力登录时自动封禁来源 IP：

sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

它不能代替密钥登录，但可以进一步减少无意义的扫描和尝试。

十、完整操作顺序总结

如果你想记住最稳妥的顺序，可以按下面的思路操作：

  1. 更新系统
  2. 创建普通用户 test
  3. 给 test sudo 权限
  4. 修改 SSH 端口为 22222
  5. 放行防火墙新端口
  6. 禁止 root SSH 登录
  7. 为 test 配置 .ssh 和 authorized_keys
  8. 在本地创建密钥对
  9. 测试 test 是否可以通过密钥登录
  10. 确认无误后关闭 SSH 密码登录

这个顺序的核心思想是：先确保新方式能进，再关闭旧方式。

十一、常见问题排查

1. 改了端口后连不上

优先检查这几项：

  • 是否真的重启了 SSH 服务
  • 是否放行了防火墙端口 22222/tcp
  • 连接时是否写了 -p 22222
  • sshd_config 是否写错，可用 sudo sshd -t 检查

2. 公钥已经导入，还是要求输入密码

常见原因有：

  • /home/test/.ssh 权限不对
  • authorized_keys 权限不对
  • 文件所有者不是 test:test
  • 公钥内容复制不完整
  • 登录时用错了用户，例如你把公钥放在 test 下，却用别的用户名登录

3. 关闭密码登录后进不去了

这通常说明你在确认密钥登录成功之前就把密码认证关掉了。所以再次强调：

  • 不要关闭当前已登录的 SSH 窗口
  • 一定要新开窗口测试密钥登录
  • 确认成功后再关密码登录

十二、结语

对新手来说，服务器初始化最重要的不是“装了什么软件”，而是“先把门锁好”。

用普通用户代替 root 直登、修改 SSH 默认端口、启用密钥登录、最后关闭密码认证，这是一套非常基础但非常实用的安全习惯。它不代表绝对安全，但足以帮你避开大量低级风险。

如果你以后继续学习 Linux 运维，可以在这套基础上再逐步补充：

  • 更细致的 sudo 权限控制
  • fail2ban 防爆破
  • ufw 或 iptables 防火墙策略
  • 双因素认证
  • 异地日志审计和入侵告警

先把这篇里的流程熟练完成，你的 Ubuntu Server 初始登录安全，就已经走在正确的路上了。