首先，通过QEMU Virtual Machine (Debian Sparc64 Etch 4.0)，我已经能够成功地从来宾到主机(MacOS Hight Sierra OS 10.13.3)获取ssh和scp命令。
我只想在来宾和主机之间传输文件。
为了得到它，我遵循了本教程：
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)虚拟机启动后，在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"客人一起得到同样的东西。
似乎ifconfig在最新版本的 Debian 中被弃用了。
无论如何，我尝试使用以下命令启动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，所以我只想要ssh/scp的方向guest-->host)。
更新 1：
我一直在调试这个问题。
1)首先，从此链接中，我在每次启动时将来宾"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"
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在客人/etc/network/interfaces)和主人(192.168.10.1由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：我也尝试通过使用带有"-net tap"标志guestfwd标志来启动，如下所示：
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)在bridge0上设置IP190.168.10.1并带有"ifconfig bridge0 192.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 将以太网广播帧发送到本地以太网段(基本上，广播帧是连接到相应网段的所有机器的帧)，询问："我需要与具有 IP 地址b.b.b.b 的人交谈。如果你们中的任何人有这个IP地址，你的以太网MAC地址是什么？
您的tcpdump摘录显示此ARP解析失败。您的客人一遍又一遍地询问，但从未得到答案。只要是这种情况，客户机就无法与主机进行任何TCP/IP 通信。
因此，您的问题不仅与SCP/SSH有关，还与一般的IP协议有关。例如，来宾将无法显示位于主机上的网站。
此外，由于主人不想发送答案，任何其他客人都会遇到同样的问题。我强烈假设，如果你以完全相同的方式启动它的 VM，并且在与具有新 debianstretch的 VM 完全相同的配置完全相同的主机上启动它的 VM，那么您的旧 debianetch会以同样的方式失败。
当然，来自客户机的 ARP 请求首先会到达连接客户机虚拟机 TAP 的网桥。只要该网桥没有分配来宾请求的 IP 地址，就不会应答来宾的 ARP 请求。此问题通常通过以下方式解决：
在主机上，将 IP 地址从物理网络接口中取出，并将其分配给网桥。然后，网桥会回答来宾的 ARP 查询。但这还不能让你去任何地方，因为现在你不能再使用主机的物理网络接口了(你已经拿走了它的IP地址)。
因此，您也可以将主机的物理网络接口连接到网桥。通常，这是静态配置，即在启动 VM 时不会动态完成。这意味着主机上的操作系统配置为创建网桥，并在启动时将其物理网络接口添加到网桥。相反，来宾的 TAP 在启动来宾时动态添加到网桥中，并在关闭访客时从网桥中删除。
将来宾的 TAP 动态添加和删除到主机的网桥通常由您提供给-tap ...配置选项的upscript和downscript参数来完成。显然，您是手动执行此操作的(UPDATE 3的第3项)。
总而言之，您的问题是主人没有回答客人ARP的问题。发生这种情况是因为这些查询到达了虚拟机的 TAP 连接到的网桥，但你没有为该网桥分配 IP 地址(更准确地说，至少不是来宾的 ARP 查询请求的 IP 地址)。