SSH is how you get a real command-line session on a machine that isn't the one in front of you — encrypted, authenticated, and (done properly) using a key pair instead of a password. Nearly every real server you'll ever touch is managed this way.
3 min read
SSH (Secure Shell) opens an encrypted, authenticated connection to a remote machine, giving you a real command-line session on it — exactly as if you were sitting at that machine's own terminal, just over a network connection instead. This directly builds on the Networking Fundamentals domain's HTTPS/TLS lesson: SSH is a different protocol, but solves the same underlying problem (encryption and authentication over a connection anyone could otherwise be watching).
$ ssh alice@203.0.113.9
alice@203.0.113.9's password: ****A password can be guessed, phished, or brute-forced. SSH key pairs — a private key that never leaves your own machine, and a matching public key placed on the server — let the server verify your identity cryptographically, without a password ever being transmitted at all, and without one being guessable through repeated attempts the way a password is.
$ ssh-keygen -t ed25519 # generate a new key pair (private + public)
$ ssh-copy-id alice@203.0.113.9 # copy your public key to the server, authorizing it
$ ssh alice@203.0.113.9 # now connects with no password prompt at allThe private key never leaves your machine at any point in this exchange — only a signature proving you hold it gets sent, which is exactly why this is more secure than a password ever traveling (even encrypted) over the network.
A server accepting password logins over the internet is exposed to constant, automated brute-force login attempts — bots trying huge numbers of common passwords against any reachable SSH port. Disabling password authentication entirely (accepting only key-based logins) removes that entire attack surface outright, rather than just trying to pick a stronger password — this is standard, expected practice for any real production server, not an optional hardening step.
$ ssh -i ~/.ssh/specific_key alice@203.0.113.9 # use a specific key file
$ scp file.txt alice@203.0.113.9:/home/alice/ # copy a file TO a remote server
$ scp alice@203.0.113.9:/home/alice/file.txt . # copy a file FROM a remote server
$ ssh alice@203.0.113.9 "ls -la /var/log" # run one command remotely, no interactive sessionscp (secure copy) reuses the exact same SSH authentication and encryption to
transfer files, rather than needing a completely separate protocol or tool for
that related task.
A ~/.ssh/config file lets you define a shorthand name for a server instead
of retyping its full address, username, and key file every time:
# in ~/.ssh/config
Host myserver
HostName 203.0.113.9
User alice
IdentityFile ~/.ssh/specific_key
$ ssh myserver # now equivalent to the full command aboveCheck your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why is SSH key-based authentication considered more secure than a password?
2. Why do real production servers typically disable SSH password authentication entirely?
3. What does `scp` do, and how does it relate to SSH?
Linux & the Command Line