SSH连接完全指南：从基础命令到密钥配置与安全加固-代码聚汇网

SSH连接完全指南：从基础命令到密钥配置与安全加固

火锅大魔王·2026-09-06·阅读 22 GEO检测（免费）

SSHOpenSSH密钥登录

|难度：普通|阅读约 31 分钟

说实话，SSH 这玩意儿，不管你是 Windows 用户还是 Linux 用户，迟早都得学会。你手里有台服务器，不是 Linux 云主机就是自己搭的物理机，想在上面敲命令、改配置、传文件，全都得靠 SSH 连过去。Windows 这边，系统其实早就自带了 OpenSSH 客户端，打开 PowerShell 或者 CMD 就能直接连；Linux 这边更不用说，ssh 命令几乎是每天都要用的基本功。这篇我就把连 SSH 这件事从头到尾捋一遍，从最简单的密码登录，到密钥免密、服务端限制登录用户、多台机器批量管理，再到各种常见坑，一次性讲清楚。适合刚接触服务器的新手，也适合想把手上的连接方式整理一遍的老手。

1. 先弄清楚 SSH 到底在连什么

1.1 SSH 不是一条命令，而是一套协议

很多人第一次接触 SSH 的时候，以为 SSH 就是 ssh user@ip 这一条命令，其实命令只是客户端，真正的核心是一套加密网络协议，工作在 TCP 的 22 端口上。它的作用说白了就是：在不安全的网络上，建立一条加密通道，然后在这条通道里安全地执行远程命令、传输文件、转发端口。

我习惯把它类比成远程主机门口的一扇安检门。你递过去的是用户名和凭证（密码或者密钥），门卫验证通过后放你进去，之后你在这台机器上的所有操作，都是在一个加密隧道里进行的。和以前老旧的 telnet 相比，telnet 是明文把用户名密码从网线上送过去，中途被人抓包就直接泄露了；SSH 则把整条会话都加密了，中间人就算截到数据包也解不开内容。

这里有个容易忽略的点：SSH 是客户端/服务端模式。你本机装的 OpenSSH Client 只是客户端，被连接的机器上必须跑着一个 sshd 服务端进程，负责监听 22 端口。Windows 10 1809 之后的系统自带了 OpenSSH Client，但默认不一定启动 OpenSSH Server 服务，所以你在 Windows 上“连别人”通常没问题，但想让别人“连你的 Windows”，得先去“设置 – 系统 – 可选功能”里把 OpenSSH 服务端装上并启动。

1.2 一个连接请求里藏着三个关键信息

无论用什么工具，发起一次 SSH 连接，本质上你都在提供三个信息：

目标地址：IP 地址或域名，告诉客户端要连到哪台机器。
端口号：默认是 22，但如果服务端改了端口，你就得用 -p 参数指定。
登录身份：也就是用户名 + 认证凭证。凭证常见的有两种，一种是密码，另一种是密钥对（私钥留在本地，公钥放到服务器）。

搞清楚这三要素之后，排查问题就简单多了。连接失败的时候，先别慌，按这个顺序问自己：IP 通不通？端口对不对？用户名有没有写对？认证方式是否匹配？大部分连接问题都出在这三件事上。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. Windows 下连接 SSH 的几种方式

2.1 系统自带 OpenSSH 客户端，够用但别嫌它简陋

Windows 10 1809 及以后的版本，PowerShell 或者 CMD 里直接敲 ssh 命令就能用，不需要额外安装任何软件。比如我要连一台内网服务器，地址是 192.168.1.20，用户名是 root，直接输入：

bash复制ssh root@192.168.1.20

第一次连接的时候，系统会提示你确认远程主机的指纹（fingerprint），输入 yes 回车即可。这一步很多新手会紧张，其实它是在告诉你“这台主机的身份指纹是 xx，你确定要连吗”，防止中间人攻击。正常输入 yes 就行，除非你明确知道这台机器的指纹发生了变化。

如果你要连的端口不是默认的 22，比如是 2222，那就加个 -p 参数：

bash复制ssh -p 2222 root@192.168.1.20

输入密码的时候，屏幕上不会显示任何字符，也不会出现星号，这是正常的，别以为键盘坏了，直接敲完回车就行。

自带客户端的缺点也很明显：没有会话保存功能，每次都要重新敲一遍 IP 和用户名；文件传输还得另开一个窗口用 scp 或 sftp。所以我平时虽然会用到它，但真正管理多台服务器的时候，还是更依赖第三方工具。

2.2 第三方 SSH 工具选哪个，我说下我的使用感受

如果你需要管理多台服务器，或者经常要传文件，建议装一个图形化工具。市面上一堆，但真正让我长期用下来的不多。

Bitvise SSH Client 是我用得比较久的一个，免费且功能扎实，终端和 SFTP 文件管理集成在同一个窗口里，左边传文件右边敲命令，非常顺手。它还支持端口转发、动态隧道，适合在 Windows 上做网络调试。

Xshell 也是很多人推荐的，界面更现代，会话管理很强大，家庭版免费。MobaXterm 更适合喜欢多标签页的人，内置了一大堆网络工具，比如 ssh、telnet、RDP、ftp 等等，一个窗口全搞定。FinalShell 是国内团队做的，自带中文界面、实时监控服务器 CPU 和内存，对新手更友好。

如果你追求原汁原味的终端体验，可以装 Windows Terminal，然后把 Windows 自带的 OpenSSH 客户端嵌进去，既保留命令行的纯粹，又能多标签页切换。这个方案适合那种不喜欢 GUI、喜欢纯命令行的老伙计。

2.3 Windows 上生成密钥，免密登录其实不复杂

密码登录虽然方便，但每次都要输密码，而且密码容易被爆破。我建议至少在 Windows 上把密钥登录配起来，整个过程也就两三分钟。

先在 PowerShell 或 CMD 里生成密钥对：

bash复制ssh-keygen -t ed25519 -C "your_email_or_comment"

一路回车就能生成。默认会保存在 C:\Users\你的用户名\.ssh\ 目录下，文件名是 id_ed25519（私钥）和 id_ed25519.pub（公钥）。私钥千万不能给别人，公钥就是要放到服务器上的。

然后查看公钥内容：

bash复制cat C:\Users\你的用户名\.ssh\id_ed25519.pub

复制公钥内容，把它追加到服务器的 ~/.ssh/authorized_keys 文件里。一种快速的方式是直接执行：

bash复制ssh root@192.168.1.20 "mkdir -p ~/.ssh && echo '粘贴公钥内容' >> ~/.ssh/authorized_keys"

输一次密码后，公钥就装好了。之后再连接就不用输密码了。

这里有个 Windows 特有的坑：.ssh 目录和私钥文件的权限不能被设置成“Everyone 可读”，否则 OpenSSH 客户端会直接报错拒绝使用这个私钥。如果遇到 Bad owner or permissions 之类的提示，右键私钥文件，在“属性 – 安全”里把多余的 user 删掉，只留下自己的账户完全控制，一般就能解决。

2.4 VS Code 远程连接 SSH，开发者的主力玩法

如果你不是纯运维，而是开发，那 VS Code 的 Remote-SSH 扩展一定要用起来。安装扩展后，按 F1 输入 Remote-SSH: Connect to Host，可以选一个已有的 SSH 配置，也可以临时输 user@host 连接。

为了长期使用，我强烈建议把所有服务器的连接信息写到 ~/.ssh/config 文件里，格式大概是这样的：

text复制Host myserver
    HostName 192.168.1.20
    User root
    Port 22
    IdentityFile ~/.ssh/id_ed25519

这样你在 VS Code 里只需要选 myserver 就能连上，不用再记 IP 和用户。连接上之后，左边能直接浏览远程文件、编辑然后自动同步，下面还能开远程终端，整个体验跟操作本机几乎一样。

配合前面配好的密钥登录，VS Code 每次连接都不需要输密码，开发效率提升非常明显。

3. Linux 下连接 SSH 的常用操作

3.1 常用 ssh 命令和参数，一次说清楚

Linux 下的 OpenSSH 客户端通常默认已经装好了，直接在终端里敲 ssh 就能用。除了一般的密码登录，几个常用参数建议记一下：

bash复制ssh -p 22 user@host              # 指定端口登录
ssh -i ~/.ssh/id_ed25519 user@host  # 指定私钥登录
ssh -v user@host                  # 调试模式，输出详细连接过程
ssh user@host 'df -h && uptime'   # 连过去直接执行命令，不进入交互终端

最后一条非常实用。比如你想检查所有服务器的磁盘使用情况，不需要一台台登进去再手动敲命令，直接一条 SSH 命令就把远程结果拉回来。

文件传输方面，最常用的是 scp 和 rsync。简单场景用 scp：

bash复制scp -P 22 ./backup.tar.gz root@host:/data/

注意这里指定端口是大写的 -P，跟登录的 -p 不一样，我当年就因为这个大小写问题卡了好一会儿。

目录级别的同步推荐 rsync：

bash复制rsync -avz -e "ssh -p 22" ./data/ root@host:/data/

-a 是归档模式保留权限和时间戳，-v 显示过程，-z 传输时压缩。-e 用来指定 ssh 命令，如果你的端口不是默认的，就得靠它把端口传进去。

3.2 密钥生成和公钥分发，保证只信任该信任的机器

Linux 下生成密钥的方式跟 Windows 基本一样：

bash复制ssh-keygen -t ed25519 -C "user@hostname"

生成后公钥在 ~/.ssh/id_ed25519.pub。把公钥放到目标服务器的标准操作是用 ssh-copy-id：

bash复制ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

这个命令会自动登录服务器，创建 ~/.ssh 目录，把公钥追加到 authorized_keys 文件里，还会顺手把目录权限修正成 700、文件权限修正成 600。手动配置也完全可以，只是权限记得要设对。

服务端 ~/.ssh 目录权限不对的话，sshd 会拒绝读取 authorized_keys，现象就是明明公钥贴进去了，但还是提示要输密码，甚至被拒绝。正确权限是：.ssh 目录 700，authorized_keys 文件 600，~ 主目录不能对组和其他用户开放写权限。

3.3 多台机器批量登录和管理的思路

服务器多了以后，一台台手动 ssh 登录会累死人。有几个方向可以参考。

第一种是写个简单的循环脚本，批量执行同样的命令：

bash复制for host in 192.168.1.10 192.168.1.20 192.168.1.30; do
    ssh $host "uptime"
done

这种做法的缺点是如果服务器很多，串行执行会慢，而且每台机器都会要求密码。这时候要么提前配好密钥免密，要么用 ssh-agent 缓存密钥。

第二种优化方式是配置 SSH 连接复用。在 ~/.ssh/config 里加上：

text复制Host *
    ControlMaster auto
    ControlPath ~/.ssh/controlmasters/%r@%h:%p
    ControlPersist 10m

加上之后，同一台主机的连接会复用一条 TCP 通道，后续连接不会重新握手，速度会快很多，尤其适合需要在多台服务器之间跳转的场景。

第三种就是从批量运维工具的角度出发，用 Ansible 或者 pssh 这类工具，把服务器列表放到一个静态文件里，然后统一执行。这个相对重一些，适合已经有一定规模的运维环境。

4. 服务端如何控制谁能登录

4.1 sshd_config 里的关键参数

连接的问题搞清楚之后，服务端配置才是最需要谨慎对待的。SSH 服务端的核心配置文件是 /etc/ssh/sshd_config，几乎所有跟登录策略有关的设置都在这里。

几个我最常用的关键项：

参数	作用	推荐设置
Port	SSH 服务监听端口	不推荐默认 22，但改端口要谨慎
PermitRootLogin	是否允许 root 登录	no 或 prohibit-password
PasswordAuthentication	是否允许密码登录	使用密钥时建议 no
PubkeyAuthentication	是否允许密钥登录	yes
AllowGroups	只允许哪些组的用户登录	按需设置 wheel
AllowUsers	只允许哪些用户登录	按需设置
MaxAuthTries	单次连接允许的最大认证次数	3
ClientAliveInterval	服务端多久探活一次	60

改配置之前，一定先备份原文件。改完之后先执行 sshd -t 检查语法，再重启服务。很多事故都是因为手误写错了配置，重启 sshd 服务后把自己的连接也断掉了。

4.2 设置只有 wheel 组的用户可以 SSH 登录

如果你用的是 RHEL 系的发行版（CentOS、Rocky、欧拉、麒麟这类），通常安装完后默认会有一个 wheel 组，这个组里的用户可以 sudo 提权。要限定只有这类用户能登录，非常简单，在 sshd_config 里加一行：

text复制AllowGroups wheel

保存后检查语法、重启 sshd。这样就只有 wheel 组的成员可以通过 SSH 登录，其他普通用户即使有账号也连不进来。

这里要提醒一下，AllowGroups 和 AllowUsers 是白名单机制，如果两个都写了，用户必须同时满足两个条件才能登录。所以别一个写 wheel 一个又加了一堆其他用户，反而把自己挡在门外。

4.3 新建用户并加入 wheel 组，顺手把 sudo 配好

一般我会新建一个专用管理用户，比如叫 ops，然后把它加入 wheel 组：

bash复制useradd ops
passwd ops
usermod -aG wheel ops
id ops

usermod -aG wheel ops 里那个 -a 是追加的意思，不加 -a 的话会把这个用户从原来的附属组里替换掉，别踩这个坑。id ops 用来确认组是否生效。

确认用户可以登录、可以 sudo 之后，再把 root 远程登录关掉：

text复制PermitRootLogin no

同时把密码认证关掉，只留密钥登录：

text复制PasswordAuthentication no
PubkeyAuthentication yes

这样整台机器的 SSH 登录就安全很多。公网服务器被暴力破解的绝大多数原因，都是开着 root 密码登录，这是非常危险的习惯。

4.4 如果你想反过来取消限制，允许 root 登录

很多人在测试环境会遇到“如何取消使 root 用户也可以 ssh 登录”的问题。如果你的本意是让 root 能被远程登录，把 PermitRootLogin 设为 yes 或者 prohibit-password 就行了。

但我的建议是：生产环境绝对不要开 PermitRootLogin yes + 密码登录的组合。如果一定要 root 远程登录，也尽量配合密钥，也就是用 prohibit-password 这个值，表示只允许密钥登录 root，不允许密码登录。这样至少能把被暴力破解的风险压到最低。

如果你只是想取消之前的限制，那多半是发现自己在配置里写了 PermitRootLogin no 或者 AllowGroups wheel，把原本能登录的 root 挡在外面了。排除思路很简单：先把 AllowGroups 和 AllowUsers 暂时注释掉，再确认 PermitRootLogin 的值，逐项排除。

5. 常见问题排查与避坑实录

5.1 连不上：超时、拒绝、认证失败，分别怎么查

连接超时（Connection timed out）通常是网络层的问题。先 ping 一下目标 IP，能通再看端口通不通，Windows 下可以用 Test-NetConnection 192.168.1.20 -Port 22，Linux 下可以用 nc -vz 192.168.1.20 22。如果端口不通，可能是云服务商的安全组没放行 22 端口，也可能是本机防火墙拦了。

连接被拒绝（Connection refused）通常说明服务端 sshd 没有启动，或者端口起在别的地方。登录服务器看一眼：

bash复制systemctl status sshd
ss -lntp | grep sshd

如果服务在跑但端口不是 22，可以看下 /etc/ssh/sshd_config 里 Port 配置。

认证失败（Permission denied）就复杂一些。如果确认密码正确但还是失败，大概率是服务端开了仅密钥登录（PasswordAuthentication no），但你的公钥又没正确放进 authorized_keys。用 ssh -v user@host 看详细输出，或者直接看服务端日志。Debian 系看 /var/log/auth.log，RHEL 系看 /var/log/secure。

5.2 系统层面被搞乱的小毛病

有不少人遇到过按 Win+R 打不开 CMD 的情况，常见原因一般是注册表或者系统策略被修改，或者是某些自装软件劫持了快捷键。遇到这种情况，可以先按 Ctrl + Shift + Esc 打开任务管理器，然后在“文件 – 运行新任务”里输入 powershell 调出终端，再运行：

bash复制reg query "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v DisableCMD

如果查出来值不是 0，可以用 reg delete 把该项删掉。再不行就用 sfc /scannow 检查系统文件完整性。另外提醒一句，很多人电脑上会莫名多出一些“工具箱”类的软件，如果它不是你自己装的，建议去“设置 – 应用”里把它卸载干净，残留的启动项也要清一下，不然它可能会抢掉快捷键、改默认程序，甚至挡掉你正常安装软件。

5.3 密钥认证报错的几种典型情况

密钥登录配置好之后，最常遇到的一个报错是：

text复制WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

这说明远程主机的指纹变了，可能是服务器重装了系统，也可能是你连错了机器。解决办法是把 known_hosts 里旧的记录删掉：

bash复制ssh-keygen -R 192.168.1.20

还有一个常见问题是 Load key "xxx": invalid format，多半是密钥文件格式不对，比如从别的工具导出的格式不被 OpenSSH 识别。此时可以考虑用 ssh-keygen -p -m PEM -f ~/.ssh/id_rsa 转换格式，或者重新用 OpenSSH 生成一对新密钥。

Windows 下最容易遇到的则是权限问题，OpenSSH 对私钥文件的权限检查非常严格。如果系统提示私钥权限过大，右键私钥文件，在“属性 – 安全 – 高级”里改掉继承关系，把多余的权限条目清掉，只留下当前用户完全控制，问题就解决了。

5.4 Git 配置 SSH 密钥时容易踩的坑

如果你用 Git 连接 GitHub、GitLab 或 Gitea 这类代码托管平台，配置流程通常是这样的：生成密钥对，把公钥粘贴到平台后台的 SSH Keys 设置里，然后本地测试：

bash复制ssh -T git@github.com

如果返回 Hi xxx! You've successfully authenticated，说明密钥生效。

最常见的坑有两个。第一个是把公钥和私钥放反了，平台只需要公钥，私钥留在本地。第二个是配了多个平台或多个账号，导致密钥混乱。这时候需要在 ~/.ssh/config 里按 Host 区分：

text复制Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

Host gitlab.com
    HostName gitlab.com
    User git
    IdentityFile ~/.ssh/id_ed25519_gitlab

配置完之后再用 ssh -T 测试，就不会串 key 了。

5.5 一次真实的排错记录

我之前有一台公网服务器，前一天还能连，第二天突然所有客户端都提示 Connection refused。排查过程大概是：先登录云控制台，通过 VNC 进去看，发现 sshd 确实没在运行，systemctl status sshd 提示启动失败。翻日志后发现 /etc/ssh/sshd_config 里被人手滑写了一个不存在的端口值，导致 sshd 起不来。这种问题如果人已经不在服务器前面，就只能靠云厂商提供的 VNC/控制台来救，所以在改配置的时候，务必先开一个备用会话，或者确认 sshd -t 检查通过后再重启。

我还遇到过一个问题：内网服务器 IP 没变，但换了网卡后 SSH 一直超时。最后查下来是服务器上开启了 firewalld，新的网卡区没有放行 22 端口。用命令行临时开放一下，业务就恢复了。这类网络层问题，单靠本机 sshd 配置是解决不了的。

6. 日常管理经验里最值得养成的几个习惯

说起来，SSH 这东西本身不复杂，真正容易出问题的都是细节和习惯。我用了这么多年，最大的体会就是：永远不要把服务器当作“能连上就行”的东西来对待。趁早把密钥登录配起来，把 root 远程密码登录关掉，把 AllowGroups wheel 这种白名单机制用起来，看起来多花了几分钟，实际上省掉了后面无数次的折腾。

还有一个很实用的小技巧：把所有服务器的 Host 配置统一维护在一个 ~/.ssh/config 文件里，配合 Git 仓库管理，换电脑的时候直接拉下来就能用，密钥单独复制过去就好。我自己现在开新机器，第一件事就是把这段配置写好，再配上 VS Code Remote-SSH，体验可以说非常顺畅。

另外，建议定期用 ssh -G 看看配置实际生效情况，比如确认某个 Host 用的是哪个私钥、连的哪个端口，排查问题的时候特别有用。命令本身记不住也没关系，man ssh_config 永远是好帮手。希望这篇能帮你把 SSH 从“会连”变成“连得明白”。