SSH and Remote Access

Summary

This chapter covers secure remote access to Linux systems using SSH. You'll learn about the SSH protocol, key-based authentication (far more secure than passwords), configuring SSH clients, and transferring files with SCP and rsync. You'll also learn firewall basics with UFW and understand network security principles.

Concepts Covered

This chapter covers the following 21 concepts from the learning graph:

SSH Protocol
SSH Command
SSH Keys
SSH Config
SCP Command
Rsync Command
Firewall Basics
UFW Firewall
Firewall Rules
Linux Security
User Authentication
Password Security
SSH Security
Key-Based Auth
Port Security
Secure File Transfer
Security Updates
Vulnerability Scanning
Log Files
Audit Logs
Security Best Practices

Prerequisites

This chapter builds on concepts from:

Welcome to the Secret Tunnel!

Imagine being able to control a computer on the other side of the world, as if you were sitting right in front of it. That's what SSH gives you—a secure, encrypted tunnel through the wild internet, letting you work remotely without anyone eavesdropping on your commands.

In this chapter, you'll learn to connect to remote systems like a pro, transfer files securely, and lock down your systems so the bad guys stay out. Security isn't just for paranoid people—it's for SMART people. And you're about to get very smart!

The SSH Protocol: Secure Shell

The SSH protocol (Secure Shell) is the standard way to securely access remote Linux systems. It encrypts everything—your commands, your passwords, your files—so nobody can snoop on your connection.

SSH replaced older, insecure protocols like Telnet (which sent passwords in plain text—yikes!) and has been the gold standard since 1995.

What SSH Does

Encrypted remote terminal: Run commands on remote computers
Secure file transfer: Copy files safely between systems
Port forwarding: Tunnel other connections through SSH
Key-based authentication: Login without passwords (more secure!)

How SSH Works (Simplified)

Client connects to server on port 22
Server and client agree on encryption method
Client authenticates (password or key)
Encrypted session begins
Everything you type is encrypted before sending

Your Computer  ←──[Encrypted Tunnel]──→  Remote Server
     │                                        │
   Client                                   Server
 (ssh command)                          (sshd daemon)

The SSH Command: Connect to Remote Systems

The ssh command is your gateway to remote servers. It's simple to use but incredibly powerful.

Basic SSH Connection

# Connect with username
ssh username@hostname

# Connect with IP address
ssh dan@192.168.1.100

# Connect to different port
ssh -p 2222 username@hostname

# Connect with verbose output (for debugging)
ssh -v username@hostname

First Connection: The Fingerprint Warning

The first time you connect to a server, you'll see something like:

The authenticity of host 'server.example.com (192.168.1.100)' can't be established.
ED25519 key fingerprint is SHA256:xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This is SSH protecting you from "man-in-the-middle" attacks. The fingerprint is the server's identity. Type yes if you trust the server—SSH will remember it for next time.

Fingerprint Changes = Red Flag!

If you've connected before and suddenly see a different fingerprint, STOP! Someone might be intercepting your connection. Verify with the server administrator before proceeding.

Running Remote Commands

# Run a single command without staying connected
ssh user@server "hostname"
ssh user@server "uptime"
ssh user@server "df -h"

# Run multiple commands
ssh user@server "cd /var/log && tail -20 syslog"

# Run a local script on remote server
ssh user@server 'bash -s' < local-script.sh

SSH Options You'll Use

Option	Purpose
`-p port`	Connect to different port
`-i keyfile`	Use specific private key
`-v`	Verbose (debugging)
`-X`	Forward X11 graphics
`-L local:host:remote`	Local port forwarding
`-R remote:host:local`	Remote port forwarding
`-N`	No command (just tunnel)

SSH Keys: Passwords Are So Yesterday

SSH keys are the secure alternative to passwords. Instead of typing a password every time, you use cryptographic key pairs. It's more secure AND more convenient—the best of both worlds!

How Key Authentication Works

You generate a key pair: private key (secret!) and public key (shareable)
You put your public key on the remote server
When you connect, SSH does cryptographic magic to prove you have the private key
If it matches, you're in—no password needed!

Generating SSH Keys

# Generate a key pair (Ed25519 - modern and secure)
ssh-keygen -t ed25519 -C "your_email@example.com"

# Or RSA (widely compatible)
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

You'll be asked: - Where to save: Press Enter for default (~/.ssh/id_ed25519) - Passphrase: Optional but HIGHLY recommended (protects your key if stolen)

This creates two files: - ~/.ssh/id_ed25519 - Your private key (NEVER share this!) - ~/.ssh/id_ed25519.pub - Your public key (safe to share)

Installing Your Public Key

# The easy way (if ssh-copy-id is available)
ssh-copy-id username@remote-server

# The manual way
cat ~/.ssh/id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

# Or copy and paste manually
cat ~/.ssh/id_ed25519.pub
# Then paste into ~/.ssh/authorized_keys on the server

Key Security Best Practices

# Set correct permissions (SSH is strict about this!)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys

Protect Your Private Key!

Your private key is like your house key. If someone gets it (and knows your passphrase if you have one), they can access all servers where you've installed the public key. NEVER:

Email your private key
Put it in a Git repository
Store it on shared systems
Share it with anyone

Key-Based Auth: Why It's Better

Key-based authentication is superior to passwords for several reasons:

Feature	Password	SSH Key
Can be guessed	Yes	Practically impossible
Can be brute-forced	Yes (slowly)	No (too long)
Can be phished	Yes	No
Reused across sites	Often	Never (unique per key)
Length	8-20 characters	4096+ bits
Convenience	Type every time	Automatic

Once you set up SSH keys, you can (and should!) disable password authentication entirely:

# On the server, edit /etc/ssh/sshd_config:
PasswordAuthentication no
PubkeyAuthentication yes

# Then restart SSH
sudo systemctl restart sshd

SSH Config: Your Connection Shortcuts

The SSH config file (~/.ssh/config) lets you create shortcuts for servers you connect to frequently. Instead of typing long commands, you define aliases!

Creating SSH Config

# Create or edit ~/.ssh/config
nano ~/.ssh/config

Example Configuration

# Default settings for all hosts
Host *
    AddKeysToAgent yes
    IdentitiesOnly yes

# Work server
Host work
    HostName server.company.com
    User jsmith
    Port 22
    IdentityFile ~/.ssh/id_work

# Raspberry Pi at home
Host pi
    HostName 192.168.1.50
    User pi
    IdentityFile ~/.ssh/id_ed25519

# Jump through bastion to reach internal server
Host internal
    HostName 10.0.0.100
    User admin
    ProxyJump bastion.company.com

# AWS server with custom settings
Host aws-prod
    HostName ec2-12-34-56-78.compute-1.amazonaws.com
    User ubuntu
    IdentityFile ~/.ssh/aws-key.pem
    ServerAliveInterval 60

Now you can just type:

ssh work      # Instead of: ssh -i ~/.ssh/id_work jsmith@server.company.com
ssh pi        # Instead of: ssh pi@192.168.1.50
ssh internal  # Automatically jumps through bastion!

Useful Config Options

Option	Purpose
`HostName`	Real hostname or IP
`User`	Default username
`Port`	SSH port
`IdentityFile`	Which private key to use
`ProxyJump`	Jump through another host
`ServerAliveInterval`	Keep connection alive
`ForwardAgent`	Allow key forwarding
`LocalForward`	Set up port forwarding

The SCP Command: Secure Copy

The scp command (secure copy) transfers files over SSH. It's like cp, but works across networks securely.

# Copy file TO remote server
scp file.txt user@server:/path/to/destination/

# Copy file FROM remote server
scp user@server:/path/to/file.txt ./local-copy.txt

# Copy entire directory (recursive)
scp -r my-folder/ user@server:/home/user/

# Copy with specific port
scp -P 2222 file.txt user@server:/path/

# Preserve timestamps and permissions
scp -p file.txt user@server:/path/

# Show progress
scp -v file.txt user@server:/path/

SCP Between Two Remote Servers

# Copy directly between two remote hosts
scp user1@server1:/path/file.txt user2@server2:/path/

Common SCP Options

Option	Purpose
`-r`	Recursive (directories)
`-P port`	Specify port (capital P!)
`-p`	Preserve modification times
`-C`	Compress during transfer
`-v`	Verbose output
`-i key`	Use specific identity file

The Rsync Command: Smart Synchronization

The rsync command is the power tool for file synchronization. Unlike SCP, it only transfers what's changed—making it MUCH faster for large directories or repeated transfers.

# Basic sync (local to remote)
rsync -av /local/folder/ user@server:/remote/folder/

# Sync from remote to local
rsync -av user@server:/remote/folder/ /local/folder/

# Delete files on destination that don't exist on source
rsync -av --delete /source/ user@server:/destination/

# Dry run (show what would happen without doing it)
rsync -av --dry-run /source/ user@server:/destination/

# Show progress
rsync -av --progress /source/ user@server:/destination/

# Exclude patterns
rsync -av --exclude='*.log' --exclude='.git' /source/ user@server:/dest/

# Compress during transfer
rsync -avz /source/ user@server:/destination/

The Trailing Slash Matters!

# WITH trailing slash: copy contents of folder
rsync -av /source/ /dest/     # Files appear directly in /dest/

# WITHOUT trailing slash: copy the folder itself
rsync -av /source /dest/      # Creates /dest/source/ with files inside

Rsync is Idempotent

You can run the same rsync command repeatedly—it only transfers changes. This makes it perfect for backups and keeping servers in sync!

Rsync vs SCP

Feature	SCP	Rsync
Speed (first copy)	Similar	Similar
Speed (updates)	Copies everything	Only changes
Resume interrupted	No	Yes
Exclude patterns	No	Yes
Delete removed files	No	Yes
Compression	Basic	Better
Bandwidth limiting	No	Yes

Secure File Transfer: Best Practices

Secure file transfer is crucial when moving sensitive data. Here are the secure options:

The Good (Encrypted)

SCP: Simple, secure, good for quick copies
SFTP: Interactive file browser over SSH
Rsync over SSH: Best for syncing large amounts
HTTPS uploads: Encrypted web transfers

The Bad (Avoid These)

FTP: Passwords sent in plain text!
HTTP uploads: Anyone can see the data
Telnet file transfers: Everything exposed

Using SFTP

# Start interactive SFTP session
sftp user@server

# SFTP commands (similar to regular shell)
sftp> ls              # List remote files
sftp> lls             # List local files
sftp> cd /path        # Change remote directory
sftp> lcd /path       # Change local directory
sftp> get file.txt    # Download file
sftp> put file.txt    # Upload file
sftp> quit

Firewall Basics: Your Digital Fortress

Firewall basics are essential for any Linux administrator. A firewall controls what network traffic can enter and leave your system—think of it as a security guard checking IDs at the door.

What Firewalls Do

Block unwanted incoming connections (hackers, port scanners)
Allow legitimate traffic (SSH, web servers)
Control outgoing connections (optional but useful)
Log suspicious activity (for investigation)

Firewall Types in Linux

Type	Description
`iptables`	Low-level, powerful, complex
`nftables`	Modern replacement for iptables
`ufw`	User-friendly frontend
`firewalld`	Zone-based, used by RHEL/Fedora

The UFW Firewall: Uncomplicated Firewall

The UFW firewall (Uncomplicated Firewall) is exactly what the name says—a simple way to manage firewall rules on Ubuntu and Debian systems.

# Check status
sudo ufw status
sudo ufw status verbose
sudo ufw status numbered  # Show rule numbers

# Enable/Disable firewall
sudo ufw enable
sudo ufw disable

# Allow incoming on port
sudo ufw allow 22        # SSH
sudo ufw allow 80        # HTTP
sudo ufw allow 443       # HTTPS

# Allow by service name
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https

# Allow from specific IP
sudo ufw allow from 192.168.1.100

# Allow from subnet
sudo ufw allow from 192.168.1.0/24

# Allow from IP to specific port
sudo ufw allow from 192.168.1.100 to any port 22

# Deny incoming on port
sudo ufw deny 23         # Block Telnet

# Delete a rule
sudo ufw delete allow 80
sudo ufw delete 3        # Delete rule number 3

# Reset to defaults
sudo ufw reset

UFW Default Policies

# Set default policies
sudo ufw default deny incoming    # Block all incoming by default
sudo ufw default allow outgoing   # Allow all outgoing by default

# This is the recommended starting point!

Rate Limiting with UFW

# Limit connections (protects against brute force)
sudo ufw limit ssh

# This allows only 6 connections per 30 seconds from same IP

Firewall Rules: Building Your Policy

Firewall rules determine what traffic is allowed. Rules are processed in order, and the first match wins.

Example Server Configuration

# Start fresh
sudo ufw reset

# Set defaults
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (with rate limiting)
sudo ufw limit ssh

# Allow web traffic
sudo ufw allow http
sudo ufw allow https

# Allow from local network only
sudo ufw allow from 192.168.1.0/24 to any port 3306  # MySQL

# Enable and check
sudo ufw enable
sudo ufw status verbose

Rule Order Example

# Rules are processed in order!
# This blocks SSH from evil IP, but allows from everyone else
sudo ufw deny from 203.0.113.50 to any port 22
sudo ufw allow ssh

Port Security: Minimizing Attack Surface

Port security means only opening the ports you actually need. Every open port is a potential entry point for attackers.

Checking Open Ports

# See what's listening
sudo ss -tulnp
sudo netstat -tulnp

# Scan your own system
nmap localhost
nmap -sV localhost  # With service detection

Best Practices

Default deny: Block everything, then allow specific ports
Principle of least privilege: Only open what's necessary
Use non-standard ports: Move SSH from 22 to something obscure
Rate limiting: Slow down brute force attacks
Geoblocking: Block countries you never connect from (advanced)

# Change SSH port in /etc/ssh/sshd_config
Port 2222

# Remember to allow the new port before changing!
sudo ufw allow 2222/tcp
sudo systemctl restart sshd

Security Through Obscurity?

Changing the SSH port isn't TRUE security—a determined attacker will find it. But it stops 99% of automated bots that only try port 22. Use it AS WELL AS other security measures, not instead of them!

Linux Security: The Big Picture

Linux security is a layered approach—no single measure is enough, but together they create strong protection.

The Security Onion (Layers of Defense)

Physical security: Lock the server room
Network security: Firewalls, VPNs
Host security: Updates, minimal services
Application security: Secure configurations
Data security: Encryption, backups
User security: Strong passwords, limited privileges
Monitoring: Logs, alerts, auditing

Quick Security Checklist

[ ] Firewall enabled with minimal ports open
[ ] SSH key authentication (passwords disabled)
[ ] Regular system updates
[ ] Non-root user accounts
[ ] Sudo for administrative tasks
[ ] Log monitoring configured
[ ] Unnecessary services disabled
[ ] File permissions properly set

User Authentication: Who Are You?

User authentication verifies that users are who they claim to be. Linux supports multiple authentication methods:

Authentication Methods

Method	Security	Convenience
Password	Medium	High
SSH Keys	High	High
Two-Factor (2FA)	Very High	Medium
Smart Cards	Very High	Low
Biometrics	High	Medium

Two-Factor Authentication for SSH

# Install Google Authenticator
sudo apt install libpam-google-authenticator

# Configure for your user
google-authenticator

# Edit /etc/pam.d/sshd and add:
auth required pam_google_authenticator.so

# Edit /etc/ssh/sshd_config:
ChallengeResponseAuthentication yes

# Restart SSH
sudo systemctl restart sshd

Now you need both your key/password AND a code from your phone!

Password Security: If You Must Use Them

Password security matters even if you prefer SSH keys—you still need passwords for sudo and local logins.

Strong Password Rules

Length: Minimum 12 characters (longer is better)
Complexity: Mix of upper, lower, numbers, symbols
Uniqueness: Different password for every system
No patterns: Avoid password123, qwerty, birthdays

Password Policies

# Install password quality checking
sudo apt install libpam-pwquality

# Edit /etc/security/pwquality.conf:
minlen = 12
dcredit = -1    # Require at least 1 digit
ucredit = -1    # Require at least 1 uppercase
lcredit = -1    # Require at least 1 lowercase
ocredit = -1    # Require at least 1 special character

Password Aging

# Set password expiration
sudo chage -M 90 username    # Expire after 90 days
sudo chage -m 7 username     # Minimum 7 days before change

# Check password status
sudo chage -l username

SSH Security: Hardening Your SSH Server

SSH security involves configuring the SSH daemon to be as secure as possible.

Essential SSH Hardening

Edit /etc/ssh/sshd_config:

# Disable root login
PermitRootLogin no

# Disable password authentication (use keys only)
PasswordAuthentication no
PubkeyAuthentication yes

# Use only SSH protocol 2
Protocol 2

# Limit login attempts
MaxAuthTries 3

# Limit concurrent sessions
MaxSessions 3

# Idle timeout (seconds)
ClientAliveInterval 300
ClientAliveCountMax 2

# Allow only specific users
AllowUsers alice bob charlie

# Or allow by group
AllowGroups ssh-users

# Disable empty passwords
PermitEmptyPasswords no

# Disable X11 forwarding (if not needed)
X11Forwarding no

After changes:

# Test configuration
sudo sshd -t

# Restart SSH
sudo systemctl restart sshd

Don't Lock Yourself Out!

Before disabling password authentication, make sure your SSH key works! Keep a second terminal connected while testing.

Fail2Ban: Automatic Banning

# Install fail2ban
sudo apt install fail2ban

# Configure /etc/fail2ban/jail.local:
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600    # 1 hour

# Start and enable
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Check banned IPs
sudo fail2ban-client status sshd

Fail2ban watches your logs and automatically blocks IPs that fail too many login attempts!

Security Updates: Stay Patched!

Security updates are your first line of defense against known vulnerabilities. Hackers actively scan for unpatched systems.

# Check for updates (Debian/Ubuntu)
sudo apt update
apt list --upgradable

# Install security updates only
sudo apt upgrade --only-upgrade

# Automatic security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

How Fast Should You Update?

Update Type	Urgency	When
Critical security	ASAP	Same day
Security patches	High	Within a week
Regular updates	Normal	Regular schedule
Major upgrades	Plan carefully	Test first

Set It and Forget It

Enable automatic security updates on all servers. The risk of an unpatched vulnerability is almost always greater than the risk of an update breaking something.

Vulnerability Scanning: Know Your Weaknesses

Vulnerability scanning helps you find security holes before attackers do.

Basic Scanning Tools

# Scan for open ports
nmap -sV your-server-ip

# Check for common vulnerabilities
sudo apt install lynis
sudo lynis audit system

# Check for rootkits
sudo apt install rkhunter
sudo rkhunter --check

What Scanners Look For

Open ports that shouldn't be
Outdated software with known vulnerabilities
Misconfigured services
Weak file permissions
Rootkits and malware
Password policy issues

Regular Scanning Schedule

# Add to cron for weekly scans
0 2 * * 0 /usr/bin/lynis audit system --cronjob > /var/log/lynis-weekly.log

Log Files: Your Security Diary

Log files record everything that happens on your system. When something goes wrong (or someone breaks in), logs tell the story.

Important Log Files

Log	Location	Contents
Auth log	`/var/log/auth.log`	Login attempts, sudo usage
Syslog	`/var/log/syslog`	System events
Kernel	`/var/log/kern.log`	Kernel messages
SSH	`/var/log/auth.log`	SSH connections
Firewall	`/var/log/ufw.log`	UFW firewall events
Fail2ban	`/var/log/fail2ban.log`	Banned IPs

Reading Logs

# View recent auth events
sudo tail -50 /var/log/auth.log

# Search for failed logins
sudo grep "Failed password" /var/log/auth.log

# Watch logs in real-time
sudo tail -f /var/log/auth.log

# Use journalctl (systemd)
sudo journalctl -u sshd --since "1 hour ago"
sudo journalctl -u sshd -f  # Follow in real-time

Log Analysis Examples

# Count failed SSH attempts by IP
sudo grep "Failed password" /var/log/auth.log | \
    grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | \
    sort | uniq -c | sort -rn | head -10

# Find successful SSH logins
sudo grep "Accepted" /var/log/auth.log

# See who used sudo
sudo grep "sudo:" /var/log/auth.log | tail -20

Audit Logs: Detailed Tracking

Audit logs provide even more detailed tracking using the Linux audit system (auditd).

# Install audit daemon
sudo apt install auditd audispd-plugins

# Start and enable
sudo systemctl enable auditd
sudo systemctl start auditd

# Add audit rules
sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -w /etc/shadow -p wa -k shadow_changes
sudo auditctl -w /home -p wa -k home_changes

# Search audit logs
sudo ausearch -k passwd_changes
sudo ausearch -ts today -k passwd_changes

# Generate reports
sudo aureport --auth
sudo aureport --login
sudo aureport --failed

Persistent Audit Rules

# Add rules to /etc/audit/rules.d/audit.rules:
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes
-w /var/log/auth.log -p wa -k auth_log

# Reload rules
sudo augenrules --load

Security Best Practices: The Golden Rules

Security best practices are the habits that keep systems safe:

The Top 10 Security Habits

Update regularly: Patch early, patch often
Use SSH keys: Disable password authentication
Firewall everything: Default deny, explicit allow
Principle of least privilege: Minimal permissions
Monitor logs: Know what's happening
Strong passwords: Where you must use them
Disable unused services: Smaller attack surface
Use sudo, not root: Accountability and safety
Backup regularly: You will need them someday
Test your security: Scan and audit yourself

The Security Mindset

"The only truly secure system is one that is powered off, cast in a block of concrete, and sealed in a lead-lined room with armed guards." — Gene Spafford

You can't achieve perfect security, but you CAN:

Make attacks difficult
Detect attacks quickly
Recover from attacks smoothly

RealVNC: Remote Desktop for Support

Sometimes SSH isn't enough—you need to see the actual desktop to help someone with a technical issue. RealVNC lets you share and control remote Linux desktops, perfect for remote technical support.

What is VNC?

VNC (Virtual Network Computing) is a protocol for sharing graphical desktops remotely. Unlike SSH (which is text-only), VNC shows you the entire screen—windows, menus, everything!

Installing RealVNC Server

On the remote Linux system you want to control:

# Download from RealVNC website or use package manager
# For Raspberry Pi OS, it's pre-installed!

# On Ubuntu/Debian, download the .deb from realvnc.com:
sudo dpkg -i VNC-Server-*.deb
sudo apt install -f  # Fix any dependencies

# Enable and start the service
sudo systemctl enable vncserver-x11-serviced
sudo systemctl start vncserver-x11-serviced

Installing RealVNC Viewer

On your computer (the one you're using for support):

# Download RealVNC Viewer from realvnc.com
# Available for Linux, Windows, macOS, and mobile!

# On Linux:
sudo dpkg -i VNC-Viewer-*.deb

Setting Up for Remote Support

Method 1: Direct Connection (Same Network)

On the remote system, find its IP address: hostname -I
On your computer, open VNC Viewer
Enter the IP address
Enter the remote user's password when prompted

# Make sure the VNC port is open
sudo ufw allow 5900

Method 2: RealVNC Cloud Connect (Internet)

For helping someone over the internet (no network configuration needed):

Create a free RealVNC account at realvnc.com
Sign in to VNC Server on the remote system
Sign in to VNC Viewer on your computer
The remote system appears in your team—just click to connect!

This is MUCH easier than configuring port forwarding!

Using VNC for Tech Support

Here's a typical remote support workflow:

User reports problem: "My program won't open!"
Connect via VNC: See exactly what they see
Investigate: Watch their screen, check settings
Fix or demonstrate: Show them how to fix it
Disconnect: They're back on their own

VNC Security Tips

# Use strong passwords
vncpasswd  # Set VNC-specific password

# Always use encryption (RealVNC does this by default)

# Limit who can connect
# In VNC Server settings, use Authentication options

# Don't leave VNC running when not needed
sudo systemctl stop vncserver-x11-serviced

VNC vs SSH for Support

Use SSH when you can fix things from the command line. Use VNC when you need to see the graphical interface—like helping someone configure desktop applications, debug GUI issues, or train them visually.

Alternative: X11 Forwarding

For running single graphical applications remotely (not the whole desktop):

# Connect with X11 forwarding
ssh -X user@remote-server

# Run a graphical program
firefox &     # Opens Firefox on YOUR display
gedit file &  # Opens Gedit on YOUR display

This is lighter than VNC for single applications, but requires X11 on your local system.

Putting It All Together: Securing a New Server

Here's a checklist for securing a fresh Linux server:

#!/bin/bash
# secure-server.sh - Initial server security setup

# 1. Update everything
sudo apt update && sudo apt upgrade -y

# 2. Create non-root user (if needed)
sudo adduser myuser
sudo usermod -aG sudo myuser

# 3. Set up SSH keys (on your LOCAL machine)
# ssh-keygen -t ed25519
# ssh-copy-id myuser@server

# 4. Harden SSH
sudo sed -i 's/#PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config

# 5. Configure firewall
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit ssh
sudo ufw enable

# 6. Install fail2ban
sudo apt install -y fail2ban
sudo systemctl enable fail2ban

# 7. Enable automatic updates
sudo apt install -y unattended-upgrades
echo 'Unattended-Upgrade::Automatic-Reboot "true";' | sudo tee -a /etc/apt/apt.conf.d/50unattended-upgrades

# 8. Restart SSH
sudo systemctl restart sshd

echo "Basic security configured! Test SSH access before disconnecting!"

Key Takeaways

You're now a security-conscious Linux user!

SSH: The secure way to access remote systems
SSH keys: Far more secure than passwords
SCP/Rsync: Secure file transfer methods
Firewalls: Control what traffic enters your system
UFW: The user-friendly firewall tool
Security updates: Your first line of defense
Logs: Your security diary for investigations
VNC: Remote desktop for graphical support

Security is a Journey!

You won't implement everything at once, and that's okay. Start with the basics (keys, firewall, updates) and add more security measures over time. Every layer helps!

What's Next?

Congratulations—you've completed the core Linux curriculum! The next chapters cover advanced topics like container orchestration and system administration for those who want to go even deeper.

Quick Quiz: SSH and Security

Why are SSH keys more secure than passwords?
What command copies a file to a remote server over SSH?
What UFW command blocks all incoming traffic except SSH?
What file do you edit to configure SSH key aliases?
Where do you look to see failed login attempts?
What tool automatically bans IPs with too many failed logins?
What's the difference between SCP and Rsync?

Quiz Answers

Keys can't be guessed or brute-forced (they're 4096+ bits), can't be phished, and don't need to be typed
scp file.txt user@server:/path/ or rsync -av file.txt user@server:/path/
sudo ufw default deny incoming then sudo ufw allow ssh
~/.ssh/config
/var/log/auth.log or journalctl -u sshd
Fail2ban
SCP copies everything; Rsync only copies what changed (and can resume interrupted transfers)

References

OpenSSH Manual - Official OpenSSH documentation covering all SSH features
SSH Key Authentication Guide - DigitalOcean's comprehensive SSH key setup tutorial
SSH Config File Examples - How to create and use SSH client configuration files
UFW Firewall Guide - Ubuntu community guide to Uncomplicated Firewall
Fail2ban Tutorial - Protecting SSH with automatic IP banning
rsync Tutorial - Complete guide to file synchronization with rsync
SSH Security Best Practices - Industry best practices for securing SSH
Two-Factor Authentication for SSH - Adding 2FA with Google Authenticator
Understanding Public Key Cryptography - How SSH key pairs work
SCP Command Examples - Secure copy command tutorial with examples
Linux Security Fundamentals - Red Hat's top security practices for Linux
SSH Port Forwarding - Using SSH tunnels for secure connections
Hardening SSH Configuration - Detailed SSH hardening guides
VNC Server Setup - RealVNC official Raspberry Pi documentation
Linux Audit System Guide - Using auditd for security auditing
Password Policy Configuration - Setting up strong password requirements
iptables vs UFW Comparison - Understanding Linux firewall options
SSH Agent Forwarding - Using ssh-agent for key management
Log Monitoring with journalctl - Viewing and analyzing system logs
CIS Linux Benchmark - Industry-standard security configuration benchmarks