SSH and Remote Access
SSH (Secure Shell) is the standard protocol for encrypted remote administration of Linux systems, replacing insecure legacy tools like telnet and rlogin that transmitted credentials in plain text. Beyond interactive shell access, SSH underlies secure file copy (scp, sftp, rsync -e ssh), remote command execution in scripts, port forwarding/tunneling, and Git's SSH transport. The protocol operates client-server: sshd (the OpenSSH daemon) listens on a server, typically port 22, and the ssh client on a workstation initiates authenticated, encrypted connections. Security in production environments hinges on moving away from password authentication toward public-key authentication, and hardening the daemon configuration against common attack vectors.
Cricket analogy: Comparable to a team switching from open radio chatter that rivals could intercept to an encrypted team huddle call, just as SSH replaced plaintext telnet with an encrypted channel for every field instruction.
Key-Based Authentication
Public-key authentication uses an asymmetric key pair: a private key that never leaves the client machine (and should be passphrase-protected) and a public key that is distributed to servers. ssh-keygen generates this pair, with -t ed25519 being the modern recommended algorithm (faster and more secure than legacy RSA-2048 for equivalent strength), though -t rsa -b 4096 remains common for compatibility with older systems. ssh-copy-id automates appending the public key to the remote user's ~/.ssh/authorized_keys file, which is what sshd checks during authentication — the server never sees the private key; instead it issues a cryptographic challenge that only the holder of the matching private key can answer.
Cricket analogy: Like a bowler's unique grip that only he can reproduce staying private while his declared bowling action is public knowledge, ssh-keygen -t ed25519 creates a faster, stronger key pair than older RSA-2048 for verifying identity.
# Generate a modern ed25519 key pair (recommended default)
ssh-keygen -t ed25519 -C "deploy@build-server"
# Generate an RSA key for compatibility with older systems
ssh-keygen -t rsa -b 4096 -C "legacy-system-key"
# Copy your public key to a remote server's authorized_keys
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10
# Connect using a specific private key and non-default port
ssh -i ~/.ssh/id_ed25519 -p 2222 deploy@203.0.113.10
# Add a key to the local ssh-agent so you aren't prompted repeatedly
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
# Correct permissions — SSH refuses keys/directories that are too open
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub ~/.ssh/authorized_keysSSH silently rejects private keys and the ~/.ssh directory if their permissions are too permissive (e.g., group- or world-writable), failing with a vague 'Permissions 0644 for id_rsa are too open' error. Always ensure ~/.ssh is 700 and private key files are 600 — this is one of the most common SSH troubleshooting gotchas for newcomers copying keys between machines.
The Client Config File and Server Hardening
~/.ssh/config lets you define per-host shortcuts (aliases, users, ports, identity files, and jump-host chains), eliminating long repetitive command lines and making scripts and muscle memory portable. On the server side, /etc/ssh/sshd_config controls daemon behavior; the most consequential hardening changes are disabling PasswordAuthentication (forcing key-based auth only), disabling PermitRootLogin (or setting it to prohibit-password), and changing the default Port to reduce automated scanning noise — though port changes are security-by-obscurity, not a substitute for proper authentication controls. Any sshd_config change requires a daemon reload (never a restart mid-session without a second, verified connection open, to avoid locking yourself out).
Cricket analogy: Like a captain keeping a shorthand notebook of field placements per opposition instead of re-explaining fields every over, ~/.ssh/config stores host aliases while sshd_config hardening disables walk-on access and locks down root login.
# ~/.ssh/config example — defines a memorable alias
Host prod-web
HostName 203.0.113.10
User deploy
Port 2222
IdentityFile ~/.ssh/id_ed25519
Host bastion
HostName 198.51.100.5
User ops
Host internal-db
HostName 10.0.5.20
User ops
ProxyJump bastion
# Now simply:
ssh prod-web
ssh internal-db # transparently tunnels through the bastion host
# Key sshd_config hardening directives (/etc/ssh/sshd_config)
# PasswordAuthentication no
# PermitRootLogin prohibit-password
# Port 2222
# AllowUsers deploy ops
# Validate config syntax, then reload (not restart) to apply safely
sudo sshd -t
sudo systemctl reload sshdOpenSSH is the dominant implementation, but the protocol itself (RFC 4251-4254) is implementation-agnostic; Dropbear is a lightweight alternative commonly found on embedded systems and routers due to its smaller footprint. Also note the historical gotcha: SSH protocol version 1 had known cryptographic weaknesses and has been removed entirely from modern OpenSSH — all connections today use protocol version 2.
Port Forwarding and File Transfer
SSH tunnels arbitrary TCP traffic through its encrypted channel. Local forwarding (-L) exposes a remote service on a local port, useful for reaching a database that only listens on a remote machine's localhost. Remote forwarding (-R) does the reverse, exposing a local service to the remote side. Dynamic forwarding (-D) turns the SSH client into a SOCKS proxy, routing arbitrary application traffic through the encrypted tunnel. For file transfer, scp offers simple one-off copies (though it's considered legacy and slated for eventual removal in favor of sftp-based transfer in some distros), sftp provides an interactive, resumable session, and rsync -e ssh is preferred for large or repeated transfers because it only sends the differences between source and destination.
Cricket analogy: Like a broadcaster routing a remote commentary feed through a secure relay so viewers can tune into a match on another continent, rsync -e ssh only re-sends the highlight clips that changed instead of the whole match footage.
# Local forwarding: reach a remote-only database on localhost:5432 via local port 5433
ssh -L 5433:localhost:5432 deploy@203.0.113.10
# Copy a file to a remote server
scp -P 2222 report.csv deploy@203.0.113.10:/home/deploy/
# Recursively sync a directory efficiently, showing progress
rsync -avz --progress -e "ssh -p 2222" ./build/ deploy@203.0.113.10:/var/www/app/- SSH replaces plaintext protocols (telnet, rlogin) with encrypted, authenticated remote access; sshd listens server-side, ssh connects client-side.
- Public-key authentication (ssh-keygen, ssh-copy-id) is strongly preferred over passwords; the private key never leaves the client.
- ~/.ssh must be 700 and private keys must be 600, or SSH will refuse to use them.
- ~/.ssh/config defines host aliases, ports, identity files, and ProxyJump chains for cleaner, portable connections.
- Server hardening in /etc/ssh/sshd_config includes disabling password auth and restricting root login; always validate with
sshd -tand reload (not restart) to avoid lockout. - SSH tunneling (-L, -R, -D) securely forwards arbitrary TCP traffic; rsync -e ssh is preferred over scp for large or repeated transfers due to delta syncing.
Practice what you learned
1. Why does SSH refuse to use a private key file with permissions like 644?
2. What does the ProxyJump directive in ~/.ssh/config accomplish?
3. Which sshd_config directive, when set to 'no', forces clients to authenticate only via public keys (or other non-password methods)?
4. What is the key advantage of `rsync -e ssh` over `scp` for repeated large transfers?
5. After editing /etc/ssh/sshd_config on a remote server you are connected to, what is the safest way to apply the changes?
Was this page helpful?
You May Also Like
Basic Networking Commands (ping, curl, ss)
Learn the essential command-line tools for diagnosing connectivity, testing HTTP endpoints, and inspecting open sockets and listening ports on Linux.
Users, Groups, and sudo
Learn how Linux organizes access through users and groups, how to create and manage them, and how sudo grants temporary elevated privileges safely and auditably.
File Permissions Explained (rwx)
Understand the Linux permission model — read, write, and execute bits for owner, group, and others — and how ls -l output maps to those permissions.
systemd and Managing Services
Learn how systemd manages services, sockets, and timers as units, and how to start, stop, enable, and inspect them with systemctl and journalctl.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics