Step 1 – Checking for network cards and status of network
Things you typically know:
Network card’s device name used to be – eth0, eth1
Now it’s enp0s3 (at least in VirtualBox VM)
Why the NIC devices are now called enpxsn
en –> stands for ethernet
px –> stands for bus number x
sn –> stands for slot number n
For example, enp0s3 would be the ethernet card in slot 3 on bus 0
If you don’t know the network cards name, many different commands and ways to find it. The most direct is:
lshw -class network
https://www.cyberciti.biz/faq/linux-list-network-cards-command/
Other commands that show the network interfaces plus other info. We’ll use these to check the status of the network connection on each card:
ifconfig -a (old, probably don’t to use as it’s being replaced by ip)
ip a
ip -br -c addr show
nmcli -p dev
Just in case you’re interested, the data file for the network configuration for each NIC is stored in the directory:
/etc/sysconfig/network-scripts
Each interface will have a file named: ifcfg-interfaceName e.g. ifcfg-enp0s3
https://www.techrepublic.com/article/how-to-configure-a-static-ip-address-in-centos-7/
If network status isn’t enabled and running, then go back and watch videos on how to enable it.
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Step 2 – Installing and enabling ssh
Installing ssh package and allowing packets through the firewall. (Going to use systemctl and firewall-cmd commands, which you will learn all about later.) Note ssh software packages are included on CentOS by default, and already enabled and allowed through firewall. Really nothing to do here but check status.
If not installed
yum install openssh
or
yum install openssh openssh-server openssh-clients
Checking status of sshd or ssh network service:
systemctl status sshd
Starting sshd or network service, and ensuring it will start automatically when system is booted:
systemctl start sshd
systemctl enable sshd
Checking if allowed through firewall:
firewall-cmd --list-services
If necessary, add rule to allow ssh (port 22) through the firewall configuration file, then reload the firewall process to have it read the new rule:
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload
https://phoenixnap.com/kb/how-to-enable-ssh-centos-7
Step 3 – Testing ssh connection from local computer
We can use the ssh command to open a connection to other computers and type commands. Technically speaking, this means we’ll open a connection on port 22, which will connect to the sshd daemon to perform encryption of all network communication. The sshd daemon will hand off the connection to the login daemon, which will check login credentials. If valid user, login daemon will start the process listed in your /etc/passwd entry for default shell, and hand you off to that process.
ssh user@127.0.0.1
Step 4 – Testing ssh connection from remote computer
Next, should test connecting from a remote computer, some other computer on the network. But since it’s a VM, this computer will be the host. And this requires doing some port forwarding in VirtualBox to move the network packets from the host network stack into the VM network stack where they can then connect to the sshd daemon on the VM.
Step 4A – Background on the Network Stack, VirtualBox, and Port Forwarding
Assume you know the details of how the network stack functions. Network applications send and receive packets, and all are processed by different layers of the stack. Outbound packets, such as web browser HTTP requests are placed inside packets that add information about sender and recipient, such as IP addresses and port numbers. This information is required to make it possible for the packet to make it to the destination computer and the correct program or service. The IP address allows the network packets to pass through all the routers and switches on the Internet. When a network packet makes it to the destination computer, it’s handed to the network stack on the destination computer. As the packet works its way back up the network stack the port number makes it possible for the network stack on the destination computer to determine which program or service should get the packet.
Each VM you make has it’s own network stack that mostly works independently from the host network stack. Since the VM isn’t a real physical computer, it can’t have it’s own real network card, but it can, and does have its own IP address, transport layer, and application layer for assigning port numbers. To make up for the missing layers when VirtualBox is installed it adds some code to interface the VM with the host computer network stack. This code basically repackages any outgoing packets so to the host network stack they look like packets coming from any application. The code also changes the port number so that the host network stack will know to hand it any incoming response packets.
Vbox actually has several different types of virtual networking it can perform, but we don’t want to go down that rabbit hole now. At this point you just need to know that the default form of networking is something called NAT or Network Address Translation. In this type of networking VBox adds some code that can inject outgoing packets into the host network stack, and eavesdrops on incoming packets and will grab any bound for the VM and hand them to the VM network stack. This isn’t super technically correct as I’m simplifying this explanation to try and keep it short, but it should give you the general idea of what’s happening.
The VBox code can grab response packets, but it needs some help to get packets that are not a response to packets originally sent from the VM. That is, if we want to do something like sit at a different computer on the network and open an ssh connection into the VM we need to tell the Vbox code to look for these incoming packets. The way we do this is with port forwarding. Port forwarding is another networking subject that I assume you know, so we’re not going into much depth on what it is and how it works.
Basically port forwarding tells the network stack, or in this case the vbox code, to take packets bound for some IP address/port combination, and change the IP address or port, or both. To set this up we need to know the IP address and port of the packets we want Vbox to grab, and the IP address and port of the VM we want to forward the packets to.
And once again, the goal is to get packets that start on the host computer and send them into the VM. So in this case the host computer is going to send packets to itself, using the 127.0.0.1 IP address. This will start them down the network stack where the Vbox code can grab them. The original destination port # is 22, which is the default ssh port. We then want to set up the Vbox code to grab these packets and send them to the IP address of the VM. Do you remember what this is for your VM? You could go back to your VM and run ip a or one of the other commands to figure it out. But I’ll just tell you that when we use the default NAT networking in Vbox this IP address is always 10.0.2.15. You may not remember this address now, but you’ll be using it enough that in a few weeks it will be one of those stupid pieces of information that you remember even if you don’t want to. The port we want to port forward to is still going to be 22, so the entire port forwarding rule we want to set up is:
From 127.0.0.1:22
To 10.0.2.15:22
Step 4B – Configuring port forwarding in VirtualBox
See the video for the steps in this part of the process.
Step 4C – Testing the ssh connection from host computer