一、连接前的准备:把四样东西确认好

这一步做对,后面一通顺;这一步跳过,后面全是返工。 大多数「连不上」都源于这四样东西里的某一样没确认。
第一样:IP 地址。
# 从商家控制台或交付邮件里拿到 IP,先确认格式
# 正常的是四个 0-255 的数字,像这样:203.0.113.10
IP 最常见的两个错误:一是抄错,二是用了过期的 IP。 第二种情况发生在重装系统、迁移机房、或者商家做了路由调整之后——重装系统会生成新的 SSH 主机密钥,但 IP 通常不变;换机房则两者都可能变。
第二样:SSH 端口。
# 默认是 22,但不少商家会用自定义端口
# 从控制台的连接信息里确认,或者试常见值
ssh -p 22 root@IP
ssh -p 2222 root@IP
第三样:登录用户名。 Linux VPS 常见的是 root,但 Ubuntu 云镜像常见 ubuntu,CentOS 常见 centos,有些商家会给一个专用的普通用户。
第四样:密码或密钥。 密码注意区分大小写、注意复制时有没有带上首尾空格、有没有把输入法切成中文导致符号变成全角——最后一个问题特别隐蔽。
这四样确认之后,先做一次端口探测,这一步能省掉大量猜测:
# 用 nc 测端口,这是判断「机器活着没」最准的一步
nc -zv 你的服务器IP 22
# 没有 nc 的话用这个
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/你的服务器IP/22' && echo "端口通" || echo "端口不通"
探测结果直接对应三个方向:
| 探测结果 | 说明 | 下一步 |
|---|---|---|
| 端口通 | 机器和网络都正常 | 往认证方向查 |
| 超时 | 机器没起、IP 错、或被拦 | 核对 IP、问商家状态 |
| 拒绝 | 端口上没有服务 | sshd 没启动,或端口记错 |
第三种情况有个例外:刚重装完系统的机器,sshd 确实可能还没起来,等一两分钟再试即可。
顺便说一句:大多数 VPS 都禁 ping,这不是故障。 禁 ping 是常规的反扫描措施,用 ping 判断机器死活会误判。端口探测才是靠谱的判断方式。
但端口探测也有它的局限:它只能告诉你「端口那头有人在应答」,不能告诉你那是不是你要找的机器。 所以完整的信息核对其实需要两步:
# 第一步:端口探测,确认机器活着
nc -zv 你的服务器IP 22
# 第二步:看 SSH 握手时服务器自报的主机密钥类型,
# 这一步能和商家控制台上的信息对上
ssh-keyscan 你的服务器IP 2>/dev/null | head -3
ssh-keyscan 的作用是只取握手信息不真正登录,它能在你输入密码之前确认这台机器的技术特征和商家给的是否一致。
最后是客户端的选择。 Windows 10 和 11 自带 OpenSSH 客户端,在 PowerShell 里直接可用;macOS 和 Linux 自带;Windows 7 或者更老的系统需要单独装客户端。
# Windows PowerShell 里确认 ssh 命令可用
ssh -V
# 找不到命令的话,去「设置 → 应用 → 可选功能」装 OpenSSH 客户端
还有一个配套工具建议一起装:PuTTY 或者 MobaXterm。 它们的用处是图形化保存会话、保存密码、以及在没有密钥的情况下批量管理多台机器。 但如果你只打算管理一两台机器,命令行完全够用。
二、第一次连接:命令、提示和首次登录要做的三件事

最基本的一条命令:
ssh root@你的服务器IP
第一次连接时你会看到一个指纹确认提示:
The authenticity of host '203.0.113.10' can't be established.
ED25519 key fingerprint is SHA256:xxxx...
Are you sure you want to continue connecting (yes/no)?
这个提示的机制:SSH 客户端第一次连一台陌生机器时,会把服务器的主机密钥给你看,你确认后会把它记在本地。 以后再连这台机器,密钥对得上就不会再问。
这里有一个必须讲清楚的安全点:这个指纹是可以被中间人伪造的。 也就是说,第一次连接时显示的指纹本身不能证明你连的是真服务器。 更可靠的做法是从商家的控制台拿官方指纹来比对:
# 在服务器上查看自己的主机密钥指纹
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
这个指纹应该和客户端首次连接时显示的一致。 对不上就说明中间有人。
确认之后,提示你输入密码:
[email protected]'s password:
注意输入密码时屏幕上不会有任何显示(连星号都没有),这是 SSH 的设计,防止密码长度泄露。打完直接回车即可。
登录成功后,第一次连接有三件事必须马上做,它们决定了后面所有操作的顺利程度:
第一件事:确认身份和系统版本。
whoami && hostname && cat /etc/os-release | head -3 && uname -r
为什么第一件事是确认身份:因为很多 VPS 交付时给的是默认密码,而这个密码在某些商家之间是通用的。如果你的第一反应是「先改密码」,那是对的,但更彻底的做法是立刻换掉 SSH 端口、换成密钥登录。
第二件事:更新系统。 这一步能解决后面一半的「明明装了却不能用」的问题。
# Debian / Ubuntu
apt update && apt upgrade -y
# CentOS / RHEL / Rocky
yum update -y
# 确认内核版本
uname -r
第三件事:确认网络配置正常。
# 出网测试,DNS 解析和路由都正常才返回内容
curl -s https://api.ipify.org; echo
# 看默认路由和 DNS 配置
ip route && cat /etc/resolv.conf
# 测 DNS 解析
nslookup 你的域名
如果这一步 curl 没有任何输出,那说明这台机器还不能上网,后面装任何东西都会失败。这时候要查的是 DNS 配置和默认网关,而不是重装。
出网不通的三种情况,分别这样查:
# 情况一:DNS 解析失败(能 ping IP 但解析不了域名)
cat /etc/resolv.conf
# 临时换成公共 DNS 测试
echo "nameserver 223.5.5.5" >> /etc/resolv.conf
echo "nameserver 8.8.8.8" >> /etc/resolv.conf
# 情况二:默认路由缺失(根本出不去)
ip route
# 期望看到 default via 网关IP dev 网卡名 这一行
# 缺了就手动加
ip route add default via 网关IP dev 网卡名
# 情况三:出站端口被拦(能解析但连不上外网)
# 用 telnet 测一个确定开放的端口
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/1.1.1.1/443' && echo "443 通" || echo "443 不通"
这三种情况的处理方式完全不同,混着查会绕远路。 先看 ip route 有没有 default 行,再看 resolv.conf 里有没有 nameserver,最后才测端口——按这个顺序,DNS 和路由问题会在前两步就暴露出来。
顺便记一下这台机器的公网 IP 出口:
curl -s https://api.ipify.org; echo
这个 IP 是你所有出网流量的来源地址。 后面配置防火墙白名单、排查第三方 IP 封禁问题时,这个值都要用。
最后一个动作:设置 SSH 别名,把上面这串参数固化下来。
cat >> ~/.ssh/config << 'EOF'
Host myvps
HostName 203.0.113.10
User root
Port 22
IdentityFile ~/.ssh/id_rsa
ServerAliveInterval 60
ServerAliveCountMax 3
EOF
# 之后直接
ssh myvps
这两行 ServerAlive 的作用是防止空闲断连,具体原理和用法在第七节展开。
三、密钥登录:完整配置与避坑要点

密码登录能连上,但它有两个明确的短板:每次都要输密码,以及密码一旦泄露就等于交出机器。 密钥登录同时解决这两件事。
完整流程六步,顺序不能乱:
# 第一步:生成密钥对
ssh-keygen -t rsa -b 4096 -C "vps-203.0.113.10"
# 第二步:把公钥推上去,会要求输入一次服务器密码
ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]
# 第三步:验证免密登录生效
ssh [email protected]
# 第四步:备份配置,改错了能回滚
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
# 第五步:关闭密码登录
sed -i 's/#PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sshd -t && systemctl reload sshd
# 第六步:另开一个终端,验证还能连上
第六步是整段操作的关键,也是最常被跳过的一步。 在你确认新窗口能登录之前,绝对不要关掉原来那个窗口。 如果配置写错了,原窗口是你唯一的救生通道——关掉它,就只能通过商家的 VNC 控制台救援了。
第五步里的 sshd -t 同样不能省。 它检查配置文件的语法,如果语法有错又直接重启,sshd 起不来,机器就失去远程访问能力了。
关于第五步用 reload 而不是 restart: reload 不会杀掉已有的 SSH 会话,所以即使新配置有问题,你当前的连接还在。这是更安全的做法。
Windows 上的对应操作:
# 生成密钥(PowerShell 里用同样的 ssh-keygen)
ssh-keygen -t rsa -b 4096 -C "vps-203.0.113.10"
# 传公钥(没有 ssh-copy-id 时的等价写法)
type $env:USERPROFILE\.ssh\id_rsa.pub | ssh [email protected] "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
几个密钥相关的常见坑:
坑一:公钥的换行符格式不对。 Windows 上用记事本编辑过公钥文件,会引入 CRLF 换行符,导致服务端读到的公钥末尾多出回车符而匹配不上。用上面的 type | ssh 管道方式可以避免这个问题。
坑二:文件权限不对。 SSH 对权限极其敏感:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/authorized_keys
权限过于开放时,sshd 会直接拒绝使用这个密钥,报 UNPROTECTED PRIVATE KEY FILE。
坑三:本地密钥太多导致认证失败。
# 明确指定只用这一个密钥
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_rsa [email protected]
SSH 客户端会按顺序尝试所有可用密钥,超过 5 次失败就断开,报 Too many authentication failures。
坑四:passphrase 每次都要输,很烦。 用 ssh-agent 缓存:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa
# 写进 ~/.bashrc 实现自启
echo 'eval "$(ssh-agent -s)"' >> ~/.bashrc
echo 'ssh-add ~/.ssh/id_rsa' >> ~/.bashrc
这样私钥文件本身保持加密,日常使用又不用反复输入。
四、传文件:三种方式与各自的适用场景

传文件是 SSH 的内置能力,不需要额外工具。 三种方式各有适用场景。
第一种:scp,适合单个文件。
# 上传单个文件
scp 本地文件.txt [email protected]:/var/www/
# 上传目录,必须加 -r
scp -r 本地目录 [email protected]:/var/www/
# 下载
scp [email protected]:/var/www/远程文件.zip .
# 指定端口
scp -P 2222 本地文件.txt [email protected]:/var/www/
注意 scp 的端口参数是大写的 -P,而 ssh 是小写的 -p。 这是个经典的记混点。
第二种:sftp,适合需要交互和断点续传的场景。
sftp [email protected]
进入后可用这些命令:
put 本地文件 /远程路径/ 上传
get /远程文件 本地路径 下载
ls 列目录
cd 目录名 切目录
lcd 本地目录 切本地目录
pwd / lpwd 看当前路径
rename 旧名 新名 重命名
rm 文件名 删除
bye 退出
第三种:rsync,适合目录同步和增量传输,这是最实用的一个。
# 基本同步
rsync -avz --delete --exclude='*.log' /本地目录/ [email protected]:/远程目录/
# 第一次同步前先看会动什么
rsync -avz --delete --dry-run /本地目录/ [email protected]:/远程目录/
--delete 是这一节最需要小心的地方。 它的含义是「删除目标端有、源端没有的文件」,如果路径方向写反,远端目录会被清空。永远先加 --dry-run 看清列表,再去掉它执行。
rsync 的几个实用参数:
# 显示进度
rsync -avz --progress /大文件 root@远程IP:/目标路径/
# 断点续传,中断了重跑同一条命令即可
rsync -avz --partial --progress /大文件 root@远程IP:/目标路径/
# 限制带宽,避免占满上行(单位是 KB/s)
rsync -avz --bwlimit=1000 /大文件 root@远程IP:/目标路径/
--bwlimit 这一条在共用带宽或者用手机热点时特别有用,可以避免传文件把其他服务挤掉。
第四种:走 SSH 管道直接传,文件多时最快。
# 打包压缩后通过管道传送,远端自动解开
tar czf - /本地目录 | ssh root@远程IP "tar xzf - -C /目标目录"
这个方法比 scp -r 快好几倍,因为它避免了成千上万次的网络往返——每个文件传一次数据是一万个来回,打包后传就是一个来回。
传完之后校验:
# 两边算校验和对比
md5sum /本地目录/重要文件.zip
ssh root@远程IP "md5sum /目标目录/重要文件.zip"
这一步在传数据库导出、安装包时必须做。 一个传了一半的压缩包,要到解压时才会报错,而那时候你可能已经覆盖了线上的文件。
还有两个传大文件时的实用技巧:
# 技巧一:断点续传,中断了重跑同一条命令即可接着传
rsync -avz --partial --progress /大文件 root@远程IP:/目标路径/
# 技巧二:限速,避免占满上行影响其他服务
rsync -avz --bwlimit=1000 /大文件 root@远程IP:/目标路径/
# 技巧三:传到一半先备份目标文件,成功后再替换(最稳的做法)
ssh root@远程IP "cp /目标/重要文件 /目标/重要文件.bak"
scp /本地/新文件 root@远程IP:/目标/重要文件.new
ssh root@远程IP "mv /目标/重要文件.new /目标/重要文件"
第三种做法值得单独强调:先传成 .new 文件,验证无误后再改名替换。 因为 Linux 的 mv 在同一个文件系统内是原子操作——要么旧文件还在,要么新文件已经到位,中间不存在「文件损坏」的中间状态。 传数据库备份、上传新版本程序时用这个方式,能避免「传了一半就把线上搞挂了」。
顺便说一下传文件的两种方向选择:
- 本地 → 服务器(上传):日常部署网站代码、传配置、传安装包;
- 服务器 → 本地(下载):拉数据库备份、拉日志排查问题、拉服务器上的文件。
下载日志做本地分析时有一个技巧,可以直接按条件筛选后再传:
# 只传最近一小时的错误日志,文件小很多
ssh root@远程IP "grep -E 'ERROR|FATAL' /var/log/app.log | tail -500" > 本地错误.log
# 只传指定日期范围的日志
ssh root@远程IP "awk '\$1 >= \"2026-11-01\"' /var/log/nginx/access.log" > 本地访问.log
这样传回来的文件只有几十 KB,分析起来比拉一个几百 MB 的原始日志快得多。
五、Windows VPS 的远程桌面:机制、步骤与性能调整

Windows 系统的 VPS 想要图形界面,用的是 RDP(远程桌面协议),和 SSH 是完全不同的两套东西。 SSH 连 Windows 只能拿到命令行,要看到桌面必须用 mstsc。
连接前的三项确认(在 Windows VPS 上用 PowerShell 执行):
# 确认远程桌面已开启,0 是开启
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections" | Select-Object fDenyTSConnections
# 确认防火墙规则已启用
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object DisplayName, Enabled
# 确认服务在运行且开机自启
Get-Service TermService | Select-Object Name, Status, StartType
如果第一项显示为 1(未开启),用这条命令打开:
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections" -Value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Restart-Service -Name TermService -Force
在本地发起连接:
- Windows:按 Win + R 输入 mstsc,在对话框填 IP;
- Mac:应用商店下载 Microsoft Remote Desktop;
- 手机:装 Microsoft Remote Desktop。
RDP 连接慢或卡顿的三个优化手段:
第一个是降低画质。 在 mstsc 连接对话框点「选项 → 显示」:
- 分辨率调低(比如 1280×720);
- 颜色质量改成「低」;
- 取消勾选「允许桌面组合」和「字体平滑」;
- 传输类型选「低画质」。
第二个是启用 UDP 传输。 RDP 默认走 TCP,丢包时会重传,体感就是一顿一顿。启用 UDP 后,网络抖动时的体验会明显改善:
# 用管理员权限的 PowerShell 执行
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value 1
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'MinEncryptionLevel' -Value 2
Restart-Service -Name TermService -Force
第三个是关掉远程桌面里用不到的功能:
# 关闭剪贴板同步(安全上也更好)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'fDisableClip' -Value 1
# 关闭磁盘映射
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'fDisableDisk' -Value 1
Restart-Service -Name TermService -Force
RDP 常见的三个报错:
| 报错 | 根因 | 处理 |
|---|---|---|
| 你的凭据不工作 | 用户名格式不对 | 用 .\Administrator 或 计算机名\Administrator |
| 远程桌面连接被拒绝 | 远程桌面没开或防火墙拦了 | 用 PowerShell 检查并打开 |
| 连接后黑屏或闪退 | 显卡驱动或分辨率问题 | 降低分辨率重试;卸载冲突的虚拟显卡驱动 |
关于「你的凭据不工作」这个报错,有必要多说两句机制。 Windows 的用户名格式有三种写法,服务端接受的规则和你本地显示的不一样:
# 三种常见的用户名格式,逐个试
# .\Administrator 本地计算机的 Administrator
# 计算机名\Administrator 完整形式
# Administrator 纯用户名,部分镜像不接受
还有一个隐蔽的原因:密码里包含中文或全角符号。 VPS 的初始密码由商家生成,如果里面包含了复制过程中被转成全角的符号,键盘输入时的实际字符就对不上了。遇到凭据错误,先试试在密码输入框里用 Ctrl+V 粘贴,而不是手动敲。
还有一个原因值得知道:Windows 的安全策略可能限制了这个账号从网络登录。 这是 Windows 服务器上的常见默认设置,症状就是「密码明明对,但远程桌面说凭据错误」:
# 检查是否允许网络登录
gpedit.msc
# 路径:计算机配置 → Windows 设置 → 安全设置 → 本地策略 → 安全选项
# 找「拒绝从网络访问此计算机」,把 guest 和本地账户从列表里去掉
最后提醒一句成本上的事:Windows VPS 的授权成本通常不包含在标价里。 同等预算下,Linux 的内存占用明显更低。只有在你确实需要 Windows 专有软件(比如某些 ERP、特定版本的 .NET 应用)时,Windows VPS 才值得付这个差价。
六、连上机器之后:第一分钟该做的五件事

登录成功不等于可以开始干活。 这一节是拿到 shell 之后的第一分钟清单,五件事做完再开始部署,能省掉后面很多麻烦。
第一件:确认硬件配置和订单一致。
# 内存
free -h
# CPU 核数和型号
nproc && lscpu | grep "Model name"
# 磁盘和挂载点
lsblk -f && df -h
为什么必须确认:VPS 是共享池中划分的资源配额,实际分配到的可能低于标称值。渠道库在售的机型从 1 GB 内存到 256 GB 都有:
| 机型 | 折合月价 | 内存 | 硬盘 | 月流量 | 每 GB 内存/月 |
|---|---|---|---|---|---|
| RosCloud-01 | 19.99 美元 | 1 GB | 20 GB | 1024 GB | 19.99 美元 |
| RosCloud-03 | 39.99 美元 | 4 GB | 80 GB | 3072 GB | 10.00 美元 |
| RosCloud-05 | 59.99 美元 | 16 GB | 240 GB | 5120 GB | 3.75 美元 |
| LAX-STARTER | 16.67 美元 | 2 GB | 40 GB | 5000 GB | 8.33 美元 |
| LAX-MEDIUM | 66.67 美元 | 8 GB | 160 GB | 20000 GB | 8.33 美元 |
| LAX-Storage-500G | 33.33 美元 | 4 GB | 500 GB | 10000 GB | 8.33 美元 |
| 云途 HK.DS.S | 800 元 | 128 GB | 6000 GB | 40000 GB | 6.25 元 |
| 云途 DS.ES.B | 1500 元 | 256 GB | 1920 GB | 30000 GB | 5.86 元 |
对照订单核对,发现不符就拍照申请调整,不要将就。 另外这张表还说明了一件事:内存单价随容量递减,RosCloud-01 是 19.99 美元/GB/月,LAX-MEDIUM 是 8.33 美元/GB/月,所以「先用小的试,不够再升」在单价上是划算的。
第二件:把系统时间校准。
timedatectl set-timezone Asia/Shanghai
timedatectl set-ntp true
timedatectl status
时间不对会让日志顺序错乱、证书校验失败、定时任务跑错时间,而且这些问题出现时很难立刻联想到是时间问题。
第三件:设置主机名。
hostnamectl set-hostname vps-web-01
第四件:改掉默认密码并收紧 SSH。 这一步在第三节已经讲过完整流程,这里只强调顺序:先确认密钥能登录,再关密码。
第五件:检查有没有你没主动装的东西。
# 开机自启的服务清单
systemctl list-unit-files --state=enabled | grep enabled
# CPU 占用最高的进程
ps aux --sort=-%cpu | head -15
# 监听的端口
ss -tulnp | grep LISTEN
这一步不是多疑。 VPS 被扫到之后被塞进挖矿程序的情况并不罕见,而挖矿程序的典型特征就是 CPU 长期跑满、内存占用高、有一个看不懂名字的进程。 上面三条命令能快速发现异常。
具体要警惕的信号有三个:
# 信号一:有个进程名字长得像随机字符串,占用接近满核
ps aux --sort=-%cpu | head -5 | awk 'NR>1 {print $3"% "$11}'
# 信号二:进程名里带 kdevtmpfs、kinsong、syscrypt 这些常见伪装名
ps aux | grep -Ei "kdevtmpfs|kinsong|syscrypt|xmr-stak" | grep -v grep
# 信号三:连接了矿池的常见端口(3333、4444、5555、7777、14444)
ss -tunp | grep -E ":(3333|4444|5555|7777|14444)"
发现这些的话,先不要慌着重装,先记下进程名和路径,再联系商家。 同时把出站端口收紧:
# 限制出站,只允许必要的端口
iptables -A OUTPUT -p tcp --dport 3333 -j DROP
iptables -A OUTPUT -p tcp --dport 4444 -j DROP
做完这五件事,你的机器才算真正「接手」了。 之后才是部署环节。
顺带说一句关于流量配额的事:渠道库里有些机型明确标了超额重置价,比如云途各档位的重置价在 200 到 500 美元之间,接近甚至超过它们的月租。所以在开始跑业务之前,最好先确认这台机器的流量配额和超额规则,这是上线前必须知道的一个数字。
七、连接不稳定:断连、卡顿、超时的完整排查

「能连上但老断」是另一类问题,根因通常不在 SSH 本身。 这一节按排查顺序给方法。
第一步:先看服务端日志,判断是谁断的。
grep -i "disconnect\|session closed\|timeout" /var/log/auth.log | tail -20
日志里的几种结果对应不同结论:
- Disconnected from user root ... [preauth]——认证阶段就断了,通常是密码错误或密钥不匹配;
- Disconnected from user root ... port xxx [idle]——空闲超时被服务端主动断开,这是最常见的一种;
- Received disconnect from ... port: ...:2: Too many authentication failures——尝试次数超限;
- Connection reset by peer——被防火墙或 fail2ban 主动拦截。
第二步:如果是空闲超时断开,加保活配置。
# 服务端配置
echo "ClientAliveInterval 60" >> /etc/ssh/sshd_config
echo "ClientAliveCountMax 3" >> /etc/ssh/sshd_config
sshd -t && systemctl reload sshd
# 客户端配置(写进 ~/.ssh/config)
# ServerAliveInterval 60
# ServerAliveCountMax 3
机制说明:ClientAliveInterval 60 表示服务端每 60 秒发一次心跳,ClientAliveCountMax 3 表示连续 3 次没回应才判定断开。 默认值往往是 0,也就是永不发送心跳,结果就是连接被中间的 NAT 设备静默掐断——表现是「网络是通的,连接却莫名其妙没了」。
第三步:如果是认证次数超限,明确指定密钥。
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_rsa [email protected]
第四步:查有没有被 fail2ban 封了。
# 当前被封的 IP
sudo fail2ban-client status sshd
# 解封自己
sudo fail2ban-client set sshd unbanip 你的IP
第五步:测网络基础质量。
# 丢包和延迟
ping -c 20 203.0.113.10
# 逐跳路径分析
mtr -r -c 20 203.0.113.10
mtr 结果的读法:中间某一跳延迟高、但后面的跳又正常,通常是那一跳对 ICMP 限速,不代表你的实际路径有问题;真正的信号是延迟在某一跳之后持续升高且不回落,那说明这条路径上有一段拥塞或绕路。
第六步:查服务器资源是不是耗尽了。
# 内存
free -h
# 磁盘
df -h
# 进程数,这个在 VPS 上很关键
ps -e --no-headers | wc -l
# 系统负载
uptime
「进程数爆掉」是 VPS 上很典型的一种故障,尤其在被塞入挖矿程序或失控循环任务时。表现就是网络明明通、SSH 却完全没反应——因为 sshd 无法 fork 新进程。
第七步:长任务的稳定性。
# 方案一:tmux,断线重连能恢复现场
apt install -y tmux
tmux new -s work
# 断线重连后
tmux attach -t work
# 方案二:nohup 后台跑,日志重定向
nohup your-command > /var/log/task.log 2>&1 &
tail -f /var/log/task.log
tmux 和 nohup 的区别:tmux 能交互——你可以在里面停进程、改参数、重新跑,对于需要观察和干预的长时间任务,它明显更合适。
八、十类常见报错对照表

这一节是前面内容的浓缩。遇到报错先在这里定位,找到对应行直接照做。
| 报错原文 | 根因 | 处理办法 |
|---|---|---|
Connection timed out |
机器没起、IP 错、端口错、网络不通 | nc -zv IP 端口 探测;核对 IP 和端口 |
Connection refused |
端口上没有服务在听 | ss -tlnp 查监听;看 sshd 状态 |
Permission denied (publickey,password) |
用户名或密码错、密钥没被接受 | 换用户名试;chmod 600 私钥;用 -vvv 看细节 |
Host key verification failed |
主机密钥变了 | ssh-keygen -R IP 后重连;确认是否重装过 |
Too many authentication failures |
本地密钥太多,试超次数 | ssh -o IdentitiesOnly=yes -i 指定密钥 |
UNPROTECTED PRIVATE KEY FILE |
私钥权限太开放 | chmod 600 ~/.ssh/id_rsa |
Connection reset by peer |
防火墙、fail2ban 或服务端主动断 | 查 fail2ban 状态和防火墙规则 |
kex_exchange_identification: Connection closed |
服务端版本协商失败 | ssh -o "KexAlgorithms=+diffie-hellman-group14-sha1" |
bind: Address already in use |
本地转发端口被占用 | 换一个本地端口号 |
channel open failed: administratively prohibited |
服务端禁止了端口转发 | 改用其他方式;查 sshd_config 的 AllowTcpForwarding |
你的凭据不工作 |
Windows 用户名或密码不对 | 用 .\Administrator 格式 |
The requested operation requires elevation |
Windows 权限不足 | 用 Administrator;确认远程桌面已开 |
这张表里前六条覆盖了绝大多数情况,记住这六条能解决大部分问题。
下面三条值得展开说说,因为它们的机制和别的报错不同:
kex_exchange_identification 的机制:连上 TCP 之后,双方要先协商加密算法版本,这个阶段就断了。 常见于客户端太老而服务端太新。如果你的 SSH 客户端是系统自带的旧版本,升级客户端是最彻底的解法;临时应急可以加上面那条命令指定一个旧算法。
Host key verification failed 的机制:本地 known_hosts 里存的记录和服务器现在的不一致。 删掉记录就行,但删之前先想一下为什么不一致——如果 IP 没变而你也没重装,那可能是中间设备在伪造连接,这时候删记录等于放行一个潜在的中间人。
bind: Address already in use 的机制:你指定的本地转发端口已经被别的程序占了。 换个端口号就行,但更根本的做法是改用端口 0,让系统自动分配一个空闲端口。
最后一个排查技巧:把 -vvv 加上,所有问题都能看到更细的信息。
ssh -vvv [email protected]
-v 是详细、-vv 更详细、-vvv 最详细。 排查时直接上 -vvv。
九、常见误区与进阶用法

这一节讲几件「看起来没关系但其实会浪费你时间」的事,以及几个能把连接体验提升一档的进阶用法。
四个常见误区:
误区一:以为能连上就说明配置达标。 连接成功只说明链路和认证没问题,说明不了这台机器的内存、磁盘、超售情况是否合格。这些必须单独测。
误区二:以为 ping 不通就是机器坏了。 禁 ping 是常规操作,用端口探测判断机器状态才准。
误区三:以为改端口就是安全了。 改端口挡住的只是自动扫描,真正的防线是密钥登录加禁用密码登录。 三件事都要做。
误区四:把 SSH 隧道当生产通道用。 SSH 转发有明显的性能损耗,连接不稳定时会断断续续。 它的定位是开发调试和临时访问,不是生产流量的通道。
四个进阶用法:
用法一:配置跳板机。 目标机器的 SSH 只对内网开放时:
ssh -J user@跳板机:22 root@目标服务器IP
用法二:端口转发访问内网服务。 第二节讲过的 -L,这里补充一个组合用法:
# 同时做端口转发和远程命令
ssh -L 3307:127.0.0.1:3306 [email protected] "命令"
# 指定本地绑定的地址,只允许本机访问,更安全
ssh -L 127.0.0.1:3307:127.0.0.1:3306 [email protected]
用法三:SOCKS 代理,把整台机器的流量走 VPS。 适合需要固定出口 IP 的场景:
# 建立 SOCKS5 代理
ssh -N -D 1080 [email protected]
# 之后把浏览器或程序的代理设置成 127.0.0.1:1080
用法四:复用 SSH 连接加速。 连续执行多条命令时,每次重新握手都要花掉几百毫秒到一秒。 复用连接能省掉这部分开销:
# 编辑 ~/.ssh/config
# ControlMaster auto
# ControlPath ~/.ssh/control-%h-%p-%r
# ControlPersist 10m
这行的意思是:第一个连接建立后保持 10 分钟,后续连接直接复用。
最后一个提醒,和安全有关:连上之后的每一台机器,都值得先看一眼 ~/.ssh/authorized_keys。
cat ~/.ssh/authorized_keys
如果发现里面有不认识的公钥,说明有人拿到过这台机器的写权限,应该立刻删掉并改密码。这个检查在你接手任何一台二手或者共享的机器时都要做。
按你的情况,下一步该看哪家
上面讲的是判断标准,但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条,直接去看对应的机型页比继续比价更快:
- 主要访客在国内、在意打开速度:先确认回程线路,再谈配置。看 iwebfusion 当前机型与价格
- 只是开发测试、临时用:按小时或月付,用完就删,别买年付。看 racknerd 当前机型与价格
价格与库存以商家页面当日显示为准,下单前建议先确认退款窗口与是否支持按月付费。
十、管理多台机器:别名、批量与密钥分发

管一台机器,命令行就够了;管十台以上,就得靠工具。 这一节讲从单台到多台时需要补上的一些做法。
第一步:把每台机器写成一条别名。
cat >> ~/.ssh/config << 'EOF'
Host web-01
HostName 203.0.113.10
User root
Port 22
IdentityFile ~/.ssh/id_vps
ServerAliveInterval 60
ServerAliveCountMax 3
Host db-01
HostName 203.0.113.20
User root
Port 22
IdentityFile ~/.ssh/id_vps
ServerAliveInterval 60
ServerAliveCountMax 3
EOF
之后 ssh web-01 就能连,不用再记 IP 和端口。 这个配置文件本身可以放进 Git 管理,团队共用。
第二步:用主机通配符批量执行。 SSH 原生支持这个功能:
# 对所有 web 开头的机器执行同一条命令
for h in web-*; do echo "=== $h ==="; ssh $h "uptime"; done
# 并行执行,机器多的时候快很多
for h in web-*; do ssh $h "uptime" & done; wait
第三步:批量分发公钥。 新机器加进来时,不用一台台手工输密码:
# 用 sshpass 自动输密码,需要先装
apt install -y sshpass
# 批量推公钥
for h in web-*; do
sshpass -p '初始密码' ssh-copy-id -i ~/.ssh/id_vps.pub root@$h 2>/dev/null
done
这一步用完之后,务必把初始密码改掉并且关掉密码登录。 批量推公钥本身是为了减少手工操作,但批量设置弱密码就是另一回事了。
第四步:用 SSH 密钥做 sudo 免密。 在需要执行管理脚本时很有用:
# 在服务器上执行
echo "root ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/99-nopasswd
chmod 440 /etc/sudoers.d/99-nopasswd
# 校验语法和权限,这一步不能省,权限不对 sudo 会直接拒绝加载
visudo -c
第五步:用 Ansible 类的工具做批量配置。 当你需要把同一套配置推到五台以上机器时,手工 SSH 循环会越来越难维护:
# Ansible 的最小可用示例
# 站点文件
# all:
# hosts:
# web-01:
# web-02:
# ansible site.yml -i inventory.ini
- name: 基础加固
hosts: all
become: yes
tasks:
- name: 更新系统
apt:
update_cache: yes
upgrade: dist
- name: 确认 SSH 配置语法
command: sshd -t
changed_when: false
注意这个例子里的一个细节:改 SSH 配置前先跑 sshd -t 校验。 这和第三节讲的是同一个原则——在批量操作里,一个语法错误会让所有机器同时失联。
第六步:把配置漂移管起来。 多台机器最常见的隐患是「这台改了那台没改」,排查起来极其耗时。一个低成本的做法是每次批量操作后留一份快照:
# 在每台机器上采集配置状态,存到本地做对比
for h in web-*; do
ssh $h "ss -tulnp; crontab -l" > /tmp/snapshot-$h.txt 2>&1
done
# 之后对比哪台不一样
diff /tmp/snapshot-web-01.txt /tmp/snapshot-web-02.txt
这个方法不专业,但能解决大部分「到底哪台不一样」的问题,而且不需要引入任何额外工具。
关于批量操作的几个纪律性建议:
- 先在一台上试,再推到全部。 批量操作里最贵的错误是「一次改错十台」;
- 改 SSH 配置这类高风险操作,永远留一个已知能连上的窗口不关;
- 批量执行前先备份,比如 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F),这样回滚是十秒钟的事;
- 不要把密码写进脚本。 第三节讲过密钥登录和 ssh-agent 的组合,批量操作用密钥,密码只用来做首次分发。
最后是关于 IP 管理的一条经验:给机器起有含义的名字,并记录它对应的 IP。
# 一个简单的资产记录方式
cat >> ~/.ssh/config << 'EOF'
# web-01 203.0.113.10 洛杉矶 2026-03 购买 跑前端
# db-01 203.0.113.20 洛杉矶 2026-05 购买 跑数据库
EOF
VPS 的一个现实特点是:IP 会变。 重装、迁移、商家调整路由都可能换 IP,而你的 DNS 解析、证书、白名单全都绑在这个 IP 上。把这张表维护好,下次 IP 变了你能立刻知道哪些地方需要跟着改。
关于价格的说明:本文涉及的价格与配置参数,来自渠道库在售机型快照(时间 2026-11-06 13:28),用于说明各场景的配置需求与量级关系;实际价格、库存与线路以商家官网当日报价为准。

喜欢
高兴
鬼脸
呵呵
无聊
伤心