企业官网建设流程全解析

1. 排查前的两个准备：先把“坑”的样子看清楚

1.1 “一直提示密码”其实分三种情况

先别急着改密码。用FinalShell连Ubuntu，输入一次密码就弹回输入框、或者一直提示“认证失败”，这种情况我碰到太多次了。但很多新手不知道的是，“一直提示密码”这句话背后，其实是完全不同的三种故障，对应完全不同的排查方向。

第一种，连上了但立刻被断开，或者密码输进去以后提示Password authentication failed，然后又弹一次密码框。这种情况大概率是用户名、密码本身不对，或者是服务端把密码认证给关了。

第二种，密码框压根不出来，直接提示Permission denied (publickey,password)。这往往说明服务器的sshd_config里只允许密钥登录，密码认证已经被禁用了。这时候你不管输多少次密码都没用，系统根本不会进入密码比对这一步。

第三种，连密码框都见不着，直接提示Connection refused或者连接超时。这不是密码的问题，是网络、端口、防火墙或者SSH服务根本没起来的问题。很多人卡在这一步，还在那里疯狂改密码，方向从一开始就跑偏了。

所以拿到手第一件事：先看清楚你属于哪一种报错，再决定下一步做什么。

1.2 确认服务器IP、用户名、端口有没有填错

确认了报错类型之后，第二件事是核对FinalShell里填的信息。听起来像废话，但我在帮别人排查时发现，绝大多数“密码一直不对”的案例，最后都是信息填错。

登录Ubuntu服务器，先执行whoami看看当前用户名到底是什么。很多人以为root是默认用户名，但Ubuntu默认安装完成后，root账号是没有密码的，你装系统时创建的普通用户才是能登录的账号。你在FinalShell的主机名一栏填root，然后输普通用户的密码，那当然一直提示密码错误。

再看IP。在Ubuntu里执行hostname -I（注意是大写的I），拿到当前主机的IP地址，把这个IP填进FinalShell。如果你连的是云服务器，填的是公网IP，那还要检查云厂商的安全组和防火墙规则是否放行了22端口。如果是虚拟机，还要看虚拟机的网络模式是NAT还是桥接，NAT模式下宿主机能不能直接访问虚拟机IP，这是另一串问题。

端口也要确认。默认SSH端口是22，但如果服务器上有人改过sshd_config里的Port，你客户端还连22，那就连接不上。在Ubuntu里执行ss -tlnp | grep ssh，就能看到ssh实际监听的端口。

还有一个容易被忽视的坑：用户名、IP有没有大小写错误，有没有多余空格。FinalShell里主机名不能带空格，用户名必须原样输入，这些细节看似无所谓，实际上SSH认证里一个字符都不能差。

2. 用命令行直连，把客户端和服务端分开

2.1 手动打一条SSH命令，能暴露大量信息

排查到这一步，如果基本信息都对，但FinalShell还是连不上，那就别再纠结FinalShell了。先在Windows上打开自带的终端（或者Windows Terminal），手动敲一条最原始的SSH命令：

ssh 用户名@服务器IP -p 端口

比如：

ssh sambacai@192.168.1.100 -p 22

第一次连接会提示确认服务器指纹，输入yes回车，然后输入密码。注意：Linux的终端里输密码是没有任何回显的，你敲了密码屏幕上不会显示星号，光标也不动，这是正常现象，不是键盘坏了。输入完直接回车就行。

命令行直连的结果会告诉你很多信息：

• 如果命令行能连上，说明SSH服务、网络、密码全都没问题，问题出在FinalShell这一侧的配置。
• 如果命令行也连不上，提示Permission denied，说明问题在服务端认证设置或者密码本身。
• 如果提示Connection refused，说明ssh服务没起来或者端口不通。
• 如果卡住不动、最后超时，说明防火墙或网络连通性有问题。

这一步是我每次排查FinaShell连接问题的必备动作。它的意义在于把问题一分为二：客户端的问题还是服务端的问题，省得在FinalShell界面里反复试错浪费时间。

2.2 命令行能连但FinalShell不行：问题锁定在客户端配置

如果命令行直连一切正常，但FinalShell用同一组账号密码连不上，这就有意思了。常见原因我在下面列出来，都是实操里真的见过的。

第一个原因是FinalShell密码框里的密码和你以为的密码不一样。很多时候用户开了“记住密码”功能，但保存的还是旧密码，后来在服务器上改过密码，FinalShell里却没更新。你每次都手动输入新密码，但FinalShell实际提交的是保存的旧密码。处理办法很简单：打开连接配置，把密码清掉重新输入一遍，或者直接删掉这个连接配置重新建一个。

第二个原因是密码里的特殊字符。比如密码里有@、#、$、空格、!这些字符，在FinalShell的连接配置里可能被转义或解析出问题。我自己遇到过密码末尾有个空格，在网页系统里改的密码，复制到FinalShell时把换行符也带进去了，结果客户端每次提交的密码长度都比真实密码多一位，怎么连都连不上。后来我改成在FinalShell里逐字手动输入密码才绕过去。

第三个原因是FinalShell版本太老。老版本的FinalShell对OpenSSH新版的某些算法支持不完整，比如新版OpenSSH禁用了ssh-rsa签名算法后，老客户端连不上。这种情况升级FinalShell到最新版，问题立刻消失。

遇到命令行能连、FinalShell连不上的情况，我的建议是：不要在FinalShell里反复改密码了，直接新建一个连接配置，用最简单的用户名和密码，排除掉之前配置里的垃圾数据。

3. 服务端三重检查：从SSH服务、配置到日志

3.1 先确认OpenSSH Server装了没、跑没跑

如果命令行也连不上，那问题大概率出在Ubuntu服务器自己身上。第一件事是确认SSH服务端软件装没装。

Ubuntu有个很坑的地方：默认安装时只装了openssh-client（用来连别人的），没装openssh-server（让别人连自己）。也就是说，你如果安装Ubuntu的时候没有勾选“安装OpenSSH server”选项，那么这台机器本身就不具备被SSH连接的能力。这种情况下客户端会提示Connection refused，因为22端口根本没有任何程序在监听。

检查方法：

sudo systemctl status ssh

如果提示Unit ssh.service could not be found，说明压根没装。安装命令：

sudo apt update sudo apt install -y openssh-server sudo systemctl enable --now ssh

安装完成后再次执行sudo systemctl status ssh，看到active (running)就说明服务起来了。如果服务是failed状态，可以执行sudo journalctl -u ssh查看失败原因。

接着确认端口有没有在监听：

sudo ss -tlnp | grep ssh

如果看到LISTEN 0 128 0.0.0.0:22，说明服务端一切正常。如果这里没有任何输出，说明sshd没有启动成功，或者配置里改了非默认端口。还有一种情况是sshd只监听在IPv6地址上，输出*:22或者[::]:22，这都是正常的。

3.2 sshd_config里三个关键参数，决定你能不能登录

如果服务在跑、端口在监听，但还是提示Permission denied，那就要检查SSH服务端的配置文件了。

配置文件在/etc/ssh/sshd_config，有些发行版还会在/etc/ssh/sshd_config.d/目录下放一些额外配置文件。Ubuntu默认情况下，sshd_config文件顶部会有一行Include /etc/ssh/sshd_config.d/*.conf，这意味着除了主配置文件，子目录里的配置也会生效。排查的时候要两边都看。

需要重点确认三个参数：

PasswordAuthentication。这是开关密码登录的总闸。如果它是no，那无论密码多正确都会被拒绝。需要改成yes。

PermitRootLogin。这个参数控制是否允许root直接登录。Ubuntu的默认值是prohibit-password，意思是root不允许用密码登录，但允许密钥登录。如果你在FinalShell里用的是root账号，那就会一直提示密码不对。想允许root密码登录，改成PermitRootLogin yes。但我个人建议，日常操作还是用普通用户加上sudo，root直接暴露密码登录容易招来暴力破解。

PubkeyAuthentication。这是密钥认证开关，如果设置了no，那密钥登录也会失败。一般保持yes即可。

修改配置后必须重启服务才生效：

sudo systemctl restart ssh

或者是：

sudo systemctl restart sshd

Ubuntu上服务名是ssh，所以第一条更常用。

这里还有一个巨坑要提醒：改配置前先备份，改完之后千万别把当前会话断开太早。建议的做法是：

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

然后修改配置、重启SSH、立刻开一个新的终端会话去连接测试，确认能连上再关旧会话。否则一旦配置改错，你可能会把自己锁在服务器外面。

3.3 auth.log日志：让系统自己说出真相

排查到这一步，如果还没弄清楚为什么拒绝认证，那就让日志说话。

Ubuntu的SSH认证日志写在/var/log/auth.log里。可以用下面的命令实时查看：

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

然后在另一边用FinalShell或者命令行尝试连接，观察日志输出。这是整个排查过程里信息量最大的一步。

常见的日志关键信息：

• Failed password for sambacai from 192.168.1.50 port 52410 ssh2：说明密码输入错误，客户端和服务端确实在进行密码比对，但密码不对。你需要检查密码本身。
• Connection closed by authenticating user sambacai 192.168.1.50 port 52410 [preauth]：这行出现时，往往说明密码认证阶段被中断。可能是用户不存在，也可能是禁用了密码登录。
• Accepted password for sambacai from 192.168.1.50 port 52430 ssh2：说明认证通过了。如果日志显示Accepted但FinalShell还是弹密码，那问题就回到了客户端。

看日志的时候，注意区分sshd进程有没有报权限错误。如果日志里有类似Could not load host key或者bad permissions的提示，说明sshd自身的密钥文件权限有问题，这也会导致SSH服务异常。

日志排查法的好处是客观。用户自己猜来猜去不如让系统直接告诉你失败原因在哪，尤其适合那种“密码明明是对的但连不上”的诡异场景。

4. FinalShell端容易踩的4个细节坑

4.1 “记住密码”没勾上的真相

回到FinalShell本身。很多人以为在连接配置里输入一次密码，之后每次连接就不需要再输了。但FinalShell的逻辑是：密码要在“设置”里保存，并且保存后连接时勾选“自动登录”，才会自动带出密码。

这里有两个不同的概念需要区分：连接时弹窗手动输入密码，和配置里保存了密码后自动登录。如果配置里密码没保存好，每次新建连接或者重启FinalShell后，它还是会弹出密码框让你输入。你以为是“一直提示密码”，其实只是客户端没保存密码，需要你每次都手动输入，这个是FinalShell的正常交互逻辑，不是bug。

处理办法：新建连接时，在密码栏里输入密码，然后勾选“保存密码”，最后点确定。下次双击连接时，如果能直接进入终端，说明保存成功。如果还弹密码框，就把连接配置删掉重新创建一次，有时候是配置没有被正确写入。

还有一个很容易忽略的点：FinalShell会为每个连接单独保存密码，你在A连接里改了密码，但脑子里以为改的是B连接。这种时候两个连接的密码不一样，用B连接自然永远对不上。建议给每个连接起有辨识度的名字，比如“Ubuntu-办公机-192.168.1.100”，避免混淆。

4.2 复制粘贴惹的祸：看不见的换行符

密码出问题，十个里有五个是复制粘贴搞的鬼。Windows的记事本、浏览器、聊天工具里的密码，复制到FinalShell密码框时，有时候会带上一个看不见的换行符。这个换行符在界面上看不出来，但SSH客户端会把它当成密码的一部分提交给服务器。服务端校验时发现密码多了一个字符，就会拒绝认证。

怎么排查？很简单，把密码复制到一个纯文本编辑器里，比如记事本，然后把光标移到密码末尾，按一下退格键，看看密码会不会变成空行或者多删除一个字符。如果感觉长度不对，就说明有隐藏字符混进去了。

更省事的方案是：在FinalShell的密码框里手动逐字输入密码，不要用复制粘贴。虽然麻烦一点，但能百分之百排除隐藏字符问题。等确认能连上之后，再考虑用“记住密码”功能把这串密码保存下来。

4.3 全角半角字符问题

这是个看似荒谬但真实存在的坑。Windows下的输入法默认可能是中文状态，这时候如果你敲键盘上的数字、字母外的符号，比如引号、括号、冒号，有可能会被输入成全角形式。全角字符和半角字符在计算机里是完全不同的Unicode编码，FinalShell把这些字符加密传输给SSH服务端，服务端解密后拿到的密码和你实际想输入的密码在字节层面上不一样，认证自然失败。

我用中文输入法的时候经常出现这个问题，尤其是密码里的@和:最容易中招。

解决办法：在输入密码前，先把输入法切换成英文模式（比如微软拼音里按Shift切换中英文），确保所有字符都是半角。或者直接在FinalShell的设置里把密码保存好，用自动登录代替手动输入，从源头避免这个问题。

4.4 FinalShell版本和本地缓存

排除以上所有因素后，如果还是连不上，就要考虑FinalShell自身的问题了。

我在排查中最常见到的是版本过旧。FinalShell的更新频率不高，但OpenSSH的更新频率很高。新版OpenSSH 8.8以上默认禁用了ssh-rsa签名算法，如果FinalShell版本稍老，可能会出现“算法协商失败”的情况，表现就是输入密码后马上断开。判断方法是看FinalShell的输出窗口里有没有no matching key exchange method字样。

解决办法就是去官网下载最新版，覆盖安装。另外一个办法是用绿色版直接解压运行，不污染系统环境。

本地缓存问题也比较常见。FinalShell的配置保存在本地文件中，如果之前的连接配置损坏，可能会导致连接受影响。Windows上FinalShell的配置目录大致在C:\Users\用户名\finalshell\下，你可以把其中某个连接对应的连接配置删掉，重新在FinalShell里创建。记得先关闭FinalShell再操作，否则配置文件可能被覆盖回写。

这个方法在处理“同一账号、同一密码，有时候能连有时候不能连”的间歇性故障时特别有效。

5. 一步到位：换SSH密钥登录，彻底告别密码弹窗

5.1 为什么密钥登录比密码登录稳

排查完一圈密码问题后，如果你问我有什么一劳永逸的解决方案，我的答案是：别用密码登录了，直接换成SSH密钥认证。

SSH密钥认证的原理本质上是一对非对称加密文件，公钥放在服务器上，私钥放在你的电脑上。连接的时候，服务器给客户端出一个加密难题，只有持有对应私钥的客户端才能解开。它不通过网络传输密码本身，所以不会有密码泄露的风险，也不存在“密码记错了”“密码有隐藏字符”这种破事。

平时自己用的话，私钥直接保存在本机，连接时几乎是一键直连。远程生产服务器上一般还会直接禁用密码登录，只允许密钥认证，这样别人连密码爆破的入口都没有了。

如果你经常连接多台服务器，密钥登录更是刚需。每台服务器装一次公钥，之后所有机器都无需输密码。相比之下，密码登录每次都输密码不说，还得担心密码被记录在FinalShell的本地配置里。

5.2 在FinalShell里生成密钥并上传到Ubuntu

密钥登录的配置也可以用命令行完成，但FinalShell提供了图形化操作，对新手友好得多。

第一步，生成密钥。打开FinalShell，顶部菜单找到“工具”，里面有一项“SSH密钥管理器”。点开后能看到当前电脑上已有的密钥列表，如果之前没生成过，点“新建”。密钥类型选RSA，长度选2048或者4096都行，2048已经足够安全。生成过程中可以设置一个私钥口令，这样就算别人拿到你的私钥文件，没有口令也解不开。当然，如果图方便，口令也可以不设。

第二步，把公钥复制到服务器。密钥生成后，密钥管理器里可以看到公钥内容，是一长串以ssh-rsa AAAA...开头的文本。复制这串内容。然后回到终端，在Ubuntu服务器上执行：

mkdir -p ~/.ssh chmod 700 ~/.ssh vim ~/.ssh/authorized_keys

把之前复制的公钥内容粘贴进去，保存退出。然后：

chmod 600 ~/.ssh/authorized_keys

这三条命令的含义分别是：创建.ssh目录、设置目录权限为700（只有自己可读写执行）、把公钥写进authorized_keys文件、设置文件权限为600（只有自己可读写）。

一个快捷办法是在本地执行ssh-copy-id命令。但你如果还没有任何能正常登录服务器的方式，这个奇招也就无从谈起了。所以最实际的方式还是先在Ubuntu图形界面或者物理终端上执行上面的命令。

第三步，用FinalShell测试密钥连接。回到FinalShell，编辑之前的连接配置，在认证方式里选择“公钥”（有些版本叫“密钥登录”），指定用你刚才生成的那把私钥，密码留空。确认后连接。如果前面步骤没出错，这次你就直接进到终端了。

5.3 密钥登录的权限检查清单

密钥登录比密码登录稳定，但权限要求更苛刻。服务器上.ssh目录和authorized_keys文件权限不对，服务端会直接拒绝读取公钥，然后一切正常认证都会失败。

这里整理一份权限检查清单：

• ~/.ssh目录权限必须是700（drwx------）
• ~/.ssh/authorized_keys文件权限必须是600（-rw-------）
• 宿主机~目录（也就是home目录）权限不能太宽松，最好是755或者更严
• 如果开启了SELinux（Ubuntu默认没有），需要额外注意上下文标签

检查命令：

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

正常情况下输出应该类似：

drwxr-xr-x 5 sambacai sambacai 4096 Mar 12 10:00 /home/sambacai drwx------ 2 sambacai sambacai 4096 Mar 12 10:01 /home/sambacai/.ssh -rw------- 1 sambacai sambacai 745 Mar 12 10:02 /home/sambacai/.ssh/authorized_keys

如果权限不对，用chmod命令修正：

chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys

还有一点，如果你给/etc/ssh/sshd_config里加了其他自定义选项，比如设置了AuthorizedKeysFile指向非默认路径，那公钥文件的位置就得对应修改，不然服务端找不到公钥。

密钥登录配置成功后，如果你确定以后都用密钥登录，可以在服务端把密码登录彻底关掉：

sudo sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config sudo systemctl restart ssh

但我要提醒一句：先确保密钥登录已经完全可用，再执行这条命令，否则你可能把自己锁在服务器外面。建议改完配置后开两个SSH窗口，一个窗口负责改配置，另一个窗口用来验证新配置是否生效，都确认没问题后，再关闭旧窗口。

6. 问题排查速查表与我的几点实操心得

6.1 用户场景速查表

把前面讲过的内容整理成一张表，方便你遇到问题时直接对照，省得把所有地方都翻一遍：

这张表是我自己在长期排障过程中沉淀出来的。遇到问题时先判断自己的现象落在那一行，然后按对应方案处理，能少走很多弯路。

6.2 连接成功后，FinalShell里头几个推荐先做好的设置

好不容易连上了，别急着高兴。有几个基础设置建议初始化的时候就做好，能省掉后面很多麻烦。

第一个是修改终端编码为UTF-8。在连接配置里找到“终端”或“高级”选项，确认编码设置为UTF-8。Ubuntu默认就是UTF-8，这一步主要是防止中文文件名乱码。

第二个是开启“SFTP”面板，也就是左侧的文件管理。FinalShell的核心优势之一就是SFTP文件上传下载，配置好后拖拽文件就能直接传到服务器上。这个功能在连接成功后默认就能用，不需要额外设置。

第三个是保存好连接分组。服务器多了之后，建议按照生产环境、测试环境、跳板机等用途建立不同分组，配合FinalShell的同步功能，以后换电脑也能一键拉回配置。

第四个是检查终端的自动重连设置。网络不稳定时，SSH容易断线，FinalShell有“自动重连”选项，勾选后，只要网络恢复，终端会自动重新建立连接。这在用笔记本连服务器长期跑任务时非常实用。

6.3 我的几点实操心得

最后说说我做Linux服务器运维这几年，围绕SSH连接踩过的一些经验和心得。

第一个心得：排查密码问题，最多花30分钟在客户端上，超过30分钟就转去查服务端和日志。很多人遇到连不上就一直在FinalShell里改密码、删连接、重启软件，其实大部分时候问题不在客户端。先把服务端的日志打开看一眼，所有真相都在/var/log/auth.log里躺着。

第二个心得：改sshd_config之前，永远先备份，永远先开第二个会话再改。我见过太多人因为改配置把服务器锁在外面，最后只能去云平台控制台用VNC救回来。正确做法是：修改配置文件前执行sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak，修改并重启服务后，立刻开一个新的SSH窗口测试连接，确认能连上了再关旧窗口。永远不要在一个会话里完成“改配置-重启-等连接”的整个过程。

第三个心得：能上密钥登录就尽量上密钥登录。密码登录的问题在于，你无法判断这次连不上到底是密码输错了，是网络问题，还是服务端改了配置。但密钥登录只要密钥文件还在、权限没问题、服务器没改端口，基本上是必通的。尤其是运维多台服务器的时候，用密钥登录配一个简单的私钥口令，比每个服务器记一个复杂密码可靠十倍。

第四个心得：注意Ubuntu和Ubuntu Linux的拼写问题。网上很多教程把Ubuntu拼成“ubantu”，这个拼写导致的后果是搜索准确率下降。建议搜问题的时候用正确的拼写Ubuntu，配合关键词ssh、sshd_config、auth.log搜索，能更快找到高质量解决方案。

最后再分享一个小技巧：如果你遇到的是FinalShell里密码一直弹，而命令行能连的情况，其实可以不排查直接绕过。用FinalShell创建连接时，认证方式不要选密码，改成密钥认证，然后把密钥配置好。这样你既保留FinalShell的图形化界面和文件管理功能，又彻底躲开了密码弹窗这条路上的所有坑。

我自己的使用习惯是：本机生成密钥对，服务器只放公钥，FinalShell里保存好私钥路径。之后每次连接，鼠标双击就能进系统。密码不对的问题从此彻底成为历史。