ftp服务器su无权访问，绝大多数原因是FTP登录分配了受限Shell与su的PAM校验冲突所致。换句话说，这不是su命令本身失效，而是你的会话从一开始就不具备执行su的资格。
先查登录Shell：ftp服务器su无权访问的根源
su命令之所以拒绝服务,核心逻辑是：它只信任/etc/passwd里登记的Shell类型，FTP服务器为了让普通账号只能上传下载、不能登录终端，通常会把用户的Shell设置成/sbin/nologin或/bin/false。
当系统执行su命令时,PAM模块会严格核对目标Shell是否在/etc/shells文件中，如果不在，直接返回Permission denied，这就是ftp服务器su无权访问的第一道铁闸。
用一行命令快速定位：
getent passwd ftpuser
输出末尾的/sbin/nologin就是罪魁祸首，行业共识认为，FTP服务默认禁用Shell是安全基线，不是故障。
vsftpd的userlist与Shell双重拦截
绝大多数linux服务器ftp权限管理问题,都出在vsftpd的配置文件里，它同时存在两个神秘的名单，叫user_list和ftpusers，很多人傻傻分不清：
/etc/vsftpd/ftpusers：硬性黑名单，写在里面的用户永远无法登录FTP/etc/vsftpd/user_list：软名单，行为由userlist_deny参数决定
当userlist_deny=YES时，user_list变成黑名单，当userlist_deny=NO时，它反而变成白名单，只有名单内的用户能登录，很多人踩的坑是：把用户从ftpusers删了，却没注意user_list里的残留记录，导致登录时直接收到vsftpd 550错误：Permission denied。
排查vsftpd 550错误的实操路径
# 1. 检查两个名单是否残留目标用户 grep -E "ftpuser|admin" /etc/vsftpd/user_list /etc/vsftpd/ftpusers # 2. 确认PAM认证模块没有额外限制 cat /etc/pam.d/vsftpd # 3. 查看安全日志，定位拒绝原因 tail -50 /var/log/messages | grep vsftpd
日志里出现PAM 1 more authentication failure或user ftpuser: could not get shadow information
，就说明卡在PAM校验环节，不是密码错误。
vsftpd登录后无法su切换的三种修复方案
临时调整用户Shell（低危，仅测试）
如果只是调试环境用,可以临时给FTP用户分配真实的bash登录权限：
usermod -s /bin/bash ftpuser echo "/bin/bash" >> /etc/shells
改完后重新登录FTP,再执行su - root。注意：这将允许该用户SSH登录服务器，生产环境务必别这么干。
保留nologin，改用虚拟用户映射（推荐）
vsftpd支持虚拟用户体系,虚拟用户的主目录、Shell全部由配置生成，天然绕开shell限制：
# 在vsftpd.conf中设置 guest_enable=YES guest_username=virtualftp local_root=/data/ftp_site
这样登录的会话是虚拟ftp用户的权限,根本不走su对目标用户Shell的检查逻辑因为vsftpd根本没让虚拟用户进/etc/passwd，这是ftp服务器搭建时兼顾安全与效率的通行做法。
为su单独放行PAM规则（高危，需谨慎）
编辑/etc/pam.d/su，将auth required pam_wheel.so use_uid注释掉，或把FTP用户加入wheel组：
usermod -aG wheel ftpuser
这种做法直接绕过了su的组校验,仅适合对安全要求较低的内网环境，业内专家指出，在公网环境开放su切换权限，等于给暴力破解留后门，风险收益比极低。
ProFTPD域名的su问题与chroot权限纠葛
如果你用的是ProFTPD,还会遇到另一种困境：chroot后壳内没有su程序的执行环境。
默认配置下,ProFTPD把用户禁锢在其主目录（类似DefaultRoot ~），而主目录里通常没有/bin/su，也没有动态链接库，执行su时报No such file or directory，不是权限拒绝，而是文件缺失。
解决思路有两种：
- 设置
DefaultRoot /，放弃chroot禁锢，安全性下降 - 在用户目录下复制su及依赖库（用ldd确认），每次更新系统库都要同步
对比vsftpd和ProFTPD的行为差异,你会发现：vsftpd卡在PAM认证，ProFTPD通常卡在文件级隔离
，两者的修复路径截然不同。
检查ProFTPD的RequireValidShell指令
ProFTPD默认要求用户Shell合法,这是它比vsftpd更“挑剔”的地方，配置中找到这一行：
RequireValidShell off
设置为off后,nologin用户也能登录FTP，但同时su的Shell校验依然存在，需要同时解决，多数情况下，改动这里并不能直接让su工作，只能保证你能登录进来调试。
绕开su：用sudo实现linux服务器ftp权限管理的替代方案
与其费劲修复su,不如换一条路，sudo本身就是为“受控提权”设计的，它的权限粒度远比su细致，而且不依赖目标账号的登录Shell。
改造步骤：
# 1. 将FTP用户加入sudo组（以CentOS为例） usermod -aG wheel ftpuser # 2. 执行sudo时跳过tty限制 echo "Defaults:ftpuser !requiretty" >> /etc/sudoers.d/ftpuser # 3. 为该用户单独声明可执行的指令集 echo "ftpuser ALL=(root) /bin/systemctl, /bin/mkdir, /bin/chown" >> /etc/sudoers.d/ftpuser
这样一来,FTP用户虽然无法执行su切换成root，却能通过sudo systemctl restart nginx等命令完成特定运维动作。更改立即生效，无需重启任何服务，而且每条命令都有日志沉淀，比su更透明。
国内外云服务商控制台里的“操作日志”功能，就是这么设计的粗粒度地开放全部权限，不如细粒度地记录每一条指令，据行业调查，带有sudo审计的服务器被攻破后，平均排查时间比开放su权限的服务器缩短约一个数量级。
价格与地域视角下的方案选型
如果你在租用云服务器,会发现开通sudo白名单基本零成本，而误开放su权限导致的安全事件，轻则重装系统，重则入侵潜伏，价格上，一台低配简米云或酷番云轻量服务器年费几百元，但安全整改的人力和时间成本远高于此。
地域差异也值得留意：国内机房对22端口和su操作的审计更严格，租用香港或海外服务器时，服务商普遍默认关闭root远程登录，反而逼着你学会sudo管理，这种外部约束，长期看对服务器稳定是好事。
场景小结：按需选择修复路线
| 场景特征 | 推荐方案 | 风险等级 |
|---|---|---|
| 本地开发环境、测试机 | 临时改Shell+直接su | 低 |
| 生产环境，需要FTP上传但禁止SSH | vsftpd虚拟用户映射 | 低 |
| 生产环境，多个管理员需临时提权 | sudo白名单授权 | 中 |
| 公网环境、无堡垒机保护 | 拒绝su，强制密钥登录+sudo审计 | 高 |
在ftp服务器搭建的早期阶段,就把“FTP专用账号”和“管理账号”完全拆开，是避免后续su权限冲突的最省心策略，哪怕再麻烦，也不要让同一个账号同时肩负文件传输与系统维护两重职责。
核心结论再次强调：ftp服务器su无权访问的本质，是FTP服务为账号配置了非交互Shell，su命令的PAM校验拒绝动用这种会话。 解决路径要么调整Shell配置，要么绕道sudo，后者更符合现代运维习惯。
ftp服务器su无权访问常见问题解答
Q1：vsftpd修改userlist后，为什么用户还是提示550权限拒绝？
A：修改user_list和ftpusers后，必须重启vsftpd服务才会生效。systemctl restart vsftpd之后，再检查/etc/pam.d/vsftpd里是否引用了pam_listfile.so模块，该模块会额外读取一个独立名单，经常造成二次拦截，同时确认allow_writeable_chroot=YES，否则用户被锁定在只能读的目录里，表现为上传失败而非登录失败。
Q2：我是用ProFTPD，FTP用户可以正常登录，但输入su后直接退回FTP提示符，没有任何错误提示，这是为什么？
A：这种情况通常是因为ProFTPD开启了DefaultRoot指令，用户找不到/bin/su这个二进制文件（被chroot隔离了），用ls -l /bin/su看看当前目录是否存在该文件，若不存在，建议把su改名为/usr/local/bin/su并通过ldd复制依赖库，或者在目标目录下创建一个软链接指向宿主机的su，若不想折腾，最省事的方法仍是改用sudo途径。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/581126.html
