1. 为什么今天还值得花时间把 SSH 远程访问这件事做扎实很多人第一次接触远程管理 Linux 主机都是从一条ssh userhost命令开始的。看起来简单但真正到了自己动手装系统、配网络、开远程的环节问题就一个接一个冒出来明明服务装好了却连不上、密码输对了却被拒绝、重启之后配置又失效了。Ubuntu 20.04 作为一个长期支持版本至今仍大量运行在各种开发机、测试服务器、家庭实验室和边缘设备上把它的 SSH 远程访问配置到位是一件投入产出比非常高的事情。这篇文章要解决的问题很具体在一台刚装好的 Ubuntu 20.04 上从零把 SSH 服务装起来并且让局域网内的其他机器能够稳定地远程登录进来。它适合三类人一是刚接触 Linux 服务端、想搞明白远程登录到底怎么回事的新手二是手头有闲置机器想做成开发或测试节点、需要一套可靠远程方案的开发者三是已经会敲命令但经常在权限、防火墙、配置持久化这些细节上翻车、想把知识补全的运维初学者。我见过太多人卡在“装完了但连不上”这一步最后靠重启、重装甚至放弃来收场。其实 SSH 远程访问涉及的环节并不多无非是服务端安装、服务状态、监听配置、认证方式、网络放行这几块但每一块都有容易忽略的细节。下面我会按照真实的操作顺序把每一步背后的原因讲清楚把常见的坑提前标出来让你一次配好、长期稳定。2. 装 SSH 之前先搞清楚服务端和客户端到底谁装谁2.1 一个高频误解Ubuntu 桌面版默认没有 SSH 服务端很多人以为 Ubuntu 自带 SSH其实要分情况。Ubuntu 桌面版默认只装了 SSH 的客户端也就是你能用ssh命令去连别人但别人连不进来因为服务端sshd根本没运行。而 Ubuntu Server 版在安装时如果勾选了相关选项通常会预装服务端。所以当你在一台桌面版机器上敲ssh localhost发现连接被拒绝时不要怀疑命令写错了先确认服务端在不在。判断方法很直接查服务状态systemctl status ssh如果返回Unit ssh.service could not be found说明服务端压根没装。如果显示active (running)那服务端已经在跑了。这个判断步骤建议放在最前面能省掉后面一堆无用排查。2.2 服务端与客户端包名不同别装错Ubuntu 里 SSH 相关的包主要有两个包名作用谁需要openssh-client提供 ssh 命令用于连接别人几乎所有机器默认都有openssh-server提供 sshd 服务允许别人连进来需要被远程访问的机器我们要装的是openssh-server。这里有个经验不要图省事直接装ssh这个元包虽然它通常会同时拉取客户端和服务端但在某些精简系统上行为不一致。明确装openssh-server意图清晰依赖也干净。提示安装前先执行sudo apt update否则可能因为软件源索引过期而装到旧版本甚至报找不到包。2.3 安装命令与安装后的第一反应安装本身一条命令sudo apt update sudo apt install openssh-server -y装完之后Ubuntu 的包管理机制通常会自动把ssh.service设为开机自启并立即启动。但“通常”不等于“一定”尤其是在容器、精简镜像或手动裁剪过的系统里。所以装完第一件事不是急着连而是确认服务真的起来了systemctl status ssh看到绿色的active (running)才算过关。如果没起来手动拉一下sudo systemctl enable --now sshenable负责开机自启--now表示同时立即启动这两个动作合在一起写是运维里的常用习惯能避免“这次起来了但重启后又没了”的尴尬。3. 服务起来了却连不上把监听、认证、网络三层逐一拆开3.1 先确认 sshd 到底在监听哪个地址和端口服务运行不代表它监听了你期望的地址。默认情况下OpenSSH 服务端监听0.0.0.0的 22 端口也就是所有网卡的 22 端口。但配置文件可能被改过或者系统里有多个网络接口导致行为不符合预期。查看监听状态sudo ss -tlnp | grep sshd这条命令会列出所有 TCP 监听端口以及对应的进程。正常应该看到类似0.0.0.0:22或*:22的输出。如果只看到127.0.0.1:22那说明服务端只监听本地回环外部机器永远连不进来问题就出在配置文件上。对应的配置项在/etc/ssh/sshd_config里关键两行是ListenAddress 0.0.0.0 Port 22ListenAddress决定监听哪些网卡地址Port决定端口。改完配置后必须重载服务才生效sudo systemctl reload ssh用reload而不是restart是因为 reload 不会断开已有连接对生产环境更友好。这个细节很多人不注意直接 restart结果把自己正在用的会话也踢掉了。3.2 认证失败密码明明对为什么还被拒连上了但登录被拒是第二类高频问题。原因通常有三个方向密码认证被禁用、用户被限制、或者密码本身有问题。先看密码认证开关。在sshd_config里PasswordAuthentication yes如果这行是no那密码登录直接被封死只能用密钥。有些加固过的系统默认就关掉了密码认证新手不知道就会一直卡在“密码正确却进不去”。再看用户限制。配置里可能有AllowUsers或DenyUsers指令只允许特定用户登录。比如写了AllowUsers deploy那你用其他账号怎么试都不行。检查方法sudo grep -E AllowUsers|DenyUsers|PermitRootLogin /etc/ssh/sshd_configPermitRootLogin也值得关注默认通常是prohibit-password意思是 root 不能用密码登录但可以用密钥。如果你正试图用 root 加密码登录被拒是正常的这是安全设计而非故障。3.3 网络层防火墙和网段这两关必须过服务正常、认证正常但就是连不上八成卡在网络层。Ubuntu 20.04 默认可能启用了ufw防火墙。查看状态sudo ufw status如果显示Status: active那就要确认 22 端口是否放行sudo ufw allow 22/tcp或者如果你改了端口把 22 换成实际端口。放行后再次查看状态应该能看到对应规则。除了防火墙还要确认两台机器在不在同一网段、能不能互相 ping 通。这一步经常被跳过但它是排查的基石。如果 ping 都不通那问题在路由或网段跟 SSH 本身没关系。确认被访问机器的 IPip addr show找到类似192.168.x.x或10.x.x.x的地址然后在另一台机器上ping这个地址。通了再谈 SSH不通就先解决网络连通性。注意如果你在虚拟机里操作还要确认虚拟机的网络模式。NAT 模式下外部机器无法直接访问虚拟机需要改成桥接模式或者配置端口转发。这是虚拟机环境里最常见的“连不上”原因没有之一。4. 让远程访问真正好用密钥登录、配置持久化与安全收尾4.1 从密码登录升级到密钥登录的完整流程密码登录能用但不够好。密钥登录更安全也更方便配好之后连密码都不用输。流程分三步生成密钥对、把公钥放到服务端、验证登录。在客户端机器上生成密钥对ssh-keygen -t ed25519 -C my-remote-key这里选ed25519而不是默认的rsa是因为 ed25519 更短、更快、安全性也足够是现代系统的推荐算法。命令会问你把密钥存哪直接回车用默认路径~/.ssh/id_ed25519即可。然后会问你要不要设密码短语设了更安全但每次登录要输不设则完全免密。个人开发机建议设一个服务器之间自动化调用可以不设。把公钥传到服务端最省事的方式是用ssh-copy-idssh-copy-id -i ~/.ssh/id_ed25519.pub user192.168.x.x这条命令会自动把公钥追加到服务端的~/.ssh/authorized_keys文件并处理好权限。如果系统里没有ssh-copy-id也可以手动复制公钥内容然后登录服务端粘贴进authorized_keys但一定要记得改权限chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys权限不对是密钥登录失败的头号原因。SSH 对权限极其敏感authorized_keys如果是 644 甚至 777服务端会直接拒绝使用它而且日志里往往只给一句模糊的提示让人摸不着头脑。4.2 配置持久化别让重启毁掉你的成果很多人配好之后能用一重启就回到解放前。原因通常是配置没写进文件或者服务没设开机自启。要保证持久化记住两件事第一所有对sshd_config的修改都要写进文件并保存改完执行sudo systemctl reload ssh。临时用命令行参数启动的方式不会持久。第二确认服务开机自启sudo systemctl is-enabled ssh返回enabled才算稳。如果是disabled执行sudo systemctl enable ssh补上。另外如果你改了端口或监听地址建议改完后先用sshd -t做一次配置语法检查sudo sshd -t这个命令只检查配置文件的语法不实际启动服务。如果配置写错了它会直接告诉你哪一行有问题。这个习惯能帮你在 reload 之前就发现错误避免把正在运行的服务搞挂。4.3 安全收尾几个不折腾但有效的加固动作远程访问能用之后花几分钟做点基础加固能挡掉大量自动化扫描和暴力尝试。以下动作都不复杂但效果明显。第一禁用 root 密码登录。在sshd_config里确保PermitRootLogin prohibit-password这样 root 只能用密钥登录密码爆破对 root 就无效了。第二考虑改默认端口。把 22 改成比如 2222能减少大量无差别扫描。改端口本身不是强安全措施但能显著降低日志噪音。改完记得同步更新防火墙规则和客户端的连接命令。第三限制登录用户。如果这台机器只给特定人用加一行AllowUsers yourname只允许指定用户登录其他账号一律拒绝简单粗暴但有效。第四装个fail2ban自动封禁反复失败的 IPsudo apt install fail2ban -y它默认就会监控 SSH 日志多次失败后自动临时封禁来源 IP。对暴露在较大网络里的机器这个工具性价比极高。提示每次改完sshd_config都先sudo sshd -t检查语法再sudo systemctl reload ssh。养成这个顺序能避免把自己锁在门外。如果真锁了还能通过本地终端或带外管理进去救回来。5. 那些文档里不写、但实际一定会遇到的坑5.1 连接超时和连接被拒绝是两码事这两个报错经常被混为一谈但指向的问题完全不同。Connection refused说明包到了目标机器但目标端口没有服务在监听问题在服务端。Connection timed out说明包根本没得到回应问题在中间网络或防火墙可能是路由不通、防火墙丢包、或者目标机器压根没开机。排查方向因此完全不同refused 去查 sshd 状态和监听地址timed out 去查网络连通性和防火墙。搞混这两个会在错误的方向上浪费大量时间。5.2 改了端口之后客户端和防火墙都要同步改端口是个连锁操作涉及三处服务端sshd_config的Port、防火墙放行规则、客户端的连接命令。任何一处没改都会连不上。我建议改端口时按这个顺序先改配置、再放行防火墙、reload 服务、最后用新端口测试。测试通过之前不要关掉旧端口的放行规则留一条后路。5.3 虚拟机、容器和云主机的差异要心里有数同样是 Ubuntu 20.04跑在物理机、虚拟机、容器和云主机上SSH 配置的注意点不一样。虚拟机要注意网络模式容器要注意 sshd 是否真的在容器内运行以及端口映射云主机要注意平台层面的安全组规则——这个规则在系统防火墙之外很多人只改了ufw却忘了安全组结果怎么都连不上。判断方法如果本机ssh localhost能通但外部连不上且系统防火墙已放行那大概率是平台层面的网络策略在拦。这时候要去平台控制台检查安全组或网络 ACL。5.4 日志是你最好的朋友遇到任何连不上的问题第一反应应该是看日志而不是反复试。服务端日志通常在sudo journalctl -u ssh -n 50或者直接看/var/log/auth.logsudo tail -f /var/log/auth.log客户端加-v参数也能看到详细的握手过程ssh -v user192.168.x.x-v可以叠加成-vv、-vvv信息越来越详细。握手卡在哪一步、用了哪种认证方式、服务端返回了什么全都看得见。学会读这些输出排查效率会提升一个档次。6. 一套可复用的检查清单与我的实际体会把上面所有内容浓缩成一套开机即用的检查顺序下次再遇到远程连不上按这个顺序走一遍基本都能定位服务端systemctl status ssh是否 runningss -tlnp | grep sshd监听地址和端口是否正确sshd_config里认证方式、用户限制是否符合预期ufw status防火墙是否放行对应端口两台机器能否互相 ping 通平台层面虚拟机网络模式、云安全组是否有额外限制看journalctl或auth.log确认服务端到底报了什么这套顺序的逻辑是从内到外、从服务到网络先确认本机服务没问题再往外一层层排查。反过来从外往里查容易在没问题的环节上反复折腾。我自己配过很多台 Ubuntu 20.04 的远程访问踩过的坑里印象最深的有两个。一个是密钥登录怎么都不行查了半天发现是authorized_keys权限被同步工具改成了 664SSH 直接拒绝使用另一个是云主机上系统防火墙放行了但安全组没放行白白折腾了一个多小时。这两个坑的共同点是问题不在你正在看的地方。所以排查时一定要有全局视角别死磕一个环节。最后分享一个提高效率的小习惯把常用的连接配置写进客户端的~/.ssh/config文件比如Host devbox HostName 192.168.x.x User yourname Port 2222 IdentityFile ~/.ssh/id_ed25519配好之后直接ssh devbox就能连不用每次敲一长串参数。机器多了之后这个文件的价值会越来越明显。远程访问这件事配一次、稳很久前期多花二十分钟把细节做对后面能省下无数次的重复排查。
