Ubuntu服务器默认允许账号在本地终端或通过串口控制台自动登录，这个设置在桌面版上看似方便，但在服务器场景下属于高风险配置。任何能物理接触机器、进入恢复模式或通过带外管理卡挂载虚拟介质的人，都能直接拿到一个已经登录的shell，绕过账号密码验证。更常见的情况是运维人员配置了KVM over IP或者云厂商的VNC控制台，如果自动登录开启，等于把系统的大门敞开了。关闭自动登录不是简单的“取消勾选”，它涉及GDM、LightDM、getty、串口控制台以及systemd服务配置多个层面。
先确认当前系统是否存在自动登录配置
Ubuntu服务器通常没有图形界面，但很多用户会安装最小化桌面环境用于远程管理，或者云镜像默认带了一些显示管理器配置。检查GDM自动登录配置，执行以下命令：
cat /etc/gdm3/custom.conf
如果输出中包含类似下面的内容，说明自动登录已经开启：
[daemon] AutomaticLoginEnable=true AutomaticLogin=ubuntu
这里的AutomaticLoginEnable值为true就是问题所在，AutomaticLogin指定了自动登录的用户名。对于LightDM，配置文件位于/etc/lightdm/lightdm.conf，需要检查[Seat:*]段落下是否有autologin-user和autologin-user-timeout参数。即使没有图形界面，某些Ubuntu衍生版本或定制镜像也可能残留这些配置。
禁用GDM自动登录
编辑/etc/gdm3/custom.conf文件，将AutomaticLoginEnable的值改为false，并注释或删除AutomaticLogin行。完整的修改建议如下：
sudo nano /etc/gdm3/custom.conf
修改后内容应为：
[daemon] # AutomaticLoginEnable=false # AutomaticLogin=ubuntu AutomaticLoginEnable=false
保存后重启GDM服务使配置生效：
sudo systemctl restart gdm3
如果服务器没有运行图形界面，这个服务可能不存在或未激活，但配置文件残留仍然可能在后续安装桌面组件时被读取。因此即使当前未运行GDM，也建议主动检查并修正配置文件。
禁用LightDM自动登录
LightDM在较老的Ubuntu版本或轻量级桌面环境中常见。编辑/etc/lightdm/lightdm.conf，找到[Seat:*]段落，将autologin-user参数注释掉或删除：
sudo nano /etc/lightdm/lightdm.conf
修改前：
[Seat:*] autologin-user=ubuntu autologin-user-timeout=0
修改后：
[Seat:*] # autologin-user=ubuntu # autologin-user-timeout=0
保存后重启LightDM：
sudo systemctl restart lightdm
如果LightDM服务未运行，配置文件中的autologin参数会在下次启动显示管理器时生效，所以提前清理配置是必要的。
检查并禁用TTY自动登录
Ubuntu服务器的文本控制台由getty管理。systemd的getty服务可以通过override配置实现自动登录。检查是否存在自动登录的override文件：
ls -la /etc/systemd/system/getty@tty1.service.d/
如果该目录存在autologin.conf或类似文件，查看内容：
cat /etc/systemd/system/getty@tty1.service.d/autologin.conf
典型的自动登录配置如下：
[Service] ExecStart= ExecStart=-/sbin/agetty --autologin ubuntu --noclear %I $TERM
要禁用TTY自动登录，直接删除该override文件或整个目录：
sudo rm -rf /etc/systemd/system/getty@tty1.service.d/
然后重新加载systemd配置：
sudo systemctl daemon-reload
如果希望保留目录但禁用自动登录，可以编辑autologin.conf，移除--autologin参数及其后的用户名。修改后执行systemctl daemon-reload和systemctl restart getty@tty1。
检查串口控制台自动登录
很多Ubuntu服务器部署在物理硬件上，运维人员会配置串口控制台用于远程带外管理。串口控制台的getty服务同样可能被配置为自动登录。检查串口getty服务配置：
systemctl status serial-getty@ttyS0.service
查看是否存在override文件：
ls -la /etc/systemd/system/serial-getty@ttyS0.service.d/
如果存在autologin.conf，内容通常包含：
[Service] ExecStart= ExecStart=-/sbin/agetty --autologin root --keep-baud 115200,38400,9600 %I $TERM
禁用方法与TTY相同，删除override目录或移除--autologin参数后重载systemd。串口控制台自动登录的风险比本地TTY更高，因为串口往往连接到集中管理设备，攻击者可能通过管理网络漏洞直接获得已登录的root shell。
移除账户免密登录相关PAM配置
有些自动登录并非通过显示管理器或getty实现，而是在PAM层面配置了特定服务的免密认证。检查/etc/pam.d/目录下是否有可疑的pam_permit.so或pam_succeed_if.so条目。例如，某些定制系统会在/etc/pam.d/login中添加：
auth sufficient pam_permit.so
这会导致所有本地登录都不需要密码。检查login和gdm-autologin相关PAM文件：
grep -r "pam_permit" /etc/pam.d/
如果发现pam_permit.so出现在auth sufficient行，应将其删除或注释。正常的Ubuntu系统PAM配置中，pam_permit.so通常只出现在account或session阶段用于特定服务，auth阶段出现sufficient pam_permit.so几乎可以确定是异常配置。
检查cloud-init配置
云服务器镜像经常通过cloud-init在首次启动时创建用户并可能设置自动登录。检查/etc/cloud/cloud.cfg中的users段落：
cat /etc/cloud/cloud.cfg
查找是否存在lock_passwd: false或ssh_pwauth相关的自动登录配置。更重要的是检查/etc/cloud/cloud.cfg.d/目录下的自定义配置，有些云厂商会在其中添加自动登录指令。例如：
grep -r "autologin" /etc/cloud/
如果发现相关配置，删除或修改对应文件。cloud-init配置在实例重启或重新初始化时可能会重新应用，因此需要从源头清理。
验证自动登录是否已彻底关闭
完成上述修改后，重启服务器进行验证。重启后观察本地终端和串口控制台是否直接进入shell。如果服务器在远程机房，可以通过IPMI或iDRAC的虚拟控制台查看启动过程。正常情况应该在登录提示符处停下，要求输入用户名和密码。
另外检查当前运行的服务中是否还有自动登录进程残留：
ps aux | grep agetty
输出中不应包含--autologin参数。如果有，说明某个getty服务仍在以自动登录模式运行，需要进一步排查对应的systemd unit文件。
加固建议：从账户策略层面防止自动登录
除了关闭现有的自动登录配置，还可以通过账户策略增加一层防护。对于不需要交互登录的服务账户，将其shell设置为/sbin/nologin或/usr/sbin/nologin：
sudo usermod -s /usr/sbin/nologin 用户名
对于需要保留登录能力的管理员账户，启用强密码策略并考虑配置SSH密钥认证替代密码登录。同时限制物理控制台访问，确保只有授权人员能接触服务器或带外管理接口。
另一个容易被忽略的点是Ubuntu的恢复模式。即使关闭了正常启动的自动登录，攻击者仍可在GRUB引导菜单中选择恢复模式进入root shell。建议为GRUB设置密码，防止未授权修改启动参数：
sudo grub-mkpasswd-pbkdf2
生成密码哈希后，编辑/etc/grub.d/40_custom文件，添加以下内容：
set superusers="admin" password_pbkdf2 admin 生成的哈希值
然后执行update-grub更新配置。这样即使有人物理接触服务器，也无法通过修改启动参数进入单用户模式或恢复模式。
关闭自动登录是Ubuntu服务器安全加固中基础但关键的一步。很多入侵事件并非来自远程漏洞利用，而是通过管理控制台、带外管理卡或云平台VNC功能直接获得了已登录的shell。逐项检查GDM、LightDM、getty、串口控制台、PAM和cloud-init配置，确保没有任何自动登录入口残留，配合GRUB密码保护和账户策略，才能有效堵住这类本地提权路径。
