0

I am trying to build a custom Ubuntu (ISO built from bionic - 18.04.2) qcow2 image via packer. This fails in the step where packer tries to SSH to the instance via port forward. I can see from VNC that the instance spins up fine, and I can login with the given ID manually on the console, but packer is unable to ssh.

I tried to ssh, ssh form host gets stuck for a long time and errors out:

ssh -vvv -p 2226 admin@127.0.0.1
debug1: identity file /home/ani/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4

Though the port is up:

$ sudo lsof -i:2226
COMMAND     PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
qemu-syst 31185 root   14u  IPv4 50059412      0t0  TCP *:2226 (LISTEN)

SSH server is running in the instance, and the user is a valid one. What else do I need to check to ensure SSH can happen via the host ? On the same host, I am able to make Ubuntu Trusty (14.04) qcow2. So, I am not sure if some additional qemu command line arguments need to be passed (for port forwarding to work correctly) Or some sshd configs need to be changed on Ubuntu bionic (18.04)!

This is the qemu command line:

/usr/bin/qemu-system-x86_64 -cpu host -smp 4 -m 8192M -boot once=d -name ubuntu-bionic-custom-0.1.qcow2 -drive file=output/ubuntu-bionic-custom-0.1.qcow2,if=virtio,cache=writeback,discard=ignore,format=qcow2 -serial file:serial.out -device e1000,netdev=user.0 -machine type=pc,accel=kvm -netdev user,id=user.0,hostfwd=tcp::2226-:22 -cdrom /home/ani/ubuntu-bionic-custom-0.1.iso -vnc 127.0.0.1:83

version:

$ /usr/bin/qemu-system-x86_64 --version 
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.4)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

--EDIT--

$ route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.192.0.1      0.0.0.0         UG    0      0        0 br0
10.0.3.0        0.0.0.0         255.255.255.0   U     0      0        0 lxcbr0
10.192.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

$ ip netns ls 
$
Ani
  • 32
  • 12
  • is the vm connecting to a bridge or virtual switch? – Sum1sAdmin Mar 03 '20 at 10:11
  • @Sum1sAdmin How do I find that out!? I am using `packer` and I am using similar configurations which used to work for `ubuntu trusty (14.04)` – Ani Mar 03 '20 at 16:38
  • Have you checked iptables/ufw rules in the vm? – hardillb Mar 04 '20 at 07:41
  • @hardillb I tried with `sudo ufw disable` and still same! – Ani Mar 04 '20 at 08:46
  • Do you see anything wrong in the arguments that packer is passing qemu ? or can I change something and try ? this does not seem to be the SSH (in guest) issue. – Ani Mar 04 '20 at 08:46
  • can you update the question with the output of `route -n` and `ip netns ls` – Sum1sAdmin Mar 04 '20 at 12:49
  • @Sum1sAdmin added the command outputs – Ani Mar 04 '20 at 16:57
  • so your network interfaces are bridged, you have 3 different ones, I have never used packer, but I would try to get the actual IP address of the VM by using bridge control commands [link][https://linux.die.net/man/8/brctl] and try using the `ssh -g` flag for port forwarding – Sum1sAdmin Mar 05 '20 at 09:19
  • @Sum1sAdmin ok, that would be a manual thing, I want to automate the process of creating `qcow2` from ISO using `packer`, so `packer` should be configured to send the right arguments to `qemu` - I don't know what I am missing here! – Ani Mar 06 '20 at 02:51
  • yes, it is an automation tool, but you have some underlying network issue probably related to the number of bridged interfaces you have a NAT'd bridge with DHCP `virbr0` you have a VM to VM only bridge `br0` and you have a bridge for containers `lxbr0` you are doing ssh >> localhost >> port forward >> VM - this should work fine so long as your actual host network can reach the network your VM is on - try getting the real IP address from the VNC session and see can you ping it, you have a low level networking issue – Sum1sAdmin Mar 06 '20 at 10:12
  • ok, let me check that – Ani Mar 06 '20 at 10:21

1 Answers1

0

This happened to be an issue with the bionic ISO image that I was using. I had changed it to use traditional networking (also falling back to older iface naming scheme), instead of NetPlan. But with that, I had to add an entry in /etc/network/interfaces for eth0

Ani
  • 32
  • 12