看起来你遇到的是典型的Windows账户显示名与核心登录账户名不匹配，或是权限同步不及时导致的OpenSSH登录问题，我来逐一解答你的疑问：

1. SSH是如何检查用户名是否存在的？ #

在Windows系统上，OpenSSH的sshd服务验证用户身份时，依赖的是本地安全账户管理器(SAM)中存储的核心登录账户名——这和你通过netplwiz修改的"显示名称"不是同一个东西。

举个例子：你最初的用户名是邮箱前5位，这是SAM里的核心账户名；当你用netplwiz修改新名称时，大概率只改了系统对外显示的友好名称，底层SAM里的核心账户名并没有同步更新。这时候whoami显示的是新的显示名称，但sshd依然在找旧的核心账户名，自然会匹配失败。

另外，sshd还会校验用户是否属于允许SSH登录的用户组（默认是Administrators组，或是你在sshd_config里配置的AllowGroups/AllowUsers列表），如果新账户的权限没有同步更新，也会触发验证失败。

2. 有没有办法用新用户名登录？ #

当然有，这里给你几个可行的解决方案，按优先级排序：

方案1：修改SAM核心账户名（最彻底）

netplwiz经常只修改显示名，没改核心账户名，这才是问题根源。你可以通过本地用户和组工具修正：

• 按下Win+R，输入lusrmgr.msc打开「本地用户和组」
• 展开左侧的「用户」文件夹，找到你的账户，右键选择「属性」
• 在「常规」标签页里，确认「用户名」字段是不是你想要的新名称。如果不是，改成新名称后点击确定
• 打开「服务」（Win+R输入services.msc），找到「OpenSSH SSH Server」，右键选择「重启」
• 之后再尝试ssh NewUserName@127.0.0.1，应该就能正常登录了

方案2：检查并更新OpenSSH的权限配置

如果你的新账户不在允许SSH登录的列表里，也会失败：

• 打开隐藏文件夹C:\ProgramData\ssh，找到sshd_config文件（用记事本或代码编辑器打开）
• 检查是否有AllowUsers或AllowGroups配置项：
  • 如果有，确认你的新用户名是否在列表中，没有的话加上（比如AllowUsers NewUserName）
  • 如果没有这些项，默认允许所有本地用户登录，但要确保你的新账户属于Administrators组
• 修改后保存文件，重启OpenSSH服务生效

方案3：清除OpenSSH缓存（针对缓存问题）

有时候sshd会缓存旧的用户信息，导致新账户无法识别：

• 先停止OpenSSH服务
• 进入C:\ProgramData\ssh文件夹，删除除了ssh_host_rsa_key、ssh_host_ecdsa_key、ssh_host_ed25519_key之外的所有文件（建议先备份）
• 重新启动OpenSSH服务，再尝试登录

方案4：用Microsoft账户邮箱登录（如果你用的是微软账户）

如果你的账户绑定了微软邮箱，直接用邮箱地址作为用户名登录试试：

ssh your_full_email@127.0.0.1

另外你提到新创建的本地账户test能正常登录，是因为创建新账户时，SAM核心账户名和显示名称完全一致，且权限配置默认正确，所以sshd能直接识别。

备注：内容来源于stack exchange，提问作者Shuangcheng Ni