SSH setup for Qemulated Pi

[rasbeer]

I'm trying to set up SSH on a Qemulated Pi (having just been allowed to order a solid Pi today ).

The Qemulated Pi is getting IP address 10.0.2.15:


So I (naively?) thought I could just setup as per existing instructions:
http://fusionstrike.com/2012/setting-ss ... -pi-debian

However, even this didn't work:

Code: Select all

# sudo mv /boot/boot_enable_ssh.rc /boot/boot.rc

/boot is empty.

So I tried:

Code: Select all

sudo update-rc.d ssh defaults

suggested here.

This appeared to fail with

Code: Select all

ssh stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (none)

Needless to say SSH failed:

Code: Select all

rasbeer@laptop:/$ ssh pi@10.0.2.15
ssh: connect to host 10.0.2.15 port 22: No route to host

Are there complications where a Qemulated Pi is involved?

(Or will I find myself unable to SSH into the real one in a couple of months? )

[AndrewS]

Are there complications where a Qemulated Pi is involved?

Yes. It's not something I've looked into myself, but there are all sorts of problems with emulated network interfaces.

[/quote](Or will I find myself unable to SSH into the real one in a couple of months? )[/quote]
Rest assured that on real hardware it'll work fine

[DuncanKennedy]

One of the things I've had problems with when trying to remotely access a QPi (Qemu Pi) is that a lot of the methods I've seen discussed here will give you an IP that can access the Internet, but can't be reached from anywhere else, even on the host machine. Double check with ping or tracrte that you can actually contact your Pi from the host. Once you've verified that you can continue debugging your setup.

[rasbeer]

Thanks guys - I tried some pinging - from the host computer to the QemuPi's IP (which always seems to be 10.0.2.15):

Code: Select all

--- 10.0.2.15 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1006ms
pipe 2

- from the QemuPi, immediately after booting in:

Code: Select all

$ ping -c 2 google.com
PING google.com (74.125.230.128) 56(84) bytes of data.
---google.com ping statistics ---
2 packets transmitted, 0 received, 100% packed loss, time 1017ms

A further confusion for me here is how it resolved the google domain name into the IP, without apparent access to a DNS. But I don't really understand this stuff, and I'm now fairly resigned to the idea that SSH into QemulatedPi is beyond my ken...

If I can get the real thing working with SSH & eventually remmina or similar I'll be happy.

[AndrewS]

Yup, remmina is available on the Pi http://packages.debian.org/squeeze/remmina

[jojopi]

A further confusion for me here is how it resolved the google domain name into the IP, without apparent access to a DNS.

The virtual 10.0.2.x network includes a virtual DHCP server at 10.0.2.2 and a virtual DNS server at 10.0.2.3.

Anyway, you said in a previous thread that you were using "-redir tcp:2222::22" among your qemu options. That tells qemu to listen on port 2222 on the host and forward to port 22 on the guest. So to ssh from the host to the guest: "ssh -p2222 pi@localhost".

[rasbeer]

Anyway, you said in a previous thread that you were using "-redir tcp:2222::22" among your qemu options. That tells qemu to listen on port 2222 on the host and forward to port 22 on the guest. So to ssh from the host to the guest: "ssh -p2222 pi@localhost".

Sheesh - scary memory you've got there jojopi! I only included that -redir option because it was in the Qemu setup how-to I followed...

And ssh -p2222 pi@localhost worked a treat!
a) Thanks very much! I can now try out some things without having to deal with the Qemulated screen (which can be a bit awkward) and
b) That REALLY should go in the wiki somewhere

[rasbeer]

Yup, remmina is available on the Pi http://packages.debian.org/squeeze/remmina

Ta - that might be my next 'project' when I've broken a few systems over SSH

(BTW, is the Abbot's Ale still flowing in the good hostelries of your fair city?)

[Joe Schmoe]

Note that what's really going on in this thread is the difference between setting up a private network vs. "bridging" to the outside (next up enclosing) network. Generally, when setting up virtual machines (regardless of which emulator software you are using), you have a choice between setting up the virtual machine on its own private network vs. bridging out to (usually) your home LAN. In the former case, you (usually) end up with an IP address like 10.x.y.z; in the later, you (usually) end up with an IP address like 192.168.x.y.

The basic difference is that with a private network, you can go out, but they can't come in. That's how your home LAN is setup - so that you can go out to the Internet, but they (the bad guys) can't come in. So, in this instance, when you tell QEMU to setup a 10.x.y.z network, you are setting up a network that, without special "hacks" (e.g., the "-redir" command line option), you can't get into it in from outside.

The easiest (though, perhaps not best) solution is to do whatever is needed to setup the QEMU emulated machine with a "bridged" network - which should get it on IP address in the 192.168.x.y range, and will be directly accessible from the other machines on your LAN.

[rasbeer]

Note that what's really going on in this thread is the difference between setting up a private network vs. "bridging" to the outside (next up enclosing) network. Generally, when setting up virtual machines (regardless of which emulator software you are using), you have a choice between setting up the virtual machine on its own private network vs. bridging out to (usually) your home LAN. In the former case, you (usually) end up with an IP address like 10.x.y.z; in the later, you (usually) end up with an IP address like 192.168.x.y.

The basic difference is that with a private network, you can go out, but they can't come in. That's how your home LAN is setup - so that you can go out to the Internet, but they (the bad guys) can't come in. So, in this instance, when you tell QEMU to setup a 10.x.y.z network, you are setting up a network that, without special "hacks" (e.g., the "-redir" command line option), you can't get into it in from outside.

Thanks Joe - I was wondering about that 10.x.y.z IP. It sounds like Qemu defaults to the private network option?

Are IPs starting with 10 reserved for private networks? (Otherwise wouldn't they clash with external addresses beginning with 10?)

EDIT: for anyone as unfamiliar with SSH as me, this seems like a pretty good summary. (That said the login command is a bit different. )

[AndrewS]

Thanks Joe - I was wondering about that 10.x.y.z IP. It sounds like Qemu defaults to the private network option?
Are IPs starting with 10 reserved for private networks? (Otherwise wouldn't they clash with external addresses beginning with 10?)

https://en.wikipedia.org/wiki/Private_network
The general convention tends to be that home LANs are on 192.168.x.y (where 9 times out of 10, x is either 0 or 1), which is why Qemu defaults to 10.x.y.z - but if your home LAN is already 10.x.y.z then yes this would conflict with the Qemu network, so you'd need to read the Qemu docs to see if it's private network addresses can be changed. (or you could fiddle the netmasks so e.g. Qemu is 10.0.x.y and the rest of your LAN is 10.5.x.y)

[Joe Schmoe]

FWIW, I'm not sure exactly what the "default" setup for QEMU is. I haven't played with QEMU (i.e., studied its documentation) enough to really say. I know that with VMWare, when you use the "wizard" to setup a new virtual machine, it explains the options for the kind of networking you want the new virtual machine to have, and has you make the choice before continuing.

When I setup QEMU to emulate the Pi, under Windows, I followed some posted instructions, that basically followed this line:

1) Install "openvpn" (under Windows) - this gives you a "TAP" device.
2) In Windows (using the network control panel), "bridge" the TAP device to (usually) your ethernet device (where the ethernet device is hooked up to your home LAN).
3) On the QEMU command line, do: -net nic -net if=TAP
(or something close to that - I don't have it in front of me at the moment)
4) Boot up the virtual machine.

The result of all this is that the emulated Pi's "eth0" device is "bridged" onto your home LAN - and gets a 192.168.x.y IP address (just like the other boxes on your home LAN) - and thus has full access to both your LAN and the Internet. And, of course, the other boxes have access to the Pi.