QEMU SSH hostfwd example from manual doesn't work anymore

  • Done
  • quality assurance status badge
Details
2 participants
  • Eric Brown
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
M
M
Maxim Cournoyer wrote on 30 May 2021 08:36
(name . bug-guix)(address . bug-guix@gnu.org)
87zgwchgmv.fsf@gmail.com
Hi!

In the manual, we have an example to allow connecting to the VM via a
port forward from the host:

$(guix system vm config.scm) -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22

Unfortunately, I cannot get this to work anymore, using a very simple
operating system with following openssh-configuration:

Toggle snippet (7 lines)
(service openssh-service-type
(openssh-configuration
(permit-root-login #t)
(allow-empty-passwords? #t)
(log-level 'debug)))

I've used port 3333 as the childhurd VM is already using 10022 by
default, like so:

$ /gnu/store/qgaihb9i6n8m96m6prrcgywwxfjyqy99-run-vm.sh -nic user,hostfwd=tcp::3333-:22

And tried connecting with:

Toggle snippet (31 lines)
$ ssh -vvvvvv root@localhost -p3333
OpenSSH_8.6p1, OpenSSL 1.1.1j 16 Feb 2021
debug1: Reading configuration data /home/maxim/.ssh/config
debug2: checking match for 'localuser mcournoyer' host localhost originally localhost
debug3: /home/maxim/.ssh/config line 13: not matched 'localuser "maxim"'
debug2: match not found
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/maxim/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/maxim/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug2: resolving "localhost" port 3333
debug3: ssh_connect_direct: entering
debug1: Connecting to localhost [127.0.0.1] port 3333.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.
debug1: identity file /home/maxim/.ssh/id_rsa type 0
debug1: identity file /home/maxim/.ssh/id_rsa-cert type -1
debug1: identity file /home/maxim/.ssh/id_dsa type -1
debug1: identity file /home/maxim/.ssh/id_dsa-cert type -1
debug1: identity file /home/maxim/.ssh/id_ecdsa type -1
debug1: identity file /home/maxim/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/maxim/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/maxim/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/maxim/.ssh/id_ed25519 type -1
debug1: identity file /home/maxim/.ssh/id_ed25519-cert type -1
debug1: identity file /home/maxim/.ssh/id_ed25519_sk type -1
debug1: identity file /home/maxim/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/maxim/.ssh/id_xmss type -1
debug1: identity file /home/maxim/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.6

Inside the guest, /var/log/secure doesn't show any activity so it
doesn't seem to be reached.

Am I doing something wrong?

Maxim
E
E
Eric Brown wrote on 30 May 2021 23:43
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 48739@debbugs.gnu.org)
86bl8r7v8z.fsf@hurd.ericcbrown.com
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (16 lines)
> Hi!
>
> In the manual, we have an example to allow connecting to the VM via a
> port forward from the host:
>
> $(guix system vm config.scm) -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22
>
> Unfortunately, I cannot get this to work anymore, using a very simple
> operating system with following openssh-configuration:
>
> [...]
>
> Am I doing something wrong?
>
> Maxim

Hello Maxim,

Just today I ssh'd into childhurd with -p 10022 like the manual
suggests.

Also, I ssh'd into Debian GNU/Hurd in qemu with 5555 like the Hurd documentation
suggests. I ended up using (also to get Spice):

qemu-system-x86_64 -m 3072 -smp 1 -enable-kvm -nic \
user,model=rtl8139,hostfwd=tcp::5555-:22 -net user -boot menu=on,order=d \
-drive cache=writeback,file=hurd.img -device \
virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 \
-chardev spicevmc,name=vdagent,id=vdagent -device \
virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0

You may have a different issue, just want to give some feedback.

Best regards,
Eric
M
M
Maxim Cournoyer wrote on 31 May 2021 05:39
(name . Eric Brown)(address . ecbrown@ericcbrown.com)(address . 48739-done@debbugs.gnu.org)
87v96zh8qi.fsf@gmail.com
Hello Eric,

[...]

Toggle quote (20 lines)
> Hello Maxim,
>
> Just today I ssh'd into childhurd with -p 10022 like the manual
> suggests.
>
> Also, I ssh'd into Debian GNU/Hurd in qemu with 5555 like the Hurd documentation
> suggests. I ended up using (also to get Spice):
>
> qemu-system-x86_64 -m 3072 -smp 1 -enable-kvm -nic \
> user,model=rtl8139,hostfwd=tcp::5555-:22 -net user -boot menu=on,order=d \
> -drive cache=writeback,file=hurd.img -device \
> virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 \
> -chardev spicevmc,name=vdagent,id=vdagent -device \
> virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0
>
> You may have a different issue, just want to give some feedback.
>
> Best regards,
> Eric

Thanks a lot for sharing this; I tried your above snippet with the
Debian Hurd img file, and it worked! Out of curiosity, how do you use
Spice with the above? It'd need a Spice-enabled viewer such as
virt-manager right? How do you point virt-manager to the VM instance
spawned with QEMU?

So it's not a QEMU bug. I'm also
running a childhurd VM and it indeed works there. The command the
childhurd service uses is:

Toggle snippet (3 lines)
qemu-system-i386 -m 512 --device rtl8139,netdev=net0 --netdev user,id=net0,hostfwd=tcp:127.0.0.1:11004-:1004,hostfwd=tcp:127.0.0.1:10022-:2222,hostfwd=tcp:127.0.0.1:15900-:5900 --snapshot --hda /gnu/store/84881fwqhwl37n7gbh8lhg3i01sxrp2p-disk-image --no-reboot --enable-kvm

Stealing its --device and --netdev options applied to my case:

Toggle snippet (3 lines)
/gnu/store/kkwyzm7b6mg42sm5cljlqrca9f5hqmyn-run-vm.sh --device rtl8139,netdev=net0 --netdev user,id=net0,hostfwd=tcp:127.0.0.1:3333-:22

And try to connect to SSH, I can see messages like:

Toggle snippet (3 lines)
qemu-system-x86_64: Slirp: Failed to send packet, ret: -1

So at this point I'm guessing my minimal OS declaration is too minimal
and missing a networking component. It's this:

Toggle snippet (13 lines)
(use-modules (gnu services ssh)
(gnu system)
(gnu tests))

(simple-operating-system
(service openssh-service-type
(openssh-configuration
(permit-root-login #t)
(allow-empty-passwords? #t)
(log-level 'debug))))


Adding the DHCP client service like so:

Toggle snippet (14 lines)
(use-modules (gnu services networking)
(gnu services ssh)
(gnu system)
(gnu tests))

(simple-operating-system
(service dhcp-client-service-type)
(service openssh-service-type
(openssh-configuration
(permit-root-login #t)
(allow-empty-passwords? #t)
(log-level 'debug))))

I've added a note to document this and spare others the trouble of going
down this hole with commit b9ac7d9aaaa5849cc3c2acd4b1b41acdd545e66b.

Thanks a lot for helping me see the solution!

Closing.

Maxim
Closed
E
E
Eric Brown wrote on 7 Jun 2021 04:06
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 48739-done@debbugs.gnu.org)
87sg1ul97u.fsf@ericcbrown.com
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (7 lines)
>
> Thanks a lot for sharing this; I tried your above snippet with the
> Debian Hurd img file, and it worked! Out of curiosity, how do you use
> Spice with the above? It'd need a Spice-enabled viewer such as
> virt-manager right? How do you point virt-manager to the VM instance
> spawned with QEMU?

Normally I just ssh -Y into Debian GNU/Hurd, but it also has GNOME. I
just thought spice was a "better console."

Actually don't use virt-manager -- I just call qemu in a terminal
multiplexer. (sometimes with -nographic)

Toggle quote (3 lines)
> Thanks a lot for helping me see the solution!
>

My pleasure, I think the student has surpassed the teacher ;-)
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 48739@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 48739
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch