配置 QEMU (Guest Debian-9.0 Sparc64 - Host MacOS High Sierra) 执行从来宾到主机的 ssh
Configure QEMU (Guest Debian-9.0 Sparc64 - Host MacOS High Sierra) to do ssh from guest to host
首先，使用 QEMU Virtual Machine (Debian Sparc64 Etch 4.0)，我已经能够成功地从来宾到主机 (MacOS Hight Sierra OS 10.13.3) 获得 ssh 和 scp 命令。
我只想在来宾和主机之间传输文件。
为了得到它，我遵循了这个 tutorial :
1) 我已经安装了TUN/TAP drivers
2) 像这样启动 QEMU：
qemu-system-sparc -boot c -hda debian_etch.img -m 512M -net nic -net tap,script=no,downscript=no
3) VM 启动后，在 MacOS 主机上执行：ifconfig tap0 192.168.10.1
4) 在 Debian Etch 主机上，进入 /etc/network/interfaces :
auto eth0
iface eth0 inet static
address 192.168.10.2
netmask 255.255.255.0
gateway 192.168.10.1
正在做：/etc/init.d/networking restart
5) 最后，对客人进行制作：$ scp -r dir user_host@192.168.10.1:~/
现在，我想和一位“Debian Sparc64 Stretch 9.0”客人做同样的事情。
最近的 Debian 版本似乎已弃用 ifconfig。
无论如何，我尝试使用 :
启动 Sparc64 映像
qemu-system-sparc64 \
-drive file=debian-9.0-sparc64.qcow2,if=none,id=drive-ide0-0-1,format=qcow2,cache=none \
-m 1024 \
-boot c \
-net nic \
-net tap,ifname=tap0,script=no,downscript=no \
-nographic
并再次执行步骤 1),3),4) 但不幸的是，来自访客的 ssh 和 scp 不起作用。
我必须注意这个 Debian Sparc64 9.0 来宾，网络逻辑名称正在改变（可能是每次启动）。例如，/etc/network/interfaces 包含：
auto enp0s5
allow-hotplug enp0s5
iface enp0s5 inet static
address 192.168.10.2
netmask 255.255.255.0
gateway 192.168.10.1
最后，我从客人那里得到以下结果：
# ssh user_host@192.168.10.1
ssh: connect to host 192.168.10.1 port 22: No route to host
ip a 给出：
# ip a
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
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global enp0s5
valid_lft forever preferred_lft forever
inet6 fec0::5054:ff:fe12:3456/64 scope site mngtmpaddr dynamic
valid_lft 86207sec preferred_lft 14207sec
inet6 fe80::5054:ff:fe12:3456/64 scope link
valid_lft forever preferred_lft forever
如果有人能给我一些线索来修复它并让 ssh/scp 命令从来宾到主机工作（我没有在来宾上联网，也没有 sshd server，所以我只想要方向guest-->host 对于 ssh/scp).
更新 1：
我继续调试这个问题。
1) 首先，从 this link 开始，我在每次启动时将客户机 "Debian 9.0 Sparc64" 的网络接口重命名为 eth0 :
vi /etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="52:54:00:12:34:56", NAME="eth0"
with MAC adress 给出者：
$ip a
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
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe12:3456/64 scope link
valid_lft forever preferred_lft forever
2) 我在主机 MacOS High Sierra 的 TAP 接口上使用 tcpdump :
# tcpdump -vv -i tap0
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:23:06.112155 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:06.112228 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:07.128440 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:07.128499 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:08.152323 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:08.152381 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:11.119346 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:11.119396 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:12.120190 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:12.120250 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:13.145028 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:13.145075 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:16.127525 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:16.127575 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:17.145202 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:17.145272 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
我是否应该断定来宾（192.168.10.2 on guest /etc/network/interfaces）和主机（192.168.10.1 set by ifconfig tap0 192.168.10.1）正在通信，因为我看到两个地址都带有 tcpdump 以上 ?
如果我在主机上执行 tcpdump -vv -i tap0，同时在客户机上重新启动网络，我得到：
00:27:07.648620 IP6 (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:07.804644 IP6 (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:08.569140 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) :: > ff02::1:ff12:3456: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::5054:ff:fe12:3456
unknown option (14), length 8 (1):
0x0000: 3bd4 4c86 3dd6
00:27:08.612632 IP (tos 0x0, ttl 255, id 37381, offset 0, flags [none], proto UDP (17), length 118)
192.168.10.1.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QU)? 6.5.4.3.2.1.e.f.f.f.0.0.4.5.0.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
00:27:09.592322 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::5054:ff:fe12:3456 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:09.592483 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::5054:ff:fe12:3456 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
source link-address option (1), length 8 (1): 52:54:00:12:34:56
0x0000: 5254 0012 3456
00:27:09.616466 IP (tos 0x0, ttl 255, id 18614, offset 0, flags [none], proto UDP (17), length 118)
192.168.10.1.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QM)? 6.5.4.3.2.1.e.f.f.f.0.0.4.5.0.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
00:27:09.976787 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::5054:ff:fe12:3456 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
这些消息中是否包含有用的信息，以便 ssh/scp 从来宾到主机？
最后，guest eth0有如下状态(UNKNOWN)是否正常：
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN
??
更新 2： 我也尝试通过使用 guestfwd 标志和“-net tap”标志来启动，如下所示：
qemu-system-sparc64 \
-boot c \
-hda debian-9.0-sparc64.qcow2 \
-net nic \
-net tap,ifname=tap0,script=no,downscript=no \
-net 'user,guestfwd=tcp::22-tcp::22' \
-m 1024 \
-nographic
但仍然无法从来宾到主机进行 ssh 访问。
我不知道，在 -net 'user,guestfwd=tcp::22-tcp::22' 中，我必须按什么顺序放置来宾和主机的 IP 以及它们各自使用的端口（我在这里使用 22两者)
如果有人能给我一些关于“guestfwd”标志的精确度。
更新 3：
最后，通过在 MacOS 主机上（以 root 身份）执行以下操作解决了该问题：
1) 使用“ifconfig bridge0 192.168.10.1”
在 bridge0 上设置 IP 190.168.10.1
2) 使用以下命令启动 Qemu：
qemu-system-sparc64 \
-boot c \
-hda debian-9.0-sparc64.qcow2 \
-device virtio-balloon \
-net nic,model=virtio,macaddr=52:54:00:12:34:56 \
-vga none \
-net tap,ifname=tap0,script=no,downscript=no \
-m 1024 \
-nographic
MAC 地址 52:54:00:12:34:56 很重要。
3) 启动 Qemu 后，将 tap0 接口添加到 bridge0 : ifconfig bridge0 addm tap0
4) 最后，我可以从来宾 Debian Sparc64 连接到 MacOS 主机（作为简单用户或 root）：
ssh user_host@192.168.10.1
一些备注：
是的，ifconfig 已被弃用，但据我所知，至少六年左右以来一直如此，而且它仍然存在……这是有原因的。我想你可以放心地使用它。
关于您的 tcpdump 摘录：您认为它包含有用信息的感觉是正确的。虽然它没有显示来宾和主机之间的真实通信，但它显示了 ARP 个查询。 ARP 是地址解析协议，需要它的原因如下：
基本上，只要TCP/IP堆叠在Ethernet之上，计算机（无论是否虚拟）都需要知道以太网硬件地址（MAC（媒体通信伙伴的访问控制）地址）。
因此，如果 IP 地址为 a.a.a.a 的计算机 A 想要与 IP 地址为 b.b.b.b 的计算机 B 对话，A 需要先知道 B 的 MAC 地址。因此，A发送一个以太网广播帧到本地以太网网段（基本上，一个广播帧是一个帧，该帧发送到 所有 台连接到相应网段的机器），询问："I need to talk to the guy which has IP address b.b.b.b. If any of you guys out there has this IP address, what is your Ethernet MAC address?".
您的 tcpdump 摘录表明此 ARP 解决方案失败。您的客人一遍又一遍地询问，却从未得到答案。只要是这种情况，来宾就无法与主机进行 any TCP/IP 通信。
所以您的问题不仅与 SCP/SSH 有关，而且与一般的 IP 协议有关。例如，来宾将无法显示位于主机上的网站。
此外，由于房东不想发送答案，任何其他客人都会遇到同样的问题。我强烈认为，如果您以完全相同的方式启动它的 VM，并且在具有与新 debian stretch.
当然，来自来宾的 ARP 请求首先到达连接来宾 VM 的 TAP 的 bridge。只要该网桥没有分配给客人请求的 IP 地址，客人的 ARP 请求就不会得到答复。这个问题通常通过以下方式解决：
在主机上，从物理网络接口中取出IP地址，并将其分配给网桥。然后网桥回答访客的 ARP 查询。但这还不能让你到任何地方，因为现在你不能再使用主机的物理网络接口（你已经拿走了它的 IP 地址）。
因此，您也将主机的物理网络接口连接到网桥。通常，这是一个静态配置，即它不是在启动 VM 时动态完成的。这意味着主机上的 OS 配置为创建网桥并在启动时将其物理网络接口添加到网桥。相反，来宾的 TAP 在来宾启动时动态添加到桥中，并在来宾关闭时从桥中删除。
动态添加和删除访客的 TAP 到主机的网桥通常是通过您为 -tap ... 配置选项提供的 upscript 和 downscript 参数完成的。显然，您正在手动执行此操作（更新 3 的第 3 项）。
总而言之，您的问题是房东没有回答房客的ARP询问。发生这种情况是因为这些查询到达了 VM 的 TAP 所连接的网桥，但您没有为该网桥分配 IP 地址（更准确地说，至少不是来宾的 ARP 查询要求的 IP 地址）。
首先，使用 QEMU Virtual Machine (Debian Sparc64 Etch 4.0)，我已经能够成功地从来宾到主机 (MacOS Hight Sierra OS 10.13.3) 获得 ssh 和 scp 命令。
我只想在来宾和主机之间传输文件。
为了得到它，我遵循了这个 tutorial :
1) 我已经安装了TUN/TAP drivers
2) 像这样启动 QEMU：
qemu-system-sparc -boot c -hda debian_etch.img -m 512M -net nic -net tap,script=no,downscript=no
3) VM 启动后，在 MacOS 主机上执行：ifconfig tap0 192.168.10.1
4) 在 Debian Etch 主机上，进入 /etc/network/interfaces :
auto eth0
iface eth0 inet static
address 192.168.10.2
netmask 255.255.255.0
gateway 192.168.10.1
正在做：/etc/init.d/networking restart
5) 最后，对客人进行制作：$ scp -r dir user_host@192.168.10.1:~/
现在，我想和一位“Debian Sparc64 Stretch 9.0”客人做同样的事情。
最近的 Debian 版本似乎已弃用 ifconfig。
无论如何，我尝试使用 :
启动 Sparc64 映像qemu-system-sparc64 \
-drive file=debian-9.0-sparc64.qcow2,if=none,id=drive-ide0-0-1,format=qcow2,cache=none \
-m 1024 \
-boot c \
-net nic \
-net tap,ifname=tap0,script=no,downscript=no \
-nographic
并再次执行步骤 1),3),4) 但不幸的是，来自访客的 ssh 和 scp 不起作用。
我必须注意这个 Debian Sparc64 9.0 来宾，网络逻辑名称正在改变（可能是每次启动）。例如，/etc/network/interfaces 包含：
auto enp0s5
allow-hotplug enp0s5
iface enp0s5 inet static
address 192.168.10.2
netmask 255.255.255.0
gateway 192.168.10.1
最后，我从客人那里得到以下结果：
# ssh user_host@192.168.10.1
ssh: connect to host 192.168.10.1 port 22: No route to host
ip a 给出：
# ip a
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
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global enp0s5
valid_lft forever preferred_lft forever
inet6 fec0::5054:ff:fe12:3456/64 scope site mngtmpaddr dynamic
valid_lft 86207sec preferred_lft 14207sec
inet6 fe80::5054:ff:fe12:3456/64 scope link
valid_lft forever preferred_lft forever
如果有人能给我一些线索来修复它并让 ssh/scp 命令从来宾到主机工作（我没有在来宾上联网，也没有 sshd server，所以我只想要方向guest-->host 对于 ssh/scp).
更新 1：
我继续调试这个问题。
1) 首先，从 this link 开始，我在每次启动时将客户机 "Debian 9.0 Sparc64" 的网络接口重命名为 eth0 :
vi /etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="52:54:00:12:34:56", NAME="eth0"
with MAC adress 给出者：
$ip a
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
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe12:3456/64 scope link
valid_lft forever preferred_lft forever
2) 我在主机 MacOS High Sierra 的 TAP 接口上使用 tcpdump :
# tcpdump -vv -i tap0
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:23:06.112155 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:06.112228 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:07.128440 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:07.128499 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:08.152323 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:08.152381 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:11.119346 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:11.119396 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:12.120190 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:12.120250 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:13.145028 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:13.145075 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:16.127525 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:16.127575 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:17.145202 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:17.145272 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
我是否应该断定来宾（192.168.10.2 on guest /etc/network/interfaces）和主机（192.168.10.1 set by ifconfig tap0 192.168.10.1）正在通信，因为我看到两个地址都带有 tcpdump 以上 ?
如果我在主机上执行 tcpdump -vv -i tap0，同时在客户机上重新启动网络，我得到：
00:27:07.648620 IP6 (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:07.804644 IP6 (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:08.569140 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) :: > ff02::1:ff12:3456: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::5054:ff:fe12:3456
unknown option (14), length 8 (1):
0x0000: 3bd4 4c86 3dd6
00:27:08.612632 IP (tos 0x0, ttl 255, id 37381, offset 0, flags [none], proto UDP (17), length 118)
192.168.10.1.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QU)? 6.5.4.3.2.1.e.f.f.f.0.0.4.5.0.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
00:27:09.592322 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::5054:ff:fe12:3456 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:09.592483 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::5054:ff:fe12:3456 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
source link-address option (1), length 8 (1): 52:54:00:12:34:56
0x0000: 5254 0012 3456
00:27:09.616466 IP (tos 0x0, ttl 255, id 18614, offset 0, flags [none], proto UDP (17), length 118)
192.168.10.1.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QM)? 6.5.4.3.2.1.e.f.f.f.0.0.4.5.0.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
00:27:09.976787 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::5054:ff:fe12:3456 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
这些消息中是否包含有用的信息，以便 ssh/scp 从来宾到主机？
最后，guest eth0有如下状态(UNKNOWN)是否正常：
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN
??
更新 2： 我也尝试通过使用 guestfwd 标志和“-net tap”标志来启动，如下所示：
qemu-system-sparc64 \
-boot c \
-hda debian-9.0-sparc64.qcow2 \
-net nic \
-net tap,ifname=tap0,script=no,downscript=no \
-net 'user,guestfwd=tcp::22-tcp::22' \
-m 1024 \
-nographic
但仍然无法从来宾到主机进行 ssh 访问。
我不知道，在 -net 'user,guestfwd=tcp::22-tcp::22' 中，我必须按什么顺序放置来宾和主机的 IP 以及它们各自使用的端口（我在这里使用 22两者)
如果有人能给我一些关于“guestfwd”标志的精确度。
更新 3：
最后，通过在 MacOS 主机上（以 root 身份）执行以下操作解决了该问题：
1) 使用“ifconfig bridge0 192.168.10.1”
bridge0 上设置 IP 190.168.10.1
2) 使用以下命令启动 Qemu：
qemu-system-sparc64 \
-boot c \
-hda debian-9.0-sparc64.qcow2 \
-device virtio-balloon \
-net nic,model=virtio,macaddr=52:54:00:12:34:56 \
-vga none \
-net tap,ifname=tap0,script=no,downscript=no \
-m 1024 \
-nographic
MAC 地址 52:54:00:12:34:56 很重要。
3) 启动 Qemu 后，将 tap0 接口添加到 bridge0 : ifconfig bridge0 addm tap0
4) 最后，我可以从来宾 Debian Sparc64 连接到 MacOS 主机（作为简单用户或 root）：
ssh user_host@192.168.10.1
一些备注：
是的，ifconfig 已被弃用，但据我所知，至少六年左右以来一直如此，而且它仍然存在……这是有原因的。我想你可以放心地使用它。
关于您的 tcpdump 摘录：您认为它包含有用信息的感觉是正确的。虽然它没有显示来宾和主机之间的真实通信，但它显示了 ARP 个查询。 ARP 是地址解析协议，需要它的原因如下：
基本上，只要TCP/IP堆叠在Ethernet之上，计算机（无论是否虚拟）都需要知道以太网硬件地址（MAC（媒体通信伙伴的访问控制）地址）。
因此，如果 IP 地址为 a.a.a.a 的计算机 A 想要与 IP 地址为 b.b.b.b 的计算机 B 对话，A 需要先知道 B 的 MAC 地址。因此，A发送一个以太网广播帧到本地以太网网段（基本上，一个广播帧是一个帧，该帧发送到 所有 台连接到相应网段的机器），询问："I need to talk to the guy which has IP address b.b.b.b. If any of you guys out there has this IP address, what is your Ethernet MAC address?".
您的 tcpdump 摘录表明此 ARP 解决方案失败。您的客人一遍又一遍地询问，却从未得到答案。只要是这种情况，来宾就无法与主机进行 any TCP/IP 通信。
所以您的问题不仅与 SCP/SSH 有关，而且与一般的 IP 协议有关。例如，来宾将无法显示位于主机上的网站。
此外，由于房东不想发送答案，任何其他客人都会遇到同样的问题。我强烈认为，如果您以完全相同的方式启动它的 VM，并且在具有与新 debian stretch.
当然，来自来宾的 ARP 请求首先到达连接来宾 VM 的 TAP 的 bridge。只要该网桥没有分配给客人请求的 IP 地址，客人的 ARP 请求就不会得到答复。这个问题通常通过以下方式解决：
在主机上，从物理网络接口中取出IP地址，并将其分配给网桥。然后网桥回答访客的 ARP 查询。但这还不能让你到任何地方，因为现在你不能再使用主机的物理网络接口（你已经拿走了它的 IP 地址）。
因此，您也将主机的物理网络接口连接到网桥。通常，这是一个静态配置，即它不是在启动 VM 时动态完成的。这意味着主机上的 OS 配置为创建网桥并在启动时将其物理网络接口添加到网桥。相反，来宾的 TAP 在来宾启动时动态添加到桥中，并在来宾关闭时从桥中删除。
动态添加和删除访客的 TAP 到主机的网桥通常是通过您为 -tap ... 配置选项提供的 upscript 和 downscript 参数完成的。显然，您正在手动执行此操作（更新 3 的第 3 项）。
总而言之，您的问题是房东没有回答房客的ARP询问。发生这种情况是因为这些查询到达了 VM 的 TAP 所连接的网桥，但您没有为该网桥分配 IP 地址（更准确地说，至少不是来宾的 ARP 查询要求的 IP 地址）。