云技术博客直接说结论：可以，但强烈不建议作为生产环境的长期方案。
这取决于你指的“新创建用户”是操作系统层面的普通用户（如 Linux 的 useradd 或 Windows 的本地账户），还是云厂商控制台层面的 IAM 子账号。通常大家问这个问题时，指的是前者——即登录服务器后新建一个非 root/Administrator 的用户来日常使用。
下面从技术实现、安全风险和最佳实践三个维度给你拆解清楚。
1. 技术层面：完全可行
在绝大多数云服务器（无论是阿里云 ECS、腾讯云 CVM，还是 AWS EC2）上，操作系统本身并没有禁止长期使用非默认用户登录的机制。
- Linux 系统：你可以用
sudo useradd newuser创建新用户，配置好 SSH 密钥认证（Key-based Authentication），然后禁用 root 远程登录，只允许这个新用户使用密码或密钥登录。这是非常标准的运维操作。 - Windows Server：同样可以创建新的本地管理员或非管理员账户，通过 RDP 连接。
只要你的 SSH 配置（/etc/ssh/sshd_config）或防火墙规则没有硬性限制 IP 或用户名，任何拥有合法凭证的用户都可以长期登录。
2. 为什么不建议“长期使用”？（核心风险）
虽然技术上可行，但在实际生产环境中，长期依赖一个“新创建的普通用户”存在几个隐患：
A. 权限管理混乱（权限漂移）
很多新手创建新用户后，为了方便，直接把这个用户加到 sudoers 列表里，或者甚至把 /etc/sudoers 改得过于宽松。结果就是，这个“新账号”实际上拥有了和 root 一样的权力。一旦该账号泄露，后果等同于 root 泄露。
如果不同开发者、不同运维人员共用同一个“新账号”，审计日志将毫无意义，因为你无法区分是谁执行了 rm -rf / 这种危险操作。
B. 密钥与密码管理的疲劳
- 密码：如果你用密码登录，长期不更换密码容易遭遇暴力破解；频繁更换密码又增加记忆负担。
- SSH 密钥：虽然推荐用密钥，但如果多人共用一个公钥，或者私钥存储不当（比如放在公共 Git 仓库里），安全性极低。
C. 缺乏集中管控
在云原生环境下，理想的状态是身份与资源分离。你自己维护的 OS 用户账号，无法与云厂商的统一身份认证（IAM）、多因素认证（MFA）、操作审计（CloudTrail/ActionTrail）无缝集成。这意味着：
- 你很难做到“离职员工一键回收所有权限”。
- 你很难实时监控谁在什么时间从哪个 IP 登录并执行了什么命令。
3. 正确的做法是什么？
如果你希望安全、规范地长期使用云服务器，建议采用以下架构：
✅ 方案一：基于 IAM 的身份联邦 + 临时凭证（推荐，尤其适合团队协作）
不要直接在服务器上创建长期有效的 OS 用户。而是：
- 在云厂商的控制台创建 IAM 用户（子账号）。
- 配置 MFA（多因素认证）。
- 使用工具如
AWS CLI、Alibaba Cloud CLI或终端插件（如mumu、cloudshell）通过临时凭证登录。 - 如果需要 SSH 登录，可以使用支持 IAM 角色的 SSH 客户端，或者通过跳板机/堡垒机进行统一认证。
✅ 方案二：标准运维流程（个人或小团队适用）
如果你必须使用 OS 用户登录，请遵循以下最佳实践：
- 禁用 root 远程登录：修改
PermitRootLogin no。 - 为每个使用者创建独立 OS 用户：严禁多人共用一个账号。
- 强制使用 SSH 密钥认证：禁用密码登录（
PasswordAuthentication no）。 - 最小权限原则：普通用户只拥有必要权限，需要提权时使用
sudo，并记录日志。 - 定期轮换密钥和密码。
✅ 方案三：使用堡垒机（Jumpserver、阿里云堡垒机等）
这是企业级标配。所有人员通过堡垒机登录，堡垒机对接 LDAP/AD 或云 IAM，实现：
- 统一身份认证。
- 操作录像审计。
- 权限精细化控制。
- 无需在每台服务器上维护大量用户账号。
总结
云服务器可以长期使用新创建的用户账号登录，但这是一种粗放式管理方式。
- 如果是个人学习、测试环境，随便建个用户用着没问题，图省事。
- 如果是生产环境、团队协作，请务必引入堡垒机或IAM 身份管理体系，避免在操作系统层面手动维护一堆零散的用户账号。
记住一句话：在云上，身份（Identity）是新的边界，管好身份比加固服务器本身更重要。