🐧 Day 7: Working with Linux Servers: Access Methods and Networking Setup
Purpose
Before moving to the next DevOps tools, it is important to understand how we actually work with Linux systems in real environments. This document explains common ways to access Linux servers and the networking setups behind them, especially when using virtual machines.
This section acts as a practical bridge between Linux fundamentals and real DevOps workflows.
Common Ways to Work with a Linux Server
In practice, there are three common approaches:
Direct login to the server
SSH access from a host machine
SSH access using NAT with port forwarding
Each method has its own use case.
Option 1: Direct Login to the Server
This is the simplest method and is commonly used in learning or lab environments.
How It Works
You open the virtual machine console
Log in using username and password
Run commands directly on the server terminal
Where This Is Used
Local labs
Initial Linux learning
Recovery or emergency console access
Limitations
Not practical for real-world DevOps
No remote automation
Does not reflect production access patterns
Option 2: SSH from Host Machine (Bridged Adapter)
This is the most realistic and preferred method for DevOps learning.
How It Works
The VM uses a bridged network adapter
The VM gets an IP address from the same network as the host
The host machine can SSH directly into the VM
ssh user@vm_ip
Why Bridged Adapter Is Used
VM behaves like a real server on the network
No port forwarding required
Closely matches production server access
When to Use
DevOps practice labs
Networking experiments
SSH-based workflows
Option 3: SSH Using NAT with Port Forwarding
This approach is commonly used when network access is restricted.
How It Works
VM uses a NAT adapter
VM has a private internal IP
Host cannot directly reach the VM
Port forwarding maps a host port to the VM SSH port
Example Port Forwarding Setup
Host IP:
127.0.0.1Host Port:
2222Guest IP: VM internal IP
Guest Port:
22
SSH Command
Example:
ssh user@127.0.0.1 -p 2222
Why Port Forwarding Is Needed
NAT isolates the VM from the host network
Port forwarding exposes specific services
SSH traffic is redirected to the VM
When to Use
Corporate or restricted networks
Laptop-based labs
Environments without bridged access
Bridged vs NAT (Quick Comparison)
| Feature | Bridged Adapter | NAT with Port Forwarding |
|---|---|---|
| Direct SSH access | Yes | No |
| Requires port forwarding | No | Yes |
| Network realism | High | Medium |
| Ease of setup | Medium | Easy |
DevOps Perspective
In real production environments:
Engineers rarely use console login
SSH access is the standard
Network access is controlled and secured
Learning both bridged and NAT-based access prepares you for different environments.
Additional Practical Considerations
SSH Configuration File
To simplify SSH access, Linux allows using an SSH configuration file.
File location:
~/.ssh/config
Example:
Host dev-vm
HostName 127.0.0.1
User devuser
Port 2222
This allows connecting using:
ssh dev-vm
This is commonly used in DevOps to avoid repeatedly typing long commands.
Security Considerations While Accessing Servers
When working with Linux servers:
Avoid enabling password-based SSH in long-term setups
Do not expose unnecessary ports via port forwarding
Use non-root users for SSH access
These practices reduce accidental security risks even in lab environments.
Relation to Cloud and Production Environments
The same access concepts apply in cloud platforms:
Cloud VMs behave like bridged networking
SSH keys are the default authentication method
Firewalls and security groups replace local port forwarding rules
Understanding VM access locally makes cloud access easier to understand.
Summary
This document explained practical ways to work with Linux systems, including direct access, SSH using bridged networking, and SSH using NAT with port forwarding. Understanding these access methods helps bridge the gap between Linux fundamentals and real DevOps workflows.
