VMware Ubuntu 虚拟机克隆 GitHub 仓库踩坑记录
VMware Ubuntu 虚拟机克隆 GitHub 仓库踩坑记录：从 DNS 失败到 SSH 公钥配置
背景
最近在 VMware Ubuntu 虚拟机里准备克隆自己的 GitHub 仓库：
1 | git clone git@github.com:chenh735/TinyWebServer.git |
结果一开始就失败了：
1 | ssh: Could not resolve hostname github.com: Temporary failure in name resolution |
看起来像是 GitHub 或 SSH 的问题，但后面排查发现，真正的问题分成了两层：
- 虚拟机网络没有正常连通，导致无法解析
github.com。 - 网络恢复后，虚拟机没有配置 GitHub SSH key，导致
Permission denied (publickey)。
这篇文章记录一下完整排查过程。
第一阶段：确认不是 GitHub 权限问题，而是网络问题
最开始的报错是：
1 | Could not resolve hostname github.com |
这个错误表示系统无法把 github.com 解析成 IP 地址。于是先测试 DNS：
1 | ping github.com |
结果：
1 | ping: github.com: 域名解析出现暂时性错误 |
这说明 DNS 解析失败。但 DNS 失败不一定只是 DNS 配置错，也可能是虚拟机根本没有联网。所以继续测试公网 IP：
1 | ping 8.8.8.8 |
结果：
1 | ping: connect: 网络不可达 |
这一步很关键。8.8.8.8 是直接访问 IP，不需要 DNS。如果连它都不通，说明问题不是 GitHub，也不是 SSH，而是虚拟机网络本身不可达。
第二阶段：检查 VMware 网络适配器
在 VMware 设置里，虚拟机网络适配器使用的是 NAT 模式：
1 | Network Adapter -> NAT |
一开始看到 Connected 选项在关机时是灰色未勾选，以为这是问题。但后来发现这是 VMware 的正常行为：
- 虚拟机关机时，
Connected可能显示为灰色，无法切换。 - 虚拟机运行时，
Connected才表示当前虚拟网卡是否连接。 - 真正决定开机自动连接的是
Connect at power on。
虚拟机启动后，网卡确实显示为 connected，但是 Ubuntu 里还是没有 IP。
执行：
1 | ip link |
一开始看到：
1 | ens33: <NO-CARRIER,BROADCAST,MULTICAST,UP> state DOWN |
NO-CARRIER 表示 Ubuntu 能看到网卡，但 VMware 没有给它真正接上链路。后来通过 VMware 菜单和网络模式调整后（VMware NAT Service和VMnetDHCP重启服务），NO-CARRIER 消失，网卡变成：
1 | ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> state UP |
这说明虚拟网线已经接上。
第三阶段：DHCP 获取 IP 失败
网卡链路恢复后，再查看 NetworkManager 状态：
1 | nmcli device status |
曾经出现过：
1 | ens33 ethernet 连接中（正在获取 IP 配置） netplan-ens33 |
但最后连接失败：
1 | 错误：连接激活失败：IP 配置无法保留（无可用地址、超时等） |
这说明链路通了，但 DHCP 没有给虚拟机分配 IPv4 地址。
于是打开 Windows 主机上的 VMware Virtual Network Editor，检查 VMnet8：
1 | VMnet8 |
这里看起来正常。为了进一步排查，也尝试过给 Ubuntu 手动配置静态 IP：
1 | sudo nmcli connection modify netplan-ens33 ipv4.method manual ipv4.addresses 192.168.136.128/24 ipv4.gateway 192.168.136.2 ipv4.dns "8.8.8.8 1.1.1.1" |
此时 Ubuntu 有了静态 IP：
1 | inet 192.168.136.128/24 |
但测试 NAT 网关失败：
1 | ping 192.168.136.2 |
结果：
1 | Destination Host Unreachable |
后来发现，当时虚拟机实际还处在桥接模式，而静态 IP 配的是 NAT 的 VMnet8 网段，所以当然无法访问 192.168.136.1 或 192.168.136.2。
切回 NAT 模式后，再把 Ubuntu 网络恢复为 DHCP：
1 | sudo nmcli connection modify netplan-ens33 ipv4.method auto |
之后网络恢复正常。
第四阶段：验证网络恢复
网络恢复后，依次测试：
1 | ping 192.168.136.1 |
这四个都能 ping 通，分别说明：
192.168.136.1通：虚拟机能访问 Windows 主机侧的 VMnet8。192.168.136.2通：VMware NAT 网关正常。8.8.8.8通：虚拟机可以访问外网。github.com通：DNS 解析也恢复正常。
到这里，最开始的 Could not resolve hostname github.com 问题已经解决。
第五阶段：GitHub SSH 权限问题
网络恢复后再次执行：
1 | git clone git@github.com:chenh735/TinyWebServer.git |
这次已经能连上 GitHub，但出现新的报错：
1 | git@github.com: Permission denied (publickey). |
这个错误说明网络已经没问题了，但是当前虚拟机没有被 GitHub 认可的 SSH 私钥。
虽然 Windows 主机上已经有 SSH key，但虚拟机是独立系统，里面并没有自动继承主机的 SSH 配置。更推荐的做法是在虚拟机里单独生成一套 SSH key，而不是复制主机私钥。
在虚拟机中执行：
1 | ssh-keygen -t ed25519 -C "你的GitHub邮箱" |
一路回车，然后查看公钥：
1 | cat ~/.ssh/id_ed25519.pub |
复制整行公钥，打开 GitHub：
1 | Settings -> SSH and GPG keys -> New SSH key |
Title 可以写：
1 | Ubuntu VMware |
Key 粘贴虚拟机里的 id_ed25519.pub 内容。
添加后测试：
1 | ssh -T git@github.com |
如果看到类似：
1 | Hi chenh735! You've successfully authenticated... |
说明 SSH 配置成功。
最后重新克隆：
1 | cd ~/project/github |
成功。
排查思路总结
这次问题看起来是 git clone 失败，但不能一上来就判断是 Git 或 GitHub 权限问题。比较清晰的排查顺序是：
1 | git clone 失败 |
几个关键判断：
1 | Could not resolve hostname github.com |
优先查 DNS 和网络。
1 | ping 8.8.8.8: 网络不可达 |
说明不是 DNS，而是虚拟机没有联网。
1 | ens33: NO-CARRIER |
说明 Ubuntu 看到了网卡，但 VMware 没有真正接上链路。
1 | IP 配置无法保留（无可用地址、超时等） |
说明链路可能已经通了，但 DHCP 没有分配地址。
1 | Permission denied (publickey) |
说明网络已经连到 GitHub 了，但 SSH key 没配置好。
常用命令速查
查看网卡：
1 | ip link |
查看 NetworkManager 设备状态：
1 | nmcli device status |
重启 NetworkManager：
1 | sudo systemctl restart NetworkManager |
重连网卡连接：
1 | sudo nmcli connection down netplan-ens33 |
恢复 DHCP：
1 | sudo nmcli connection modify netplan-ens33 ipv4.method auto |
配置静态 IP 示例：
1 | sudo nmcli connection modify netplan-ens33 ipv4.method manual ipv4.addresses 192.168.136.128/24 ipv4.gateway 192.168.136.2 ipv4.dns "8.8.8.8 1.1.1.1" |
测试 GitHub SSH：
1 | ssh -T git@github.com |
生成 SSH key：
1 | ssh-keygen -t ed25519 -C "你的GitHub邮箱" |
最终结论
这次问题不是单一原因，而是连续遇到了两层问题：
- VMware 虚拟机网络配置不稳定，导致 Ubuntu 无法联网和解析 GitHub。
- 网络恢复后，虚拟机没有单独配置 GitHub SSH key，导致 SSH 克隆被拒绝。
最终通过切回 NAT、恢复 DHCP、验证网关和 DNS，再给虚拟机单独添加 GitHub SSH key，成功完成仓库克隆。
