Ubuntu服务器SSH反向端口转发的安全风险排查及更优方案咨询

阿华AIGC实验室

2026-4-22

嗨，我来帮你拆解这个问题的安全风险，再给你几个更稳妥的方案～

一、现有配置下，知道user_123的密码会不会损坏服务器？

首先可以放心：直接损坏服务器的风险极低，原因如下：

你给user_123设置的shell是/bin/false，这意味着任何人用这个账号SSH登录服务器后，会立刻被断开，根本没法进入交互式环境执行任何命令。
默认情况下，这个账号也没法使用SFTP（因为SFTP需要shell支持或单独配置sftp-server），所以也没法上传恶意文件到服务器。
反向端口转发本身只是建立了一个从服务器到客户端的通道，这个通道只能让服务器这边的用户通过10022端口连接到客户端的SSH服务，并不会反过来让客户端能操作服务器。

不过也有几个潜在的小风险需要注意：

如果后续你不小心修改了SSH服务器配置（比如开启了这个用户的SFTP权限，或者把shell改成了可交互的），那风险会立刻上升。
如果客户端设备被盗或被劫持，攻击者可以利用这个反向隧道持续连接到服务器，但因为user_123没有操作权限，最多也就是占用一点服务器的网络资源，没法破坏服务器本身。

二、更安全的优化方案

你的核心需求是稳定、安全地通过服务器反向连接到LTE客户端，这里有几个升级方案：

1. 用SSH密钥代替密码登录（最基础的安全升级）

把客户端的密码登录改成密钥登录，彻底避免密码泄露的风险：

在客户端生成密钥对（推荐用更安全的ed25519算法）：
```
ssh-keygen -t ed25519
```
一路回车即可，不需要设置密钥密码（如果要设，后续可以用ssh-agent自动管理，避免每次输入）。
把客户端的公钥传到服务器的user_123账号下：
```
ssh-copy-id -i ~/.ssh/id_ed25519.pub user_123@serverIp
```
（如果没法用ssh-copy-id，也可以手动复制客户端~/.ssh/id_ed25519.pub里的内容，粘贴到服务器user_123的~/.ssh/authorized_keys文件中，注意要确保服务器上~/.ssh目录权限是700，authorized_keys权限是600）
服务器上禁用user_123的密码登录，修改/etc/ssh/sshd_config，添加以下内容：
```
Match User user_123
    PasswordAuthentication no
```
然后重启SSH服务：
```
sudo systemctl restart sshd
```

2. 限制密钥只能用于反向端口转发（进一步缩小权限）

在服务器的authorized_keys里给客户端的公钥添加限制，让这个密钥只能用于反向转发到客户端的22端口，连其他SSH操作都做不了：
修改~/.ssh/authorized_keys里对应的公钥行，开头加上这些限制选项：

command="echo 'This account is only for reverse SSH tunneling'",no-agent-forwarding,no-X11-forwarding,permitopen="localhost:22" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...

这样即使密钥泄露，攻击者也没法用它做任何其他操作，只能维持反向隧道。

3. 用autossh保持隧道稳定（适配LTE网络波动）

LTE网络可能不稳定，普通SSH隧道断开后不会自动重连，用autossh可以解决这个问题：

客户端安装autossh：
```
sudo apt install autossh
```
替换原来的SSH命令为：
```
autossh -M 0 -fN -R 10022:localhost:22 user_123@serverIp
```
-M 0表示不额外监听端口，用SSH内置的心跳机制检测连接状态，断开后自动重连。