Day 3 - The Standard for Remote Access: SSH, sshd_config, Key Authentication, and Port Forwarding

📌 Key Takeaways

• SSH is not just a remote shell; it is a comprehensive secure channel that layers authentication, file transfer, and port forwarding on top of an encrypted tunnel. Port 22 alone handles shell, scp, sftp, and tunnels.
• SSH 22 (encrypted) vs Telnet 23 (plaintext). The server config is sshd_config (with the d), the client config is ssh_config.
• Three security directives: PermitRootLogin no, PasswordAuthentication no (keys only), MaxAuthTries 3.
• For public key authentication, put the public key (.pub) in the server's authorized_keys and keep the private key on the client. Permissions are ~/.ssh 700, key files 600 — if they're too loose, SSH ignores the key.
• Forwarding is distinguished by direction — -L local (from my side, out beyond the remote) / -R remote (from the remote side, back to my side) / -D dynamic (SOCKS). scp's port option is uppercase -P, ssh's is lowercase -p.

Telnet vs SSH — The Decisive Difference Between Plaintext and Encryption

⚠️ Trap: Telnet is port 23, SSH is port 22. A choice that swaps the ports is wrong. The exact opposite statements, such as "Telnet encrypts" or "SSH is plaintext," are traps too. Telnet's only remaining use is as "a tool to test whether a port is open" (telnet host 80), not for actual remote access.

SSH is secure because at the start of a connection it safely agrees on a session encryption key through key exchange. Since every command, output, and password afterward flows encrypted with this key, anyone intercepting in the middle sees only meaningless ciphertext. Telnet has no such process, so passwords are exposed as-is.

Key sshd_config Security Directives

• The behavior of the SSH server is determined by /etc/ssh/sshd_config.
• Do not confuse it with /etc/ssh/ssh_config, the client configuration.

# /etc/ssh/sshd_config — key security directives
Port 22                          # Connection port (sometimes changed for security)
ListenAddress 0.0.0.0            # Address to listen on
Protocol 2                       # SSH protocol version (1 is vulnerable, use only 2)
 
PermitRootLogin no               # Block direct root login (security essential)
PasswordAuthentication yes       # Allow password authentication (no if keys only)
PubkeyAuthentication yes         # Allow public key authentication
PermitEmptyPasswords no          # Forbid login with an empty password
 
MaxAuthTries 3                   # Limit authentication attempts (brute-force defense)
LoginGraceTime 60                # Time limit to complete login (seconds)
AllowUsers alice bob             # Whitelist of users allowed to connect
DenyUsers guest                  # Users denied connection
 
ClientAliveInterval 300          # Interval for checking idle sessions
X11Forwarding yes                # Allow X11 GUI forwarding

• After changing the settings, the daemon must be made to reload.

sshd -t                          # Check config syntax (important: avoid locking yourself out with a bad config)
systemctl restart sshd           # Restart the daemon

⚠️ Trap: PermitRootLogin no is a representative security directive. It blocks direct root login, removing the number one target of brute-force attacks. Also, don't mix up sshd_config (server) and ssh_config (client). "The sshd_config with the daemon d is the server config."

Key distinction: Changing to PasswordAuthentication no completely blocks password login and allows only public key authentication. This is a strong security setting in practice. However, if you turn this on without registering your key beforehand, even you can't get in, so you must apply it only after registering the key.

An SSH server exposed to the internet is constantly hit by botnet brute-force attacks. The combination of PermitRootLogin no + PasswordAuthentication no (keys only) + MaxAuthTries 3 is the standard defense. On top of that, changing the port from 22 can evade a good share of automated scans, so it is often used in practice (though the fundamental defense is key authentication).

Public Key Authentication — Safe Login Without a Password

• The crown jewel of SSH is public key authentication, which lets you log in safely without a password.
• Principle: create a key pair, leave the public key on the server, and prove your identity with the private key.

# 1. Generate a key pair on the client
ssh-keygen -t ed25519 -C "alice@laptop"
#   -t : key algorithm (ed25519 recommended, for rsa use -b 4096)
#   Output: ~/.ssh/id_ed25519 (private key), ~/.ssh/id_ed25519.pub (public key)
 
# 2. Register the public key on the server (easiest way)
ssh-copy-id alice@192.168.1.10
#   → The public key is appended to the server's ~/.ssh/authorized_keys
 
# 3. Afterward, connect without a password
ssh alice@192.168.1.10

• Key authentication has strict permission requirements. If they're too loose, SSH rejects the key for security.

chmod 700 ~/.ssh                       # The directory is 700
chmod 600 ~/.ssh/authorized_keys       # The file is 600
chmod 600 ~/.ssh/id_ed25519            # The private key is 600 too

Public key authentication can be understood as "the public key is the lock, the private key is the key." The lock (public key) is safe to leave openly in the server's authorized_keys, and the client never leaks the key (private key). When the client answers, with its key, the challenge the server issued with the lock, its identity is proven without a password.

What you register on the server is the public key (.pub), and what the client keeps is the private key. A choice that reverses this, saying "upload the private key to the server," is wrong (leaking a private key is fatal). Another trap: if the ~/.ssh permissions are loose, key authentication is ignored and the password is asked for again.

Key distinction: authorized_keys (kept on the server, the list of public keys allowed to connect) and known_hosts (kept on the client, a record of the host keys of servers you've connected to) are different. The former is about "who do we let in," the latter about "is this the right server (detecting man-in-the-middle attacks)."

Try It Yourself — Setting Up Key Authentication

# Check the generated keys
ls -l ~/.ssh/
# id_ed25519  id_ed25519.pub  authorized_keys  known_hosts
 
# Check the registered public keys on the server side
cat ~/.ssh/authorized_keys
 
# Trace the authentication process with verbose logging (when diagnosing problems)
ssh -v alice@192.168.1.10

scp and sftp — File Transfer Over SSH

• Files are also moved safely over the SSH channel. No separate FTP server is needed.

# scp : copy with a single command line
scp report.txt alice@192.168.1.10:/home/alice/    # Local→remote upload
scp alice@192.168.1.10:/var/log/app.log ./        # Remote→local download
scp -r project/ alice@192.168.1.10:/srv/          # Whole directory (-r)
scp -P 2222 file user@host:/path/                 # Specify the port with uppercase -P
 
# sftp : interactive file transfer (similar to FTP commands but with SSH security)
sftp alice@192.168.1.10
sftp> put backup.tar
sftp> get config.yaml
sftp> bye

scp's port option is uppercase -P, while ssh's port option is lowercase -p. The case is reversed, so it's easy to mix up. Another point is that scp uses SSH (port 22) as-is, so a secure transfer works without a separate FTP server.

SSH Port Forwarding (Tunneling) — The Magic of the Encrypted Tunnel

• SSH can carry other connections inside its encrypted tunnel. It is powerful for bypassing firewalls and for safe access.

# Local forwarding: my 8080 → via the SSH server → internal DB (3306)
ssh -L 8080:db.internal:3306 alice@gateway
#   Now connecting to localhost:8080 is safely tunneled to internal db.internal:3306
 
# Dynamic forwarding: send all traffic beyond SSH through a SOCKS proxy
ssh -D 1080 alice@gateway

Local forwarding (-L) is "a passage linking a port on my computer to a service beyond the remote." It lets you use an internal-network DB you can't reach directly as if it were on your localhost, with the SSH gateway as a stepping stone. Every passage is encrypted by SSH, so it's safe. Summarize it as "an internal service you can't reach directly = local forwarding."

Key distinction: Local (-L) starts from my side and goes out beyond the remote, while remote (-R) starts from the remote side and comes in to my side. The directions are exactly opposite. Dynamic (-D) differs in that it accepts any destination as a SOCKS proxy rather than a specific target.

Pre-Exam Checklist

• SSH 22 / Telnet 23, SSH is encrypted, Telnet is plaintext
• Server config = sshd_config, client config = ssh_config
• PermitRootLogin no / PasswordAuthentication no (keys only) / MaxAuthTries
• ssh-keygen → public key (.pub) goes in the server's authorized_keys, the private key stays on the client
• ~/.ssh 700, authorized_keys and private key 600
• scp port -P (uppercase), ssh port -p (lowercase)
• Forwarding: -L local, -R remote, -D dynamic (SOCKS)

📖 Glossary

• SSH (Secure Shell) : The standard remote access protocol that encrypts everything end to end. It uses port 22.
• Key exchange : The process of safely agreeing on a session encryption key at the start of a connection. It's why SSH resists eavesdropping.
• sshd_config vs ssh_config : Server (daemon) config / client config. The one with the d is the server.
• PermitRootLogin : Whether root may log in directly over SSH. Setting it to no is the baseline defense.
• PasswordAuthentication no : A setting that blocks password login and allows only public key authentication. Turn it on after registering your key.
• MaxAuthTries : The number of authentication attempts allowed per connection. Used to defend against brute force.
• Public key / Private key : The lock you leave openly on the server / the key only the client holds. Leaking the private key is fatal.
• ssh-keygen / ssh-copy-id : The command that creates a key pair / the command that registers the created public key on the server.
• authorized_keys : The server-side list of "these public keys are let in."
• known_hosts : The record, accumulated on the client, of "host keys of servers you've connected to." Used to detect man-in-the-middle attacks.
• scp / sftp : Copy with a one-line command / exchange interactively. Both ride SSH port 22 as-is.
• Local forwarding (-L) : A tunnel linking connections arriving at my local port to a target beyond the SSH server.
• Remote forwarding (-R) : A tunnel pulling connections arriving at the remote server's port to a target on my side. The direction is opposite to -L.
• Dynamic forwarding (-D) : A method that acts as a SOCKS proxy with no specific target and accepts every destination.