ubuntu/debian 默认不启用 ssh 服务端，centos/rhel 默认已安装并启用 sshd；需先确认系统类型、服务名（ssh.service 或 sshd.service）、包是否安装及防火墙规则，再启动。
Ubuntu/Debian 默认不启用 SSH 服务端，CentOS/RHEL 默认已安装并启用 sshd；直接执行 systemctl start ssh 或 systemctl start sshd 很可能失败，因为服务名、包名、配置路径在不同发行版中并不统一——得先确认你用的是什么系统、装了哪个服务、监听哪个端口。
怎么判断 SSH 服务是否已安装且可用
别急着启动，先看有没有“东西”可启：
-
ssh -V只检查客户端（几乎总存在），不能说明服务端已装 - 查服务端包：Ubuntu/Debian 用
dpkg -l | grep openssh-server；CentOS/RHEL/Fedora 用rpm -qa | grep openssh-server - 查服务单元名：运行
systemctl list-unit-files | grep -E "(ssh|sshd)"，常见结果是ssh.service（Debian系）或sshd.service（RHEL系） - 查进程监听：
ss -tlnp | grep ':22'比netstat更可靠，若无输出，大概率没跑起来或换了端口
systemctl start ssh 失败的常见原因
报错 Failed to start ssh.service: Unit ssh.service not found 是最典型的信号，说明服务名不对。这不是权限或配置问题，而是根本没这个 unit 文件。
- Ubuntu 20.04+ 默认安装
openssh-server，对应服务名是ssh.service，不是sshd.service - CentOS 7/8、RHEL 8/9、Fedora 默认用
sshd.service，装的是openssh-server包，但 unit 名带d - 如果装了包却没对应 service，可能是安装不完整：
sudo apt install --reinstall openssh-server（Debian系）或sudo dnf reinstall openssh-server（Fedora） - 某些最小化安装镜像（如 Ubuntu Server Core）甚至默认不装
openssh-server，必须手动apt install openssh-server
防火墙放行前，连本地都连不上
即使 systemctl status ssh 显示 active (running)，ssh localhost 仍可能超时——十有八九是防火墙拦了。别跳过这步。
- Ubuntu 默认用
ufw：运行sudo ufw status verbose，若为Inactive可忽略；若为Active，必须加规则：sudo ufw allow 22（或自定义端口） - RHEL/CentOS 8+ 默认用
firewalld：运行sudo firewall-cmd --list-ports，没看到22/tcp就补上：sudo firewall-cmd --add-port=22/tcp --permanent && sudo firewall-cmd --reload - CentOS 6/7 若用
iptables，规则要写进/etc/sysconfig/iptables才能持久，临时加的iptables -A INPUT ...重启就丢 - 虚拟机用户额外注意：VirtualBox/VMware 的网络模式（NAT / Bridged）会影响宿主机能否访问 guest 的 22 端口
修改端口后 systemctl restart 不生效？
改完 /etc/ssh/sshd_config 里的 Port，只执行 systemctl restart ssh 是不够的——旧连接还在占着原端口，新配置没真正加载。
- 必须确认配置语法正确：
sudo sshd -t，返回空行才表示无语法错误 - 改端口后，
ufw或firewalld规则也得同步更新，否则外部请求根本到不了进程 - SELinux（RHEL/CentOS）可能阻止非标准端口：运行
sudo setsebool -P ssh_port_t 1并sudo semanage port -a -t ssh_port_t -p tcp 2222（以 2222 为例） - 改完一定要验证监听地址：
ss -tlnp | grep ':2222'，而不是只信systemctl status的“running”状态
最容易被忽略的是服务名和防火墙的耦合性：同一套命令在 Ubuntu 和 CentOS 上可能一个成功一个报错，不是命令错了，是发行版约定不同。动手前花 30 秒确认 systemctl list-unit-files | grep ssh 输出什么，比反复 restart 有用得多。
