别再乱试了！Jetson Orin (Ubuntu 20.04) SSH无法连接的终极检查清单

Jetson Orin (Ubuntu 20.04) SSH连接故障排查终极指南

当你兴奋地拿到全新的Jetson Orin设备，准备通过SSH进行远程开发时，却发现无论如何都无法建立连接——这种挫败感每个开发者都深有体会。本文将带你系统性地排查Ubuntu 20.04系统上SSH连接失败的各类原因，从基础检查到深度配置，提供一份真正有效的解决方案清单。

1. 基础网络连通性检查

在深入SSH配置之前，首先要确认最基本的网络连接是否正常。很多情况下，问题就出在这些看似简单的基础环节。

本地回环测试是第一步。在终端执行：

ping 127.0.0.1

如果连本地回环都不通，说明TCP/IP协议栈可能存在问题。此时需要检查网络接口状态：

ip addr show

典型输出应包含类似内容：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever

注意：如果lo接口状态不是UP，需要手动启用：sudo ip link set lo up

接下来检查物理网络接口。对于有线连接，使用：

sudo ethtool eth0

查看"Link detected"是否为yes。无线网络则需检查：

nmcli device wifi list nmcli device wifi connect [SSID] password [PASSWORD]

2. SSH服务状态诊断

确认网络正常后，下一步是检查SSH服务本身是否正常运行。执行以下命令查看服务状态：

sudo systemctl status ssh

健康状态应显示"active (running)"。如果服务未运行，尝试启动：

sudo systemctl start ssh sudo systemctl enable ssh # 设置开机自启

常见问题包括：

• 服务配置文件缺失：/lib/systemd/system/ssh.service不存在
• 依赖包未安装：openssh-server可能未正确安装

修复方案：

sudo apt install --reinstall openssh-server sudo systemctl daemon-reload

3. 端口与防火墙配置

SSH默认使用22端口，需要确保该端口未被占用且防火墙允许通过。

检查端口监听状态：

sudo netstat -tulnp | grep :22

正常应显示sshd正在监听。如果没有输出，可能是：

• 其他服务占用了22端口
• sshd配置了非标准端口

UFW防火墙配置：

sudo ufw status # 查看状态 sudo ufw allow 22 # 允许SSH端口 sudo ufw enable # 启用防火墙

对于更复杂的iptables规则，检查：

sudo iptables -L -n -v

如果发现DROP规则，需要添加允许规则：

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

4. SSH主机密钥问题

"no hostkeys available"是Jetson Orin上常见的错误，通常出现在新系统或重置后。解决方案是重新生成主机密钥：

sudo rm /etc/ssh/ssh_host_* sudo dpkg-reconfigure openssh-server sudo ssh-keygen -A

关键点：

1. 删除旧密钥文件
2. 重新配置openssh-server
3. 生成新的主机密钥

完成后验证：

sudo sshd -T # 测试配置 sudo systemctl restart ssh

5. 高级配置调优

对于仍然无法连接的情况，可能需要调整SSH配置文件/etc/ssh/sshd_config：

sudo nano /etc/ssh/sshd_config

确保以下关键参数设置正确：

Port 22 ListenAddress 0.0.0.0 PermitRootLogin prohibit-password PasswordAuthentication yes

修改后必须重启服务：

sudo systemctl restart ssh

6. 日志分析与故障定位

当所有常规检查都通过但仍无法连接时，查看系统日志是最后的手段：

journalctl -u ssh -b # 查看本次启动后的ssh日志 sudo tail -f /var/log/auth.log # 实时认证日志

典型错误模式：

• "Connection refused"：服务未运行或端口被阻止
• "No route to host"：网络问题
• "Permission denied"：认证失败

7. 备选方案与测试技巧

如果经过上述步骤问题依旧，可以尝试这些备选方案：

临时使用Telnet测试端口：

sudo apt install telnetd telnet localhost 22

创建最小测试环境：

sudo sshd -D -d -e -p 2222 # 前台调试模式

网络数据包捕获：

sudo tcpdump -i any port 22 -vv

记住，每次修改配置后，都应该先在本机测试：

ssh localhost

成功后再尝试从外部连接。

8. 系统级深度检查

对于顽固问题，可能需要检查系统级配置：

SELinux/AppArmor状态：

sudo aa-status # AppArmor sudo sestatus # SELinux

系统资源限制：

ulimit -a # 用户限制 cat /proc/sys/net/core/somaxconn # 系统连接数

内核模块检查：

lsmod | grep ssh

这些深度检查往往能发现隐藏的系统级限制。