这种循环困境确实让人头大，我来给你几个可行的解决方案——既然服务器是你们自己的，我们可以从系统启动层面突破这个权限限制：

方法一：单用户模式（Debian系通用，最快的方式） #

1. 重启服务器，在GRUB启动菜单出现时（云服务器的话需要通过服务商的控制台进入VNC/远程控制台），选中当前正在使用的内核版本，按e进入编辑模式。
2. 找到以linux开头的那一行，把里面的ro替换成rw init=/bin/bash，如果有quiet、splash这类静默启动参数，也可以删掉，方便看实时输出。
3. 按Ctrl+X或者F10启动系统，这时候会直接进入拥有root权限的shell，不需要输入任何密码。
4. 现在可以着手修复问题了：
   • 先检查su命令的状态：执行which su，如果返回找不到，说明提供su命令的util-linux包可能损坏或被意外卸载，重新安装即可：apt install --reinstall util-linux
   • 把你的SSH登录用户添加到sudoers列表：用visudo命令编辑/etc/sudoers（一定要用visudo，它会检查语法错误，避免你把sudoers搞坏），添加一行你的用户名 ALL=(ALL:ALL) ALL，替换成你实际用SSH登录的用户名。
   • 如果需要临时用root登录SSH（后续建议改回禁止）：编辑/etc/ssh/sshd_config，把PermitRootLogin no改成PermitRootLogin yes，然后重启SSH服务：systemctl restart sshd
5. 修复完成后，执行exec /sbin/init回到正常系统，或者直接输入reboot重启服务器。

方法二：救援模式（单用户模式失效时备用） #

如果单用户模式无法正常启动，试试救援模式：

1. 通过服务器的管理控制台（物理机插安装介质，云服务器在面板里选救援模式）启动救援环境。
2. 救援模式启动后，系统会自动检测并挂载你的系统分区，通常会提示挂载点（比如/mnt/sysimage）。
3. 切换到你的系统环境：chroot /mnt/sysimage，这时候你就拥有了系统的root权限。
4. 重复方法一里的修复步骤：重装util-linux、添加用户到sudoers、调整SSH配置。
5. 修复完成后，输入exit退出chroot环境，再执行reboot重启服务器。

一些注意事项 #

• 操作前如果是云服务器，强烈建议先创建系统快照，避免误操作导致数据丢失。
• 问题解决后，记得把PermitRootLogin改回no，保持服务器的安全性，日常用sudo就足够了。
• 这次升级后su命令丢失，大概率是升级过程中util-linux包被意外覆盖或卸载，重新安装就能恢复。

备注：内容来源于stack exchange，提问作者Matthieu CORMELIER