Allow remote access

Secure the operating system

It is now presumed that initial user account changes have been performed. (If not, take care of that.)

Before opening up a new doorway into the system, take some time to check out the network connections to see what doorways into the system already exist. See: checking the network ports.

If there are no “Active Internet connections” that seem to be a threat, such as a TCP connection that seems to be listening to traffic, then supplying network access/connectivity is probably a relatively safe thing to do at this point.

Handling networking
Handle virtual machine network configuration

The default method of networking may have some limitations. For example, Qemu's default is to use a method of networking that uses NAT and SLiRP code, which supports only TCP/IPv4 connections and UDP/IPv4 communications, but not other protocols like ICMP/IPv4, nor anything using IPv6.

The good news is that this may not be a problem that needs any time to take care of. If this entire “multi-server project” guide has been getting completed in order, then enabling the full networking may be something that has already been taken care of.

However, if the full networking hasn't been enabled yet, now may be about as good of a time as any. (Or, one could decide to just delay this task until working on another virtual machine, and just leave this machine permanently crippled. If this guide is being used as part of a structured/formal training session like a class, make sure to follow any instructions that are part of that training. Otherwise, you may just wish to make your own decision on whether this machine should have full networking capabilities.)

See: virtual machine's networking. If that is a portion of the guide that has already been done, then skip it.

Setting an IP address

An IP address needs to be set. If an IP address isn't set yet, here are some quick pointers/instructions.

On the virtual machine, make sure the desired IP address is set. Doing this will require knowing the name of the NIC (see: available NICs).

  • If communication with the physical machine is enabled, and if the physical machine is listening for DHCP/IPv4 traffic, then use:
    sudo dhclient nicname

    e.g.:

    sudo dhclient em0
    (network addressing)
  • sudo ifconfig nicname 192.0.2.2 netmask 255.255.255.0

    (manually setting current network address)

Using SSH
Connecting to neighbor

Attempt to verify IP connectivity. This is not absolutely required, and may suggest some misleading indicators if firewall traffic is blocking various types of communication. However, if traffic is generally permitted, this might reveal some other types of problems, such as if a device is not currently configured with the IP address.

First, figure out the address of another device. (This may be another device on the same network. For example, if this is a virtual machine, then using the IP address of the physical machine will probably work just fine.) Then, verify IP connectivity is working as expected. (A simple ping command will often be sufficient.)

If expected connectivity is not working, then there may be some worth in checking out why that connectivity is not functionling.

First, back up what is going to be changed. This doesn't need to be a fancy off-site, off-device backup (which might be easier to create after the Internet access is fully working well), but any sort of simple backup is recommended.

The following shows creating a quick backup, and starting to edit the correct file, with OpenSSH.

sudo cp -pi /etc/ssh/sshd_config /etc/ssh/sshdcfg.old
ls -l /etc/ssh/
Troubles

Just be a little careful to specify the correct file; there is also a similary-named /etc/ssh/ssh_config file which is NOT the right file. That would be the file designed for the OpenSSH SSH client, but the file that needs to be backed up (and then changed here) is the file for the SSH server.

Note that people using “Portable OpenSSH” might have files placed in other locations (like right in /etc/, instead of /etc/ssh/), so users of that software may need to explore to determine where these files are. (This may be doable by reading documentation, or simply searching the filesystem.) The following may be helpful for finding the configuration file:

sudo find /etc/ -iname "*sshd*"

Enable support for groups. Keep in mind that these example commands are meant for OpenSSH, and users of “Portable OpenSSH” may need to adjust these command lines to use the right file.

[#osshgprq]: Requiring groups
echo AllowGroups _sshok| sudo -n tee -a /etc/ssh/sshd_config

Understand that, even though the statement looks rather permissive (since the statement starts with the word “Allow”), this is really rather exclusionary. This will disable connections by anybody who is not in the specified group(s). The correct order to do things may be to place someone into a group that is allowed, and to do that before implementing the change in this text file.

If there is a desire to use a custom TCP port number, then that may also be specified in this configuration file.

Example of custom TCP port number

The following just specifies what is normally the default, so this example is useless unless customized.

echo Port 22| sudo -n tee -a /etc/ssh/sshd_config

Now, presumably the users have been created, and the SSH server configuration has been specified, and the IP addresses have been set.

The following test should report zero (“0”).

sudo sshd -t
echo ${?}

(Don't bother trying as non-root. Well, there's no harm, but the results are predictable: sshd will notice that some “key” files should exist, but will be unable to access them.)

Note that having the server reload its configuration might/is-believed-to not necessarily affect any existing SSH connections. However, the options will affect new SSH connections. In a recent case there were two SSH servers (processes) running. (Perhaps the new copy noticed the different TCP port, and simply started up as an additional copy?) To eliminate ambiguity which could easily result in confusion, stop any existing SSH server.

sudo kill $( cat /var/run/sshd.pid )
ps -auxww | grep -i sshd | grep -v grep
echo ${?} # result of 1 is desired unless you are actively using SSH

(Note: The above line will work with systems using OpenSSH. For systems using “Portable OpenSSH”, the ps command's parameter of -auxww may need adjustment. See: ps command implementation differences. If additional software needs to be stopped, see adjusting running software.)

Now, go ahead start the server if it's not running yet...

sudo $( which sshd )

And, make sure the server is using the new configuration.

sudo kill -HUP $( cat /var/run/sshd.pid )

(Contrary to what the name of the program seems to imply, the kill command does not function by terminating a program. The kill command is really just a signal deliverer, and the default signal is the “SIGKILL” signal. In this case, we're sending the “hangup” signal, also known as “SIGHUP”. That signal was originally meant to have something to do with disconnecting a communications connection (particularly when referring to a connection over a dial-up telephone line, using landline POTS), but modern software often treats that signal as a request to re-perform some of the program's startup processes, including applying software configuration. Different programs can vary in how they respond to that signal, but reloading the configuration file is the effect that OpenSSH has to that signal.)

Know the system address

If DNS is not set up yet, then know the IP address of the system to connect to.

Proper key verification

Once the server is fully operational, properly preform the key verification. First, on the virtual machine, run:

for x in /etc/ssh/ssh_host_*key.pub ; do echo $x : ; ssh-keygen -lf $x ; done

Then, on the (physical) system that is running the virtual machine software, connect to the virtual machine with a command such as:

ssh -p 22 -o VisualHostKey=yes -l loginName virtMach.example.zz
  • (Customize the system name, which is the part after the “=yes ”, as necessary.)
    • If DNS is not set up yet, then an IP address may be needed.

Then, verify that the key matches, as noted by: verifying SSH keys.

If the network address cannot be found

Make sure you are specifying the remote system.

If you are trying to connect to an IPv6 link-local address (which means it is part of fe80::/16, which will mean it starts with “fe80:”), then you'll need to specify the local NIC identifier. The NIC identifier to specify is based on the local system, while the address to connect to will be the remote system's address. e.g.,

ssh -p 22 -o VisualHostKey=yes fe80::2%tun0

The interface identifiers are mentioned in a couple of places at availble NICs.

Typically, it may be easier to simply connect to a different network address (such as an IPv6 ULA, which is in fd00::/8, meaning it starts with “fd”)). That way, you don't need to figure out the NIC identifier on one system, and be careful to specify the IPv6 link-local address used by the other system.

If the SSH server doesn't respond

First of all, know that the only system that should be used to run the SSH client, at this time, is the machine with the TUN/TAP device (which is the “physical” machine that is running the “virtual machine” software). The reason for this is because there are now multiple subnets, which may require some routing to be set up, and that routing may not be set up yet. (After routing gets set up, an SSH session will be able to be created from a client running on another machine. However, the full networking scenario isn't that “well developed”, quite yet.

If IPv6 isn't working, give IPv4 a try. (And if you only tried IPv4, then give IPv6 a try.) Know that using an IPv6 link-local address (which starts with “fe80:”) may be more challenging If just one of those is working, that helps to narrow down some of the likely causes.

Other possible causes could include the SSH server not running, or a network interface lacking a necessary setting. Check that the IP addresses are what is expected.

If you cannot log in

If you're connecting, but it isn't responding:

Check the authorization logs
Checking authorization logs in OpenBSD
sudo tail /var/log/authlog
If user isn't in AllowGroups

Add the user.

grep -i AllowGroup /etc/ssh/sshd_config

Here are some resources that are not part of this guide. (Once the issue is fixed, this guide recommends returning back to this guide.)

e.g. from OpenBSD:

$ user info username | grep groups
groups  username wheel
$ usermod -G username,wheel,_sshok username
usermod: Program must be run as root
echo ${?}
1
$ sudo usermod -G username,wheel,_sshok username
echo ${?}
0
$ user info username | grep groups
If there is no record of the connection

Make sure you're connecting to the right system. Double-check the IP address on the command line. Also double-check the IP address on the TUN/TAP interface. (If it has the IP address that should belong to the virtual machine, then the virtual machine doesn't get a copy of the traffic.)

If you're using the IPv6 link-local address (which starts with fe80:), the NIC may need to be specified. e.g.:

ssh -p 22 -o VisualHostKey=yes -l loginName fe80::8642%tun144

Note: for those who may be using virtual machines, successfully logging into the SSH server probably means that there will be no further need for the local console; if administration has been done by using a remote access method (such as a VNC server built into the software), then that method might not be necessary any longer. Even still, it might be a bit early to be closing an existing VNC connection (and spending effort closing the VNC server, which may generally be a good thing to do as a way to increase security by reducing the number of potential doorways into the system). An alternate way to interact with the machine, such as using VNC, may be useful if networking becomes broken. Since further steps may involve changes to how network traffic is enabled, such as making adjustments to the configuration of firewall software, the potential for problems still seems pretty high (compared to a more “normal” state where a network has been very functional for a while). So, keep those VNC sessions open, for now, if it is convenient to do so. If some sort of networking issue happens, such as IP addresses not being assigned as expected after a reboot, the “local display” (visible by using an VNC session) may still be a useful tool.

Prepare for more “copy and paste”

This guide may have made some efforts to keep command lines relatively short. One reason for this is that many people type slower than 100 words per minute. However, commands found in later parts of this guide may be less prone to be quite as short.

If you haven't yet gotten into the habit, try to SSH to the “physical” machine that is running the “virtual machine” software, and then use an SSH client on that machine to connect to the SSH server on the “virtual machine”. Doing so will probably allow you to use “copy and paste” on commands, which will make many of the upcoming processes go quicker and easier. There may also be less likelihood of typos. However, whenever using “copy and paste”, be sure to check for anything that needs to be customized. (This guide will often show text that needs customization with a certain font style, as discussed by the key/legend.)