Ubuntu服务器直接暴露SSH端口22是运维安全里最容易被忽视的隐患。很多人以为改了端口、禁用了root登录就万事大吉，实际上只要服务器还能被直接连接，暴力破解、凭据泄露、操作审计缺失这些问题就始终存在。更稳妥的做法是在服务器集群前部署一台堡垒机，所有运维人员必须先登录堡垒机，再由堡垒机跳转到目标服务器，同时在堡垒机上完成身份认证、权限控制和全程操作记录。下面直接讲如何在Ubuntu 22.04或20.04上搭建一套可用的堡垒机环境，核心组件用Teleport，因为它部署简单、自带审计和短期证书功能，比手动配置JumpServer或自研跳板脚本更可靠。

一、堡垒机要解决的核心问题

堡垒机不是简单的一台跳板服务器。它需要同时解决四个问题：身份统一认证、权限最小化、操作全程审计、以及目标服务器不直接暴露登录入口。如果只是用一台Ubuntu服务器做SSH跳转，那只能叫跳板机，不叫堡垒机。跳板机依然依赖系统账户和密码，无法做到细粒度授权，也无法回放操作过程。真正的堡垒机应当让用户登录时通过堡垒机认证，获得一张短期有效的SSH证书，再用这张证书连接目标服务器。目标服务器只信任堡垒机签发的证书，不信任任何密码或长期密钥。这样即使某个运维人员的密码泄露，攻击者没有堡垒机签发的短期证书，也无法直接登录目标服务器。

二、环境准备与基础加固

先准备一台独立的Ubuntu服务器作为堡垒机，建议配置不低于2核4GB，系统版本22.04 LTS。目标服务器可以是任意数量的Ubuntu或其他Linux发行版。堡垒机自身的基础加固是第一步，因为它是整个运维入口的汇聚点。安装系统后先更新软件包并启用自动安全更新：

sudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

然后配置防火墙，只开放堡垒机对外提供服务的端口。Teleport默认使用443端口提供Web界面和反向隧道服务，SSH代理服务使用3023端口。如果不需要Web界面，可以只开放3023。用UFW配置：

sudo ufw allow 443/tcp
sudo ufw allow 3023/tcp
sudo ufw enable

堡垒机自身不要开放22端口给公网。管理堡垒机本身通过云厂商的VNC或本地控制台完成，或者只允许办公网出口IP访问22端口。这一步能大幅减少堡垒机被扫描和爆破的概率。

三、安装Teleport堡垒机

Teleport提供了官方安装脚本和APT仓库。在堡垒机上执行以下命令安装Teleport社区版：

curl https://goteleport.com/static/install.sh | bash -s 16.1.0

安装完成后，生成配置文件。Teleport的配置文件位于/etc/teleport.yaml。下面给出一份适合单节点部署的配置示例：

version: v3
teleport:
  nodename: bastion-01
  data_dir: /var/lib/teleport
  log:
    output: stderr
    severity: INFO
  ca_pin: ""
  diag_addr: ""
auth_service:
  enabled: yes
  listen_addr: 0.0.0.0:3025
  cluster_name: prod-bastion
  tokens:
    - "proxy,node:replace-with-a-long-random-token"
ssh_service:
  enabled: yes
  labels:
    env: prod
proxy_service:
  enabled: yes
  listen_addr: 0.0.0.0:3023
  web_listen_addr: 0.0.0.0:443
  tunnel_listen_addr: 0.0.0.0:3024
  public_addr: bastion.example.com:443
  https_keypairs: []
  acme: {}

配置文件里cluster_name是集群标识，tokens里的随机字符串用于节点加入认证，务必替换为足够长的随机值。public_addr需要替换为堡垒机的实际域名或公网IP。如果使用IP而非域名，Teleport会自动生成自签名证书，浏览器访问时会有安全提示，但功能不受影响。生产环境建议配置一个真实域名并启用ACME自动签发证书。

四、启动并初始化堡垒机

配置文件就绪后，启动Teleport：

sudo systemctl enable teleport
sudo systemctl start teleport

首次启动后，需要创建本地管理员账户。Teleport使用tctl命令管理用户。执行以下命令创建一个名为admin的管理员，并赋予访问权限：

sudo tctl users add admin --roles=editor,access --logins=root,ubuntu

命令执行后会输出一个URL，在浏览器打开该URL完成密码设置和二次认证绑定。这个admin账户就是堡垒机的第一个管理员。后续所有用户都通过Web界面或tctl创建，不再使用系统账户登录。

五、让目标服务器加入堡垒机管理

目标服务器需要运行Teleport的node服务，并加入到堡垒机集群。在目标服务器上安装Teleport：

curl https://goteleport.com/static/install.sh | bash -s 16.1.0

然后创建节点配置文件/etc/teleport-node.yaml：

version: v3
teleport:
  nodename: web-server-01
  data_dir: /var/lib/teleport
  log:
    output: stderr
    severity: INFO
  ca_pin: ""
  diag_addr: ""
auth_service:
  enabled: no
ssh_service:
  enabled: yes
  labels:
    env: prod
    role: web
proxy_service:
  enabled: no

接下来用加入令牌将节点注册到堡垒机。在堡垒机上生成一个节点加入令牌：

sudo tctl nodes add --ttl=30m --roles=node

命令会输出一个以token开头的字符串。回到目标服务器，用该令牌启动节点服务：

sudo teleport start --config=/etc/teleport-node.yaml --auth-server=bastion.example.com:3025 --join-method=token --token=替换为生成的令牌

验证节点是否成功注册，在堡垒机上执行：

sudo tctl nodes ls

如果能看到目标服务器的主机名和标签，说明节点已加入。此时目标服务器的SSH服务仍然在运行，但后续我们会调整防火墙，只允许来自堡垒机的连接，或者直接关闭公网SSH访问。

六、配置访问策略与权限控制

Teleport的权限控制通过角色（Role）实现。默认角色有access、editor、auditor等，但生产环境需要自定义角色，实现最小权限。例如只允许运维人员以ubuntu用户登录web服务器，不允许登录数据库服务器。创建一个角色文件web-ops.yaml：

kind: role
version: v5
metadata:
  name: web-ops
spec:
  allow:
    logins: ["ubuntu"]
    node_labels:
      role: "web"
    rules:
      - resources: ["session"]
        verbs: ["list", "read"]
  deny:
    logins: ["root"]

应用角色：

sudo tctl create -f web-ops.yaml

然后将该角色分配给具体用户：

sudo tctl users update username --set-roles=web-ops

这样用户登录堡垒机后，只能看到带有role=web标签的服务器，并且只能以ubuntu用户连接。即使该用户知道root密码，也会被Teleport拒绝。

七、启用会话审计与录像回放

Teleport默认会记录所有SSH会话的输入输出，并以结构化格式存储在堡垒机的/var/lib/teleport/log目录。管理员可以通过Web界面查看实时会话，也可以回放历史会话。要确保审计功能正常工作，需要在auth_service配置中明确开启会话录制：

auth_service:
  session_recording: "node-sync"
  proxy_checks_host_keys: yes

session_recording设置为node-sync表示在节点端同步录制，适合大多数场景。如果堡垒机磁盘空间有限，可以考虑将录制模式改为proxy-sync，在代理端录制。审计日志包含用户身份、登录时间、执行的每一条命令、文件传输记录等。对于合规要求较高的场景，还可以将审计日志定期导出到外部存储，防止堡垒机自身被攻破后日志被清除。

八、关闭目标服务器的直接SSH访问

节点加入Teleport后，目标服务器不再需要向公网开放SSH端口。修改目标服务器的防火墙规则，只允许来自堡垒机内网IP的22端口访问，或者直接关闭22端口。如果目标服务器和堡垒机在同一内网，可以配置安全组只允许堡垒机IP访问22。如果不在同一内网，Teleport的反向隧道机制可以让堡垒机通过443端口连接到目标服务器，目标服务器无需开放任何入站端口。这是Teleport相比传统跳板机的一个重要优势。配置完成后，运维人员只能通过堡垒机访问目标服务器，直接SSH连接会被拒绝。

九、日常运维与高可用注意事项

单节点Teleport已经可以满足中小团队的需求，但堡垒机本身成为单点故障后，一旦宕机所有运维操作都会中断。对于核心业务，建议部署至少两个Teleport代理节点，并通过负载均衡器分发443端口的流量。认证服务可以使用Teleport内置的HA模式，需要配置共享存储或使用外部数据库。日常运维中要定期检查节点状态、审计日志存储空间、以及证书有效期。Teleport的短期证书默认有效期为12小时，用户需要定期重新认证，这本身也是一种安全机制。另外要定期更新Teleport版本，社区版更新频繁，安全修复及时。

堡垒机搭建完成后，整个服务器登录链路就变成了：运维人员通过Web界面或tsh客户端登录堡垒机，完成多因素认证，Teleport签发短期证书，用户选择目标服务器发起连接，所有操作被实时录制。目标服务器不直接暴露登录入口，密码泄露或密钥丢失不再导致服务器被直接控制。这套方案在Ubuntu上部署成本低，维护简单，比手动维护跳板脚本和SSH密钥对要可靠得多。