Replace remote login with SSH

The previous lesson showed what an observer gets from a plaintext session: everything. The fix is not a Telnet patch or a hidden port. Use SSH for remote login over any network you do not fully control.

This is not a preference. It is the baseline. Telnet remote login has been obsolete for this job since the 1990s.

What SSH adds

SSH sets up a protected transport, authenticates the server, authenticates the user, and carries terminal sessions through encrypted channels. It also protects the integrity of the traffic, so an attacker cannot silently alter bytes in flight. Every property Telnet lacks, handled before your first command runs.

The command is as short as the Telnet one:

ssh alice@server.example

On the first connection, SSH shows you the server’s host key fingerprint:

The authenticity of host 'server.example (203.0.113.7)' can't be established.
ED25519 key fingerprint is SHA256:xk8m2P1vQ9rT4wLnYc6bJdHs0aZeUf3gRi7oN5qWvKk.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Do not type yes on reflex. This prompt is SSH asking you to confirm you are talking to the right machine. The way to answer it properly is to compare the fingerprint against one you got through a trusted channel: the hosting provider’s console, a colleague who set the server up, a note you made when you installed it.

Why does this matter so much? Encryption without authentication just means the attacker reads your session privately. An encrypted connection to an unverified impostor is not a safe replacement for Telnet. It only feels like one.

Once you accept, SSH stores the key in ~/.ssh/known_hosts and checks it on every later connection. A sudden mismatch warning means the server changed or someone is intercepting you. Stop and find out which before you type a password.

Check nothing still listens on 23

While replacing Telnet, verify the old service is actually gone from your servers:

ss -tln | grep :23

No output is the answer you want. A telnetd that keeps running next to sshd keeps the plaintext risk alive for anyone who still connects to it, including old scripts nobody remembers.

What Telnet is still for

Keep Telnet for controlled legacy systems, protocol study, and narrow diagnostics where plaintext is intentional and no secret is sent. That is exactly how this course uses it: a window into TCP and text protocols.

For logging into machines and running commands, the answer is SSH, every time.