SSH basics: connect and verify a server identity

01 / 05

SSH authenticates both sides

Secure Shell (SSH) encrypts a remote terminal session end to end. Your client verifies the server's identity using a host key, then the server authenticates you — with a password, a key pair, or another method the administrator configured. Encryption protects the conversation from eavesdropping; it says nothing about whether you should be having that conversation with this particular server in the first place, so the two checks are independent and both matter.

`ssh -V` prints your local SSH client's version, which matters because an older client sometimes lacks support for a key type or cipher a modern server requires, or, less commonly, still defaults to something a modern server refuses outright. Knowing your version before you troubleshoot a failed connection saves a great deal of guessing.

SSH normally listens on TCP port 22, though an administrator can move it — another reason "I can reach the server" and "I can reach its SSH port" are separate facts, in the same spirit as the DNS-versus-reachability distinction the next lesson covers in more depth.

02 / 05

Host keys prevent wrong-server mistakes

The first time you connect to a server, SSH asks whether to trust the host key it presents, and after you accept, it remembers that key in your local known_hosts file. A later warning that the key has changed can be entirely normal — after a deliberate server rebuild or a planned key rotation — but it can equally signal a DNS problem, a routing change, or an interception attempt, and SSH itself cannot tell those apart for you.

The only safe response to a changed-key warning is to verify the new fingerprint through a separate, trusted channel — your cloud provider's console, a colleague on a phone call, an internal wiki page — before you accept it. Typing yes because the warning is inconvenient defeats the entire purpose of host-key checking.

A fingerprint is simply a short, human-comparable hash of the full host key — small enough to read aloud on a phone call, which is exactly the property that makes out-of-band verification practical instead of theoretical.

03 / 05

Guided sample: inspect your local SSH records

Your `~/.ssh` directory holds your keys and your known_hosts file, both safe to list and inspect without connecting anywhere. `ssh-keygen -F` searches known_hosts for a specific host without modifying it. The address used below, 203.0.113.10, is reserved by RFC 5737 (a Request for Comments — one of the numbered documents through which the IETF publishes Internet standards) specifically for documentation, so searching for it in known_hosts is a local way to practice the syntax. Do not attempt a connection to that example address.

ssh -Vls -l ~/.sshssh-keygen -F 203.0.113.10

04 / 05

Guided sample: connect to an approved lab host

This is a template, not a command you can run as printed: 203.0.113.10 and learner are stand-ins for `<LAB_HOST>` and `<LAB_USER>` — the documentation-only address and placeholder account name that the code block below uses so it stays valid, runnable syntax. Replace both with the real address and username your instructor or your own lab environment gives you, and only after you receive them from that host's owner.

`StrictHostKeyChecking=ask` is the safe, default-equivalent setting: it still asks you to confirm an unknown key rather than silently accepting or silently refusing one. Never change that setting to `no` to make a connection error go away — that disables the exact check this lesson exists to teach you to respect.

ssh -o StrictHostKeyChecking=ask learner@203.0.113.10# After verifying the displayed fingerprint through your lab console, type yes.

05 / 05

Protect credentials and access

For VICIdial specifically, prefer individually named accounts over a shared root login, prefer key-based authentication wherever the host supports it, and keep a documented, approved break-glass process for the rare case when a named account cannot get in. None of that is optional once real customer calls depend on the server staying reachable only by the people who should reach it.

A named account also makes an audit trail possible: when three people share one root login, a change made at 2 a.m. has no author, but a change made by a named account does. That single property is worth the small extra setup cost on any host you intend to keep running past this lab.

• I can explain why a changed host-key warning is not something to click through.
• I verify a new fingerprint out of band before accepting it, every time.
• I know the difference between a documentation-only address and a real lab host I have been given.