Finalshell连Ubuntu一直提示输入密码？从SSH底层排查到解决

先说一个结论：这个问题大概率不是Finalshell坏了，也不是Ubuntu密码真的输错了，而是整套SSH登录链路里某一环没对上。作为常年用VMware跑Ubuntu、又把Finalshell当作主要SSH工具的人，我至少在三个不同环境里遇到过"一直提示输入密码"的诡异情况。密码明明是对的，点确定之后过两秒又弹一次，循环往复，像极了第一次用SSH时手忙脚乱的样子。

这篇文章就把我踩过的坑、排障的思考过程和最终的解决方案一次性讲清楚。不管你是刚装好Ubuntu虚拟机的新手，还是已经折腾了半天没头绪的老鸟，跟着下面的排查顺序走一遍，大概率能解决。

1. 先搞清楚"一直提示输入密码"背后到底发生了什么

1.1 这个报错场景到底是什么

需要先理解一个基本概念：Finalshell连Ubuntu虚拟机，本质上是在和你虚拟机里的SSH服务（sshd）对话。整个连接过程大致是三层：先建立TCP网络连接，再做SSH协议握手，最后进行用户身份认证。身份认证失败，才会出现反复弹密码框的行为。

大部分人对"一直提示输入密码"的第一反应是密码输错了，于是反复输入、反复弹窗，很快心态就崩了。但实际排障的时候你会发现，这个现象可能由三个完全不同的原因引起：一是SSH服务端根本没启用密码登录，二是客户端根本没把"密码验证"作为登录方式，三是用户的密码状态本身不满足登录条件。三种情况的表象一模一样，但解决路径完全不同。

所以我特别建议遇到这个问题时，先不要急着反复输密码，而是按下面的步骤做一次系统性排查。一次到位，比盲试十次更有用。

1.2 为什么Finalshell的表现形式如此迷惑

Finalshell作为一个图形化SSH客户端，它的缺点是会把很多底层信息"包装"起来。比如你用原生命令行工具 ssh 连接时，如果把日志级别调高，终端里会清晰地打印出"Connection closed by remote host""Permission denied, please try again"这类信息，而Finalshell往往只弹一个模糊的密码框或一个笼统的提示。

这就导致排障信息量不足。我实测下来的经验是：在Finalshell上排查了三十分钟没搞明白的事情，回到命令行用 ssh -vvv 看了一眼日志，十秒钟就定位了。所以本文虽然有大量篇幅在讲Finalshell怎么配置，但真正核心的排障技巧反而是"跳出Finalshell，用原生SSH命令做对照测试"。先别急着嫌弃命令行，这才是快速解决问题的钥匙。

2. 问题一：Ubuntu里SSH服务根本没装或者没起来

2.1 Ubuntu默认确实不装openssh-server

这是绝大多数新手第一次踩坑的根源。Ubuntu的桌面版（Desktop）默认只装了SSH客户端，没有安装SSH服务端。也就是说，你在Ubuntu图形界面里能正常上网、能打开终端，不代表这台机器"开着门"等你远程连接。SSH服务端没有安装时，虚拟机根本没有监听22端口，Finalshell发过去的连接请求会直接失败。

但这里有个迷惑点：有些版本的Ubuntu在提示上不够直观，Finalshell弹的是密码框而不是"连接被拒绝"，导致你以为问题出在密码上。其实服务端压根就没给你认证的机会。

判断方法很简单。在Ubuntu的图形界面里打开终端，执行下面的命令：

bash复制systemctl status ssh

如果提示 Unit ssh.service could not be found，那就是没装。如果看到提示是 inactive (dead)，说明装了但没启动。如果显示 active (running)，服务这一层基本没问题，可以直接跳到下一个排查点。

2.2 检查服务和调整自启动

如果是没安装的情况，直接在Ubuntu终端里安装openssh-server即可：

bash复制sudo apt update
sudo apt install openssh-server

安装完成后，顺手把服务启动并设置成开机自启：

bash复制sudo systemctl start ssh
sudo systemctl enable ssh

这里要插一句很多教程不会强调的坑：Ubuntu默认防火墙可能是关闭的，但如果你之前手动开过ufw，就要注意放行22端口，否则SSH服务明明在运行，外部连接照样进不来。

bash复制sudo ufw allow 22/tcp
sudo ufw reload

安装并启动之后，再用 Finallshell 或命令行试一下连接。如果你看到连接正常进入密码验证阶段，那就说明刚才的根源就是服务端缺失。这一步解决掉的问题，大概能覆盖掉一小半"一直提示密码"的求助帖。

3. 问题二：sshd_config把密码登录给关了

3.1 大概率是PasswordAuthentication no

如果你确认ssh服务在运行，却仍然反复被要求输入密码，那就要看看sshd的配置文件里是否把密码认证关掉了。文件名是 /etc/ssh/sshd_config。

比较常见的一种情况：你在网上看教程时，有人为了"安全加固"建议你关闭密码登录、只保留密钥登录。结果你按教程操作到一半，密钥还没配好，密码登录已经关了。于是自己把自己锁在门外，还以为是密码输错了。

需要重点关注三个配置项：

如果你看到 PasswordAuthentication 这一项是 no，或者被某个 include 文件覆盖成 no，那就会导致"输多少次密码都没用"的情况。

这里要特别提醒一个细节：新版Ubuntu的sshd_config文件里，很多配置项默认是被注释掉的。被注释意味着使用系统内置默认值。而不同版本Ubuntu的默认值不完全一样。所以判断配置项是否生效，不能只看这一行存不存在，要看"实际生效值"是什么。

3.2 手把手改配置并重启服务

操作我之前都是这么做的。先备份，再修改：

bash复制sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

找到下面两行，确认或修改为：

text复制PasswordAuthentication yes
PermitRootLogin yes

我个人的建议是：如果你只是在虚拟机里测试用，PermitRootLogin 可以设为 yes。但如果你这台机器未来要暴露到公网，还是保持默认的 prohibit-password 更稳妥，然后用普通用户登录。

改完之后重启SSH服务：

bash复制sudo systemctl restart ssh

这里有一个常见的操作误区。很多人改完配置之后不重启服务，然后反复试密码，自然一点变化都没有。另外，如果你修改了主配置文件，但 /etc/ssh/sshd_config.d/ 目录下有其他 .conf 文件，Ubuntu会在主配置里引入它们，这些文件里的优先级设置可能会覆盖你的修改。排查时别忘了看一眼这个目录里的配置。

4. 问题三：用户名和密码本身有猫腻

4.1 root用户默认没有密码

这是另一个高频翻车点。Ubuntu系统默认的root账户是被锁定的，也就是说安装系统时设置的那个用户是普通用户，它可以通过sudo提权，但root本身没有可用密码。

如果你在Finalshell里填写的用户名是root，并且试图用安装系统时设置的密码登录，系统会一直认证失败，但界面表现同样是"不断弹密码框"。从运维角度看这是很反直觉的，因为Windows或者旧版Linux发行版装完系统之后root就能直接登录，但Ubuntu默认不是这个逻辑。

解决方案有两个。方案一：用安装时创建的普通用户登录Finalshell，需要权限时再在命令里加sudo。方案二：如果你非要用root直连，先在Ubuntu图形界面或普通用户SSH会话里执行：

bash复制sudo passwd root

按提示设置一个root密码，然后用这个密码在Finalshell里连接root。没有执行过这一步，root永远登不上去。

4.2 复制粘贴带来的换行符陷阱

这一条看起来特别基础，却是我见过最多人哭笑不得的原因。

很多教程里会展示密码输入框，读者看了之后觉得很好办，直接复制粘贴就完事了。问题在于：你在Windows下从网页或文档里复制密码时，有时候会连带复制一个换行符或空格。粘贴到Finalshell密码框里之后，肉眼看不出区别，但提交给服务端的字符串已经不对了。

这种场景下的表现非常迷惑：密码正确率极高，但服务端收到的密码一直多一个隐藏字符，于是反复弹窗。我的处理方式是：先在本地文本文件里输入一次密码，再对照提示符到日志里验证，甚至可以先改用原生命令行测试连接（命令行里粘贴密码后按回车，感官上更直接）。

还有一个变体，就是大小写或特殊字符被输入法自动"纠正"了。比如某些输入法在英文模式下输入逗号和句号时，会输出中文标点。密码里只要混入一个全角字符，整个认证就废了。遇到这种情况，连接前先确认一下输入法状态。

4.3 密码特殊字符要注意

Ubuntu的密码理论上可以包含各种特殊字符，比如 @ 或 #。这类字符在交互式密码输入时通常没问题，但如果你的Finalshell配置里悄悄把密码存进了会话文件，某些字符可能被当作特殊符号处理，导致实际提交的密码被截断。

我遇到过一位朋友的案例：密码里有美元符号 $，他确认在Ubuntu本机可以登录，但Finalshell始终提示密码错误。最后把密码改成不含特殊字符的组合，立刻连接成功。这说明某些客户端在"保存密码并自动登录"的场景里对特殊字符处理得不够友好。

如果你的密码必须包含特殊字符，最简单的办法是先用命令行ssh手工验证一次，确认服务端认证逻辑没问题，再看Finalshell侧是否有密码自动填充相关的设置开关。

5. 问题四：Finalshell会话配置里的几个致命细节

5.1 登录方式选项和保存密码

Finalshell新建会话时，认证方式默认可能有几种选项，包括"密码"和"公钥"。如果你之前在这个会话上做过密钥登录的实验，会话配置里可能还留着密钥认证的配置，导致连接时Finalshell优先尝试公钥方式，而不是密码方式。

这就会造成一个现象：明明配好了密码，页面也弹出密码框，但点到确定后仍然进不去。因为Finalshell可能拿着密钥去找服务端，没找到匹配的密钥，认证交互就中断了。

新建会话时注意检查认证方式那一栏，确认勾选的是"密码"而不是"公钥"。如果是已存在的会话，右键编辑连接，把认证方式切回去。同时，如果你不想每次连接都重新输入密码，在连接配置里找到"保存密码"或"记住密码"的选项勾上。不勾选的话，即使密码完全正确，每次重连都会再次弹框，容易被误认为"一直提示输密码"。

5.2 端口和IP是否填对

Ubuntu的SSH服务默认端口是22。绝大多数情况下，你不需要改这个数字。但如果你之前为了"安全"修改过SSH端口（比如改成2222），却在Finalshell里仍然填22，那么连接请求会发到一个根本没有服务的端口上。

这种情况在Finalshell里的表现通常不是直接报"连接失败"，而是一段时间的等待后重新弹密码框。原因是连接超时或握手重置，客户端被带回登录界面。排障时先确认端口号是否与服务端实际监听端口一致。

虚拟机IP同样是个变量。如果你用的是VMware默认的NAT网络，虚拟机的IP地址可能是通过DHCP动态分配的。这意味着今天连的IP和明天重启后的IP可能不一样。如果Finalshell里保存的是旧IP，自然会连不上。

在Ubuntu终端里查看当前IP：

bash复制ip addr

找到类似 192.168.x.x 的地址，用这个地址去更新Finalshell里的会话配置。另外，常见的还有把虚拟机IP填成宿主机IP的，这种低级错误造成的现象也是"连不上却又不知道为什么"。填IP之前先确认你写的是虚拟机的地址，不是Windows宿主机的地址。

6. 附加排查：改了配置还是不行怎么办

6.1 查看服务端认证日志

如果前面几步都做完了，仍然一直提示输入密码，那就要去服务端日志里找线索。Ubuntu的SSH认证日志一般可以通过journalctl查看：

bash复制sudo journalctl -u ssh -f

然后在连接的另一端用Finalshell触发一次登录，观察终端里实时日志输出。常见的几类关键字：

• Failed password for invalid user：表示用户名本身不存在
• Failed password for root：表示密码不正确，或root未设置密码
• Connection closed by authenticating user：表示认证交互中断，往往和客户端配置有关
• Connection refused：表示服务没起来，或者端口不对

日志能直接告诉你服务端到底在哪个环节拒绝了连接。这个方法比在客户端反复试错高效得多。

6.2 用原生ssh命令做对照测试

这是我最推荐的终极判断法。打开Windows的PowerShell或CMD，或者直接在Ubuntu里回环测试，执行：

bash复制ssh -vvv 用户名@虚拟机IP

把日志级别提到最高。如果命令行能顺利登录，说明服务端一切正常，问题出在Finalshell这个客户端上，继续检查会话配置即可。如果命令行也登录失败，则说明服务端或账号状态有问题，跟着日志继续追。

还可以显式关闭密钥认证，只测密码：

bash复制ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password 用户名@虚拟机IP

这个命令的意义在于排除干扰项。很多服务端配置了密钥优先，如果密钥不匹配再回退到密码，而回退过程可能因为配置问题失败。用这个命令强制使用纯密码认证，就能看出密码认证本身是否可用。

我在实际排障中无数次靠这个方法定位问题。有一次服务端、账号全都正常，就是Finalshell会话里的认证方式残留了公钥设定，用命令行一对比，立刻真相大白。

6.3 检查known_hosts之间的冲突

还有一个容易被忽略的点：如果你以前用命令行SSH连过这台Ubuntu，Windows下的家目录里会记录一个known_hosts文件。如果Ubuntu重装过系统或SSH密钥重新生成过，已知的主机指纹就会对不上。

正常情况下客户端会警告"REMOTE HOST IDENTIFICATION HAS CHANGED"，提示你清除旧记录。但有些版本的客户端配置过于激进的自动处理策略，会导致认证阶段异常中断。处理方法是找到用户目录下的 .ssh/known_hosts 文件，删掉或注释掉对应IP的那一行。

Finalshell本身也有会话缓存，如果你改过虚拟机的主机名或IP，建议删除旧会话重新建一个，避免旧缓存干扰。这类问题不算高频，但一旦碰上就会让人怀疑人生。

7. 高频问题速查表

上面的内容写了很多，为了让你之后排查起来更顺手，我把最常见的场景整理成一张速查表，问题现象、可能原因、解决方法放到一起，直接用即可。

这张表是按照出现频率从高到低排的。实际处理时建议对应表格从上往下查，大部分问题在第三行之前就能解决。真正走到最后一行的情况，多半是服务器被多次改过配置，现场环境复杂，需要耐心把每层配置逐一确认。

说实话，Finalshell和虚拟机Ubuntu的这套组合，只要把"SSH服务在跑、端口对得上、密码认证开着、用户名密码正确"这四件事确认完，基本不会出大问题。反复弹密码框只是表象，真正的问题往往藏在某个你觉得"不可能出错"的小地方，比如认证方式、特殊字符、旧配置覆盖新配置。

我在实际操作中养成了一个习惯：排障时优先改一个变量、测一次连接，而不是同时改多个设置。哪怕方向猜错了，至少能通过排除法缩小范围。你如果现在正卡在这个问题上，按文章顺序逐项对照检查一遍，不用急着看别的教程，更不用重装系统。大多数情况，十到二十分钟内就能找到真正的原因，然后一劳永逸。