根本原因是ssh握手阶段的dns反向解析；远程sshd配置usedns yes时，会对客户端ip执行阻塞式gethostbyaddr()查询，无ptr记录或dns慢则卡住30秒，paramiko connect()随之挂起。
根本原因不是代码，而是SSH握手阶段的DNS反向解析。Python用paramiko连接远程Linux服务器时卡在connect()、耗时十几秒甚至超时，大概率不是网络延迟，而是远程主机在建立SSH连接后，尝试对你的客户端IP做gethostbyaddr()反向DNS查询——而这个查询会默认阻塞，且超时长达30秒。
为什么Paramiko connect()会卡住十几秒
Paramiko本身不控制反向解析，它复用OpenSSH服务端行为。当远程sshd配置了UseDNS yes（RHEL/CentOS默认开启，Ubuntu默认关闭），每次新连接都会触发一次gethostbyaddr()调用。若客户端IP无PTR记录，或DNS服务器响应慢，sshd就干等，Paramiko的connect()也跟着挂住。
- 现象：调用
client.connect(hostname=...)后长时间无返回，strace能看到recvfrom()阻塞在AF_INET套接字上 - 验证方式：在远程服务器执行
sudo grep "reverse mapping" /var/log/secure，出现reverse mapping checking getaddrinfo即为确诊 - 注意：
timeout参数传给connect()只控制TCP连接建立，不控制后续SSH协议层的DNS等待
Paramiko连接超时设置的三个层级
Paramiko的timeout只管TCP握手；真正影响“卡住”体验的是底层SSH协议流程。必须分层处理：
-
timeout=5：仅作用于TCP三次握手，对DNS卡顿无效 -
auth_timeout=10：控制密钥/密码认证阶段总耗时，但反向解析发生在认证前 - 真正有效的是禁用远程
sshd的UseDNS——这是唯一能根治卡顿的配置
示例错误写法：client.connect(host, username='u', timeout=3, auth_timeout=3) —— 这无法解决DNS卡顿。
远程sshd配置必须改UseDNS no
登录远程Linux服务器，编辑/etc/ssh/sshd_config：
sudo sed -i 's/^#*UseDNS.*/UseDNS no/' /etc/ssh/sshd_config sudo systemctl restart sshd
- 不要只加
UseDNS no到文件末尾——如果前面有UseDNS yes未被注释，它仍生效 - 修改后必须
systemctl restart sshd，reload不够，旧连接不会重读该配置 - 该配置对所有SSH客户端生效，包括
ssh命令、VSCode Remote-SSH、Paramiko等，一劳永逸
/etc/hosts本地映射只是备选方案
如果无法修改远程sshd_config（如共享服务器无root权限），可在远程/etc/hosts中添加客户端IP的正向解析记录，绕过反向查询：
- 假设你本地IP是
192.168.1.100，主机名是laptop，则在远程执行：echo "192.168.1.100 laptop" | sudo tee -a /etc/hosts
- 注意：此法仅在远程能稳定解析你IP对应主机名时才有效；若IP是DHCP分配，每次变更都要同步更新
- 该方案治标不治本，且
/etc/hosts需维护多台客户端时成本陡增
真正的瓶颈永远在远程sshd配置，而非Paramiko代码怎么写。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
