SSH, Remote Access, and Encryption in Transit

Why SSH Security Matters

Secure Shell (SSH) is the primary protocol administrators use to manage Linux servers remotely. Because it exposes an authenticated, encrypted channel directly into a system, a poorly configured SSH daemon is one of the most targeted services on the internet. Automated bots continuously scan for open SSH ports and attempt credential attacks. Hardening SSH is therefore one of the first actions you should take on any production Linux system — and a core skill tested on CompTIA Security+ and CySA+.

How SSH Encryption Works

SSH uses asymmetric cryptography during the initial handshake to authenticate both server and client, then switches to a symmetric session key for bulk data transfer. When you connect to a server, your client verifies the server's host key against a known-hosts file, protecting you from man-in-the-middle attacks. The client can then prove its identity either by password or by a cryptographic key pair.

A key pair consists of a private key (kept secret on your local machine) and a public key (placed on the server in `~/.ssh/authorized_keys`). Authentication works by a challenge-response: the server encrypts a random value with your public key; only your private key can decrypt and answer it correctly. No password ever crosses the network.

Ed25519 is the recommended key algorithm today. It is based on elliptic-curve cryptography, produces short keys, resists certain side-channel attacks, and is faster than older RSA keys while providing strong security. CompTIA Security+ covers elliptic-curve concepts in its Cryptography and PKI domain.

Generating and Deploying a Key Pair

On your host machine, run:

```

ssh-keygen -t ed25519 -C "your_label"

```

Accept the default file path or choose a custom one. Add a strong passphrase — this encrypts the private key on disk, so theft of the file alone is not sufficient for access. Use `ssh-copy-id user@server_ip` to install the public key on the remote VM automatically. After that, `ssh user@server_ip` should succeed without a password prompt.

Hardening /etc/ssh/sshd_config

The SSH daemon reads its configuration from `/etc/ssh/sshd_config`. Always keep a second terminal session open and authenticated before restarting `sshd` — a misconfiguration could lock you out, so the open session is your safety net to fix errors without losing access.

Key directives to set:

• `PermitRootLogin no` — prevents direct root login; attackers must first compromise a regular account.
• `PasswordAuthentication no` — forces key-based login once keys are deployed; eliminates brute-force password attacks.
• `AllowUsers alice bob` — restricts SSH access to named accounts only; all others are denied even with valid credentials.
• `Port 2222` (or another non-default port) — reduces automated scan noise; security through obscurity alone is weak, but combined with other controls it lowers log clutter.
• `ClientAliveInterval 300` and `ClientAliveCountMax 2` — terminates idle sessions after roughly ten minutes, reducing the window for session hijacking.

After editing, validate syntax with `sshd -t` before restarting. Restart with `sudo systemctl restart sshd`. The CIS Benchmark for SSH provides a detailed, evidence-based checklist aligned with these controls.

Blocking Brute-Force Attacks with fail2ban

Even with password authentication disabled, attackers may probe for configuration weaknesses. fail2ban monitors log files (such as `/var/log/auth.log`) and uses configurable rules to ban IP addresses that exceed a failure threshold within a time window.

Install with `sudo apt install fail2ban`. The default jail configuration lives in `/etc/fail2ban/jail.conf`; create a local override at `/etc/fail2ban/jail.local` to survive package updates. A basic SSH jail entry sets `maxretry` (maximum failures before ban), `findtime` (the observation window), and `bantime` (how long the IP is blocked). After enabling the jail and restarting fail2ban, inspect status with:

```

sudo fail2ban-client status sshd

```

This command shows currently jailed IPs, total bans, and failed attempts — useful evidence for an incident report.

Logging and Verification

`/var/log/auth.log` (Debian/Ubuntu) records every authentication attempt, success or failure. Review it with `grep sshd /var/log/auth.log | tail -50` to see recent activity. CySA+ emphasizes log analysis as a core analyst skill; being able to correlate authentication failures with ban events demonstrates that your controls are functioning.

Safety and Professional Practice

• Always work from a second open session when editing `sshd_config` on a live server. Losing remote access to a cloud VM can be extremely difficult to recover without console access.
• Never store private keys on shared systems or in version control repositories.
• Document every configuration change: what was changed, why, and when. This supports audit trails and change management processes.
• In organizational environments, obtain proper authorization before performing any port scans or simulated attacks, even on systems you own.