SSH, Remote Access, and Key-Based Authentication
Objective. Students will generate SSH key pairs, configure key-based login to a remote Linux host, harden the SSH daemon configuration, and use SCP and rsync for secure file transfer.
This lesson, its worked examples and its practice questions has not yet been verified by an industry-certified professional or by a certification or approval body. It is a study draft and may contain errors. Do not use it as instructions for work on a job site or on live equipment. Always follow your instructor, your supervising professional, and current official references and regulations.
VoTechWorks program approval and accreditation are still in progress. Credentials are issued only by the certifying bodies named in each program, after their own exams.
Why SSH Matters for Web Developers
Secure Shell (SSH) is the standard protocol for remotely administering Linux servers, pushing code, and transferring files. Every web and software developer who works with a cloud server, a VPS, or a co-located machine will use SSH daily. Understanding how to configure it securely is not optional — a misconfigured SSH server is one of the most common entry points for unauthorized access.
How SSH Authentication Works
SSH supports two main authentication methods: password-based and key-based. Password authentication is convenient but vulnerable to brute-force attacks. Key-based authentication uses a mathematically linked pair of files:
- Private key — stays on your local machine, never shared.
- Public key — copied to the remote server into `~/.ssh/authorized_keys`.
When you connect, the server sends a challenge that only the holder of the matching private key can answer. Even if an attacker captures network traffic, they cannot derive the private key from the public key.
Generating an Ed25519 Key Pair
Ed25519 is the recommended algorithm today. It produces shorter keys than RSA while providing strong security. To generate a key pair:
```bash
ssh-keygen -t ed25519
```
The tool asks for a save location (accept the default `~/.ssh/id_ed25519`) and a passphrase. Always set a passphrase. If your private key file is ever stolen, the passphrase is the last line of defense preventing its use. Your private key file should have permissions `600` (owner read/write only). The `.ssh` directory itself should be `700`. These permissions are set automatically by `ssh-keygen`, but verify them:
```bash
ls -la ~/.ssh/
```
Copying the Public Key to a Remote Host
`ssh-copy-id` is the safest, easiest way to install your public key on a remote server:
```bash
ssh-copy-id username@remote_ip
```
This appends your public key to the remote user's `~/.ssh/authorized_keys` and sets correct permissions. After this step, test the connection:
```bash
ssh username@remote_ip
```
You should be prompted for your local passphrase (not the remote password), and you should log in successfully.
Hardening the SSH Daemon (sshd_config)
The SSH daemon configuration file is `/etc/ssh/sshd_config`. Editing it incorrectly can lock you out of a server, so always keep a second terminal session open while making changes, and test before closing that session.
Three essential hardening settings:
| Directive | Recommended Value | Reason |
|---|---|---|
| `PermitRootLogin` | `no` | Prevents direct root login over SSH |
| `PasswordAuthentication` | `no` | Forces key-based auth only |
| `Port` | A non-default value | Reduces automated scanning noise |
After editing, reload the daemon without dropping existing connections:
```bash
sudo systemctl reload sshd
```
Then verify from a new terminal window that key-based login still works before closing your existing session.
Safety note: Disabling `PasswordAuthentication` before confirming your key-based login works will lock you out of the server. Always test in order: (1) confirm key login works, (2) then disable password auth, (3) then reload, (4) then test again from a new session.
Secure File Transfer: SCP and Rsync
SCP (Secure Copy Protocol) copies files over SSH. To push a local archive to a remote server:
```bash
scp project.tar.gz username@remote_ip:/home/username/
```
SCP is simple but copies the entire file every time, even if only one byte changed.
Rsync is smarter. It calculates differences and transfers only changed blocks. The `--checksum` flag compares files by MD5/SHA checksum rather than modification time and file size, which is more reliable:
```bash
rsync -av --checksum local_dir/ username@remote_ip:/home/username/remote_dir/
```
Flags used:
- `-a` — archive mode: preserves permissions, timestamps, symbolic links, and recurses into subdirectories.
- `-v` — verbose output so you can see exactly what was transferred.
- `--checksum` — ensures byte-level accuracy.
After syncing, compare directory sizes on both machines with:
```bash
du -sh directory_name/
```
If both values match, the transfer was accurate.
Credential Relevance
This lesson directly supports the CompTIA Linux+ exam, which tests SSH configuration, file permissions, and secure remote access. CompTIA ITF+ concepts of networking and security fundamentals underpin the theory. PCEP Python is less directly tested here, but Python scripts often automate SSH tasks using libraries like Paramiko.
Key Safety Rules Summary
1. Never share your private key.
2. Always use a passphrase on private keys.
3. Keep a live session open when editing `sshd_config`.
4. Test key login before disabling password auth.
5. Verify file permissions on `~/.ssh/` are `700` and on private key files are `600`.
Key terms9
Materials: Pairs of student VMs on the same LAN, OpenSSH man pages, sshd_config reference, rsync man page
Check: Instructor attempts password login to each student's VM (must be refused) and key-based login (must succeed); rsync output must show zero files skipped — pass requires both outcomes confirmed.
Practice check8
Answer each question, then check it. Nothing is recorded; this is your own practice.
