Using a default address


These instructions were made for a version of the tutorial which did not yet try to implement automatic assignment of IPv6 addresses (using something like SLAAC and/or DHCPv6). There were IPv6 “link-local” addresses, but no other IPv6 address assigned through any kind of “dynamic” process.

The preparing the first system for children process had instructions: “Recommended: Make it an address that is reserved for new systems. This way, new systems can be remotely accessed relatively easy.”

Check “known hosts”

Determine what IPv6 address is used by the default network configuration of each child. (If this address is not documented well, yet, then figure out that address. That might involve logging into the system, at which point there might be no additional convenience to trying to use that address for this system. In that case, there may be a need to just hold off, until the next time a new system is created. However, do document the default address this time around, so the next system can be simpler.)

grep -i 2001:db8:1::1 ~/.ssh/known_hosts

If it exists, remove it:

cpytobak ~/.ssh/known_hosts
echo ${VISUAL}
${VISUAL} ~/.ssh/known_hosts

Go ahead and make an SSH connection.

ssh -p 22 -i privKey -l loginName 2001:db8:1::1

(The following example shows a reference to “-i privKey”. That only applies if the child image has a public key pre-installed. Actually, that means that the parent image has the same public key pre-installed, and that's not necessarily a recommended setup. So, that parameter might not be applicable. It is an optional parameter, so just leave it off if it doesn't apply.)

Bad security practice

Actually, if the best SSH-handling recommendations are to be strictly followed, authentication information should not be sent over the SSH connection until the SSH key, or at least some sort of SSH fingerprint (perhaps an SHA256 hash, or a “Visual Host Key”), is verified. (The proper verification process is documented at verifying the SSH fingerprint, which could be done by using Qemu's internal VNC.)

In practice, this is one case where this guide suggests not worrying about that too much if the network connectivity is being performed on a network which is considered to be fully secure. For instance, if the “firewall” virtual machine is connecting to this system, there's very little opportunity for an attacker to perform a network-based attack (as long as the “physical”/“host” system is successfully secured). However, using SSH from other machines may introduce more routing hops, and introduce more possible locations that attackers may find useful.

Place documentation in a template

If having this re-usable address is convenient, then it may be worthwhile to document the address in the “template” that gets copied whenever new machines get made. Then, whenever that template gets copied, this information can be conveniently available, right next to other details like the username and password.

Documenting the re-usable IPv6 address may be less valuable after DNS is operational, because an “easy-to-use” DNS name could point to the IPv6 address. (Even then, the DNS name ought to be documented, but that documentation may offer a bit less benefit when the address is easily memorized.)