--- Begin Message ---
|
Subject: |
QEMU SSH hostfwd example from manual doesn't work anymore |
|
Date: |
Sun, 30 May 2021 02:36:56 -0400 |
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:
--8<---------------cut here---------------start------------->8---
(service openssh-service-type
(openssh-configuration
(permit-root-login #t)
(allow-empty-passwords? #t)
(log-level 'debug)))
--8<---------------cut here---------------end--------------->8---
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:
--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#48739: QEMU SSH hostfwd example from manual doesn't work anymore |
|
Date: |
Sun, 30 May 2021 23:39:49 -0400 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hello Eric,
[...]
> 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:
--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---
Stealing its --device and --netdev options applied to my case:
--8<---------------cut here---------------start------------->8---
/gnu/store/kkwyzm7b6mg42sm5cljlqrca9f5hqmyn-run-vm.sh --device
rtl8139,netdev=net0 --netdev user,id=net0,hostfwd=tcp:127.0.0.1:3333-:22
--8<---------------cut here---------------end--------------->8---
And try to connect to SSH, I can see messages like:
--8<---------------cut here---------------start------------->8---
qemu-system-x86_64: Slirp: Failed to send packet, ret: -1
--8<---------------cut here---------------end--------------->8---
So at this point I'm guessing my minimal OS declaration is too minimal
and missing a networking component. It's this:
--8<---------------cut here---------------start------------->8---
(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))))
--8<---------------cut here---------------end--------------->8---
Adding the DHCP client service like so:
--8<---------------cut here---------------start------------->8---
(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))))
--8<---------------cut here---------------end--------------->8---
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
--- End Message ---