Unable to ssh in the QEMU VM

[Xylopyrographer]

Hello:

Working through MELP, 3rd Ed.

In Chapter 7, page 218, after building and confirming the QEMU VM runs (using runqemu qemuarm64 nographic), I try to ssh into it by opening a new Terminal tab and enter ssh root@192.168.7.2.

The connection attempt eventually fails on a time out.

Similarly down on page 219 at step 7, running devtool deploy-target bubblewrap root@192.168.7.2 also fails with a connection time out.

Everything seems to be up and running as it should on the QEMU VM. Starting it and running through the startup console dump gives:

runqemu - INFO - If this is not intended, touch /tmp/qemu-tap-locks/tap0.skip to make runqemu skip tap0.
runqemu - INFO - Network configuration: ip=192.168.7.2::192.168.7.1:255.255.255.0::eth0:off:8.8.8.8 net.ifnames=0
runqemu - INFO - Running /home/resu/build-mine/tmp/work/x86_64-linux/qemu-helper-native/1.0/recipe-sysroot-native/usr/bin/qemu-system-aarch64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -drive id=disk0,file=/home/resu/build-mine/tmp/deploy/images/qemuarm64/core-image-full-cmdline-qemuarm64.rootfs-20240307222257.ext4,if=none,format=raw -device virtio-blk-pci,drive=disk0 -device qemu-xhci -device usb-tablet -device usb-kbd  -machine virt -cpu cortex-a57 -smp 4 -m 256 -serial mon:stdio -serial null -nographic -device virtio-gpu-pci -kernel /home/resu/build-mine/tmp/deploy/images/qemuarm64/Image -append 'root=/dev/vda rw  mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0::eth0:off:8.8.8.8 net.ifnames=0 console=ttyAMA0 console=hvc0 swiotlb=0 '

Linux version 6.5.13-yocto-standard (oe-user@oe-host) (aarch64-poky-linux-gcc (GCC) 13.2.0, GNU ld (GNU Binutils) 2.41.0.20231213) #1 SMP PREEMPT Thu Dec 14 16:41:39 UTC 2023

Kernel command line: root=/dev/vda rw  mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0::eth0:off:8.8.8.8 net.ifnames=0 console=ttyAMA0 console=hvc0 swiotlb=0 

IP-Config: Complete:
     device=eth0, hwaddr=52:54:00:12:34:02, ipaddr=192.168.7.2, mask=255.255.255.0, gw=192.168.7.1
     host=192.168.7.2, domain=, nis-domain=(none)
     bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
     nameserver0=8.8.8.8

INIT: Entering runlevel: 5
Configuring network interfaces... RTNETLINK answers: File exists
Starting OpenBSD Secure Shell server: sshd
done.

Running the ssh connect from the non-QEMU VM Terminal tab in verbose mode gives:

% ssh -vvv root@192.168.7.2
OpenSSH_9.2p1 Debian-2+deb12u2, OpenSSL 3.0.11 19 Sep 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.7.2 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/resu/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/resu/.ssh/known_hosts2'
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.7.2 [192.168.7.2] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: connect to address 192.168.7.2 port 22: Connection timed out
ssh: connect to host 192.168.7.2 port 22: Connection timed out

Other commands executed from within the QEMU VM also seem to indicate that things are OK on the VM. Examples:

root@qemuarm64:~# ps aux | grep sshd
root       266  0.0  1.6   8544  3752 ?        Ss   21:30   0:00 sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups
root       378 30.0  0.5   2948  1280 ttyAMA0  S+   23:21   0:00 grep sshd

and

root@qemuarm64:~# netstat -plntu | grep ssh
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      266/sshd: /usr/sbin 
tcp6       0      0 :::22                   :::*                    LISTEN      266/sshd: /usr/sbin 

As well, I can telnet in to the VM itself by running (from within the VM): telnet localhost 22 which returns:

Connected to localhost
SSH-2.0-OpenSSH_9.5

So I think all is as it should be on the QEMU side of things?

FWIW, cannot seem to get to the Internet from the QUEM VM. Example, pinging 4.4.4.4 returns Destination Host Unreachable.

Just need the magic keystrokes or config info to get in from outside the VM.

Any hints?

Thanks.

[fvasquez]

I remember these devtool exercises working for me back when I created them. I think I experienced some hiccups initially with QEMU's default TAP networking but nothing I wasn't able to quickly sort out.

Can you ping 192.168.1.72 from your host machine? If you can't then SSH won't work either.

I don't think the QEMU VM needs internet access to execute the devtool exercises. It only needs to communicate with your host machine.

I think the QEMU VM key can go stale when the VM exits. That's why I regenerate the key on page 221 like so:

$ ssh-keygen -f "/home/frank/.ssh/known_hosts" -R "192.168.7.2"

Replace frank with your username in the path above and try connecting again.

I noticed your QEMU VM is running a bleeding edge Linux kernel.

Linux version 6.5.13-yocto-standard (oe-user@oe-host) (aarch64-poky-linux-gcc (GCC) 13.2.0, GNU ld (GNU Binutils) 2.41.0.20231213) #1 SMP PREEMPT Thu Dec 14 16:41:39 UTC 2023

I tested these devtool exercises against Yocto 3.1 (Dunfell) LTS. Although it's unlikely, devtool may have regressed in more recent versions of Yocto. I advise that you use an LTS release of Yocto like 4.0 (Kirkstone) to ensure continued maintenance.

[Xylopyrographer]

Thanks again for the reply.

I can try rebuilding the VM with Yocto Kirkstone. Though interestingly, when regenerating the ssh key, the response is:

Host 192.168.7.2 not found in /home/resu/.ssh/known_hosts

Guess I'll figure out what that means first...

BTW, I am enjoying the book. 👍

[Xylopyrographer]

To close the loop:

Did get this working.

Problem was a whacked out firewall configuration on the Debian machine.

Between firewalld, the Firewall GUI app and nfstables things got out of sync.

Finally figured out how to disable all that and Bob's yer uncle we're good to go.

Haven't revisited how to reset all the firewall configuration. Bigger fish to fry at the moment.

Thanks for the replies.