Finalshell连接Ubuntu虚拟机反复提示输入密码？从SSH到网络全链路排查

Finalshell连接VMware里的Ubuntu虚拟机，密码输了一遍又一遍，界面上始终是那句"请输入密码"，这种问题我帮人远程看过很多次。表面看是密码不对，实际原因五花八门，十次里有八次甚至跟密码本身一点关系都没有。

先说结论：最常见的场景是这样的——刚装完Ubuntu虚拟机，在VMware的窗口里能正常登录桌面，然后打开Finalshell想远程操作，主机填了、端口填了22、用户名密码也都填了，点连接，却反复弹出密码输入框，甚至显示"认证失败"。这时候大多数人会陷入一个死循环：换个密码试、再试、再换，越试越急，越急越错。

但真正的问题是，你根本不了解Finalshell这个"提示输入密码"背后，到底卡在哪一个环节。下面我按从服务端到客户端的顺序，把完整排查链路过一次。

1. 现象描述与问题边界：先确认你踩的是哪一个"密码循环"

在动手改任何配置之前，先搞清楚一件事：你遇到的"一直提示输入密码"，具体是下面哪一种表现？因为Finalshell界面上几种不同的提示，对应的排查方向完全不同。我实际处理过的类似问题里，至少能分成四种。

1.1 四种典型的"提示密码"现象

标题里"一直提示输入密码"最贴合的是第三种：系统没有立刻断开，而是你输完密码回一个Access denied，然后又弹一次输入框。这种一般卡在认证环节，不是网络层问题。但也不能完全排除第一个坑——很多人以为"提示输入密码"就是"要我输密码"，其实前面还有"连接被拒绝"这种根本轮不到输密码的情况。

1.2 虚拟机里能登录，不代表SSH能登录

这是新手最容易混淆的一点：在VMware桌面里用Ubuntu登录，是"本地登录"，走的是显示器和键盘；而Finalshell连接是"远程SSH登录"，走的是网络和sshd服务。二者虽然共享同一个用户和密码，但完全是两条独立的链路。

本地登录能用，SSH却一直提示密码错误，通常有三个方向的原因：

第一，SSH服务根本不存在。Ubuntu桌面版默认不装openssh-server，只装了客户端，你在虚拟机里能正常登录是因为本地登录用不到SSH，所以一点感知都没有。

第二，密码策略差异。Ubuntu默认安装时创建的普通用户可以密码登录，但root用户没有密码，很多人习惯性地在Finalshell里填root，觉得Linux都是root，结果怎么输都是错。这个原因占比极高，后面专门讲。

第三，SSH服务端配置里禁用了密码认证。你填的密码再对，服务器根本不接受密码这种方式，自然永远循环。

所以排查的第一步，不是反复试密码，而是确认问题到底出现在哪一环。下一节就从虚拟机内部开始，把服务端情况摸清楚。

2. 服务端排查：SSH服务是否真的活着，以及"ssh"和"sshd"的命名坑

这一节必须在虚拟机里操作。如果你现在连虚拟机的桌面都进不去，先回到VMware的控制台，用安装时创建的用户名和密码登录进去。

2.1 三步确认SSH服务状态

在虚拟机终端执行：

ps -ef | grep ssh

看输出里有没有/usr/sbin/sshd这个进程。如果有，说明服务在跑；如果没有，大概率是没安装或没启动。这里有个专属于Ubuntu的命名坑：Debian系操作系统里，SSH服务对应的systemd服务名叫ssh，不是很多教程里写的sshd。所以：

sudo systemctl status ssh

如果提示 "Unit ssh.service could not be found"，直接安装：

sudo apt update sudo apt install openssh-server

安装完成后：

sudo systemctl enable --now ssh sudo systemctl status ssh

看到 active (running) 就说明服务活了。然后再确认端口监听：

sudo netstat -tlnp | grep 22

正常会看到 sshd 监听 0.0.0.0:22。如果提示找不到netstat，说明没装net-tools，用Ubuntu自带的ss命令即可：

sudo ss -tlnp | grep :22

如果端口没有监听，检查一下是否有AppArmor限制。Ubuntu下这个命令值得看一眼：

sudo aa-status | grep ssh

多数情况下AppArmor不会拦SSH，但如果你是从网上下的特殊改版系统，这一步能省去很多猜疑。

2.2 修改sshd_config的隐藏雷区：Windows编辑器的换行符

服务没装好，装上就能通，这不是难点。真正让人抓狂的是另一个坑：你在Windows上用记事本或某些编辑器打开过sshd_config，改完保存，然后把文件传回Linux。这个文件的行尾是Windows的CRLF，而Linux的sshd启动时对这个很敏感，轻则警告，重则直接拒绝加载配置。

我遇到过一例：用户从Windows编辑sshd_config，把PermitRootLogin改成yes，保存后上传覆盖，然后执行 systemctl restart ssh，结果服务直接起不来了。查了半天，就是文件行尾问题。

所以改这个文件的正确姿势是，在Linux终端里用nano或vim改：

sudo nano /etc/ssh/sshd_config

改完以后，先做语法验证：

sudo sshd -t

没有任何输出说明语法OK，有报错就按提示改。确认无误再重启服务：

sudo systemctl restart ssh

注意：这个"先验证后重启"的习惯比记住任何配置项都重要。sshd_config写错一个值，可能直接导致你把自己锁死。

还有一个Ubuntu特有的大坑，藏在/etc/ssh/sshd_config.d/目录里。新版Ubuntu会在这个目录下放一个50-cloud-init.conf，它里面的配置优先级比主配置高。如果你在主文件里改了PasswordAuthentication yes，但drop-in文件里写的是PasswordAuthentication no，那实际生效的依然是 no。我在线上环境见过不少次这种"改了没反应"的情况。

检查方法：

ls /etc/ssh/sshd_config.d/ cat /etc/ssh/sshd_config.d/*.conf

想直接看最终生效的配置，用这个命令：

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'

sshd -T会把当前实际加载的配置打印出来，所有覆盖关系一目了然。这个命令是我排查SSH问题时的首选工具，比只看主配置文件靠谱得多。

2.3 查看认证日志，让系统告诉你到底哪里不对

如果你不想瞎猜，系统其实已经把答案写在日志里了。Ubuntu SSH认证日志默认写在/var/log/auth.log，实时跟一下：

sudo tail -f /var/log/auth.log

然后回到Finalshell再试一次连接，切回终端看新增日志：

• 如果看到Failed password for root from 192.168.x.x port 22 ssh2，说明密码确实没通过验证，也可能是root账户被禁密码登录。
• 如果看到Connection closed by authenticating user root ... [preauth]，说明sshd在认证前就直接关了连接，这通常跟PermitRootLogin配置有关。
• 如果看到Connection reset by 192.168.x.x，一般是客户端断开或网络问题。

日志是排错的照妖镜，能帮你把"服务端问题"和"客户端问题"干净地切开。我看到有太多人在Finalshell界面里瞎试密码十分钟，不如打开一个终端看日志来得快。

3. 最大元凶：Ubuntu默认禁用的root账户与PermitRootLogin的三种取值

如果服务正常、日志也显示连接进来了，但密码就是过不去，那十有八九是本章的问题。我甚至可以直接说：这个标题的场景下，一半以上的原因就是"用root登录，而Ubuntu默认不允许root用密码登录"。

3.1 为什么你输root密码永远是错的

Ubuntu在安装过程中不会让你设置root密码，而是创建一个具有sudo权限的普通用户，root账户默认是被锁定的——没有密码，无法登录。这是Ubuntu和CentOS非常不一样的地方。CentOS装完你可以直接ssh root加密码，Ubuntu不行。

所以你在Finalshell的用户名一栏填root，无论密码填的是你登录Ubuntu桌面那个密码，还是你sudo时用的那个密码，都是错的。因为root账户本身就没有密码，sshd验证时永远返回失败。

这就能完美解释标题里的现象：为什么虚拟机里能登录桌面、能正常使用，Finalshell却永远循环"输入密码"。

解决方案有两个方向：

1. 老老实实用普通用户登录——安装Ubuntu时创建的那个用户名，密码就是登录桌面的密码。
2. 如果你确实需要root远程登录，给root设置密码并打开PermitRootLogin。

我个人推荐第一种，但很多运维场景确实需要root权限，所以下面把两种都说透。

3.2 PermitRootLogin三值详解与正确改法

/etc/ssh/sshd_config里有一个参数叫 PermitRootLogin，常见取值：

Ubuntu 22.04之后默认是 prohibit-password，这正是很多人填了正确的root密码也无法登录的原因——sshd的逻辑是：你是root，我允许你通过密钥进来，但你输入的密码我不会接受，直接拒绝。

如果你确认要开放root密码登录，把这一行改成：

PermitRootLogin yes

然后按前面说的，先sudo sshd -t验证，再sudo systemctl restart ssh。改完后先用普通用户登录测试没问题，再试root。

提示：开放root密码登录意味着任何能扫到你22端口的人都可以对着root暴力尝试密码，风险需要自己承担。虚拟机在NAT网络下还好，如果是桥接模式直接暴露在局域网里，root弱密码就是给自己装了一颗雷。

3.3 普通用户登录的成功路径

我更推荐的方式：依然用普通用户登录，需要root权限时在Finalshell的终端里执行：

sudo -i

输入当前用户的sudo密码就能切到root。这样既满足远程管理需求，又不用真正开放root的SSH登录，安全性和便利性都在。

如果觉得每次sudo都要输密码麻烦，可以配置免密sudo，但也要考虑风险权衡，不建议新手直接照抄。普通的做法是保持sudo密码验证，因为Finalshell连上后你本来就需要输一次密码才能sudo，只是比root多一步而已。

另外，如果你的目标只是跑命令行、装软件、起服务，普通用户的权限已经足够。只有改系统级配置、装驱动这类操作才需要sudo，所以普通用户登录并不会明显拖慢你的工作效率。

4. 网络链路：Ping得通不代表22端口通

前面讲的是"能连上但认证失败"的情况。还有一种常见情况是"压根没连上，但Finalshell一直转圈或提示超时"，有些版本会反复弹输入框，让用户误以为是密码问题。

4.1 VMware三种网络模式下的IP常识

VMware给虚拟机提供了几种网络模式，日常用得最多的是NAT和桥接。

• NAT模式：虚拟机在你物理机的私有网段里，由VMware虚拟网关转发。一般虚拟机IP是 192.168.x.x 网段，和物理机之间的互通靠VMware虚拟网卡VMnet8。
• 桥接模式：虚拟机直接接入物理网络，它拿到的IP和你的路由器、物理机处于同一个网段。
• 仅主机模式：只有虚拟机和你电脑能互通，虚拟机不能访问外网。

很多人的Finalshell连不上的根源，是压根不知道自己虚拟机IP是什么，在Finalshell里填了一个过期的、或者脑子里想象的地址。所以第一步永远是到虚拟机里查IP：

ip addr

eth0或ens33那个网卡的inet v4就是你的目标IP。Ubuntu 24.04里常见的是ens33这种命名，不要死记eth0。

然后回到Windows命令行：

ping 虚拟机IP

能ping通说明二层三层网络没问题，继续查端口。ping不通就要回头查VMware虚拟网络编辑器、虚拟机网卡连接状态，还要确认物理机防火墙是否拦截ICMP。

4.2 防火墙和22端口的前世今生

Ping通了但Finalshell连不上，基本就是TCP 22端口被拦。Ubuntu桌面版自带的UFW防火墙默认可能是关闭的，但如果你按教程开过防火墙，就要确认有没有放行SSH：

sudo ufw status sudo ufw allow 22/tcp

如果你看到状态是 inactive，那就不是UFW的问题，转而检查物理机Windows Defender防火墙。某些安全软件会把Finalshell的入站连接拦截，但在NAT模式下，实际上是虚拟网关在连接虚拟机，Windows防火墙一般不拦这个方向。真正该盯的是虚拟机自己的防火墙规则，比如你配置了nftables或iptables：

sudo iptables -L -n | grep 22

另外还有一种不太容易想到的情况：虚拟机用了NAT，但VMware的NAT服务（VMware NAT Service）被手动停掉了。在Windows服务管理器里可以看到这个服务，如果状态不是"正在运行"，虚拟机和外网/物理机的通信会异常。这在系统优化、清理软件之后偶发，值得留个心眼。

4.3 稳定连接从固定IP开始

网络通了之后，还有一个尤其烦人的问题：虚拟机IP会变。你这次连上是192.168.137.130，过几天开机变192.168.137.145了，Finalshell里存的还是旧IP，连不上你也意识不到，第一反应往往是"密码又错了"。

所以在一切连接正常之后，建议给虚拟机配置一个固定IP，或者至少在VMware里为这台虚拟机设置DHCP保留。Ubuntu 24.04用的网络管理工具是netplan，我一般建议直接在netplan配置文件里指定静态IP。先看当前配置：

ls /etc/netplan/ cat /etc/netplan/01-network-manager-all.yaml

典型的Netplan配置增加addresses和routes，关掉DHCP：

network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: false addresses: - 192.168.137.130/24 routes: - to: default via: 192.168.137.2 nameservers: addresses: [223.5.5.5, 8.8.8.8]

然后：

sudo netplan apply

注意网关地址要填VMware NAT设置的网关，我写的192.168.137.2只是举例。实际以你VMware虚拟网络编辑器里的NAT设置页为准。设置前先确认DHCP下网关是多少，再抄进去，别凭感觉填。

5. Finalshell客户端侧的暗坑：密钥缓存、特殊字符与日志定位

服务端一切正常，网络也通，密码也肯定是对的，但Finalshell还是反复弹密码。这时候问题掉头指向客户端本身。客户端的问题不像服务端那么显性，但经常能磨死人。

5.1 认证方式被"记住"了，改密码也没用

Finalshell支持密码登录和密钥登录，而且会在连接配置里记住你的认证方式。一个非常常见的场景：你之前用密钥登录过，后来把系统的密码改了，或者把密钥删了，又或者换了新系统重装了Ubuntu，但Finalshell里那个连接配置仍然保留着"使用密钥"的选项。

这时候你即使把密码栏改成新密码点了保存，实际连接时Finalshell仍会优先尝试密钥认证，密钥认证失败后，又因为没有明确允许密码认证，直接表现为一直让你输密码，输对了也白搭。

对策：编辑连接配置，找认证方式那一栏，确认选的是"密码/口令"，而不是"密钥"。如果你勾选了保存密码，还要检查保存后的用户名是不是带上了多余空格或域名前缀。

我还遇到过：用户复制了别人的连接配置，主机名和用户名都带了奇怪的尾巴，比如用户名是ubuntu@localhost，当然登录不进去。Finalshell里用户名就填纯正的用户名，主机名也不要带端口和路径。

5.2 密码里的特殊字符和输入法

第二个客户端侧的大坑是密码本身。如果你的Ubuntu安装密码包含特殊字符，比如$、"、'、#这类，在Finalshell的密码框里直接输入一般没问题，但如果走了"配置里的密码模板/变量"，或者从其他工具导出的配置，这些字符可能被转义，实际发送的密码和真实密码不一致。

还有输入法问题。Windows下如果你开着中文输入法，半角/全角状态没切对，输入数字和字母时可能出现全角符号，密码里如果有符号就直接错位。我习惯上仍然建议：排除配置问题时，重新手动输入一次密码，别用复制粘贴，避免隐藏字符跟着进去。

如果口令里有大写字母、小写字母、数字和符号组合，建议先在虚拟机里确认密码能记住，比如用当前用户的密码执行一次sudo，确认记忆中的密码确实是"当前正确的那个密码"。很多时候用户以为的密码和实际系统里的密码有偏差，纯粹是记忆问题，而不是技术问题。

5.3 Finalshell日志怎么读

如果以上都排除，还有一个终极手段：看Finalshell自己的日志。Windows下日志目录一般在：

%APPDATA%\FinalShell\logs

如果找不到，在FinalShell安装目录下找logs文件夹。里面按日期存放着连接日志。打开对应时间的日志，搜索你连接的IP或用户名，会看到类似：

[ssh] authentication failed [ssh] Permission denied (publickey,password)

如果日志显示 authentication failed，基本就是用户名密码或配置问题。如果显示的是 timeout 或 connection reset，那问题在网络层。这样就能精确地把问题定位到哪一侧，不用猜来猜去。

Finalshell的日志是普通文本文件，用记事本就能打开，不用装任何额外工具。我在定位"反复提示密码"的时候，习惯同时开虚拟机里的auth.log和Windows下的Finalshell日志，两边一对照，两三分钟就能找到根因。

6. 从源头根治：给虚拟机SSH配一套长期好用的方案

排查方法说完了，下面是总结性的最佳实践。与其每次重装虚拟机都踩一遍"密码循环"的坑，不如在第一次配置时就把SSH环境弄利索。

6.1 用普通用户+sudo替代root密码登录

我自己的习惯是：Ubuntu虚拟机装完之后，第一件事就是装openssh-server，然后创建一个专门用于远程登录的普通用户，比如叫dev：

sudo useradd -m -s /bin/bash dev sudo passwd dev sudo usermod -aG sudo dev

然后远程登录一律用这个dev用户，不再用root。日常管理需要管理员权限时，登录后执行sudo -i。这样即使密码防不住暴力破解，破坏者也拿不到root，损失可控。

如果实在需要root远程登录，也要给root设置足够强的密码，再打开PermitRootLogin，并建议配合防火墙限定来源IP：

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

这条规则的意思很明确：只允许局域网内IP访问22端口，外部扫描器连敲门的机会都没有。

6.2 配置免密登录，彻底告别"输入密码"

如果你觉得密码登录太折腾，就上SSH密钥。在Windows端用命令行生成密钥对：

ssh-keygen -t ed25519 -C "vm-ubuntu"

然后手动把公钥内容追加到虚拟机的 ~/.ssh/authorized_keys 里。如果没有ssh-copy-id，就直接编辑：

mkdir -p ~/.ssh echo "ssh-ed25519 AAAA...你本地的公钥" >> ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys

接下来在Finalshell的认证方式里选择"密钥"，把私钥路径配上。之后连接就不再需要密码，连"一直提示输入密码"这个问题的存在基础都消失了。

不过要注意：密钥文件的权限也很关键。私钥在Windows下如果被其他用户可读，有些SSH客户端会拒绝加载，Finalshell对此相对宽松，但最好还是通过右键属性里的安全设置，配置成只有当前用户能访问。

6.3 日常排错工具箱

最后把定位这类问题常用到的命令整理成一张表，方便你存下来当备忘录：

用这套流程，从"服务端服务"到"认证配置"到"网络"再到"客户端设置"，每个环节都有一句命令能给出答案。我实际排查过的类似问题里，最快的记录是两分钟——点了连接，看一眼日志，发现是root被禁密码登录，切换到普通用户立刻通过。

有人可能觉得"一直提示输入密码"是个小case，但就是这么个小问题，卡住新手上手Linux的情况太多了。希望这篇文章能帮你一次走通整个排错链路，以后不管遇到Finalshell，还是换成别的SSH工具，思路都是通用的：服务有没有活、认证允不允许、网络通不通、客户端有没有自作主张，按这个顺序，问题基本无所遁形。

最后再分享一个我自己的习惯：新装完系统第一次通过Finalshell连接之前，先在虚拟机终端里执行一次ssh localhost。如果能登录成功，说明本机SSH服务没问题、用户名密码也没问题；如果这一步都提示密码失败，那就先在虚拟机里解决用户密码问题，再回头检查Finalshell。这个习惯帮我省了太多无谓的排查时间，也分享给你。